Ivy? Bazel?

[Tim Consolazio]

Anybody been working with these yet? If so, any practical reasons to make the switch?

Note I said "practical", as in, you have a specific example where your work has clearly benefited from the switch (as opposed to documentation we can all find on our own).

Myself:

- I see no particular compelling reason to switch to Ivy. This is not to say that there isn't value in Ivy, in fact, based on the docs, I'd have to say it's a superior overall mechanism.

But "superior mechanism" is not a practical reason to switch. Angular 6-8 is hardly "a thing of the past", and the rendering engine works just fine for the apps I work on (which include enterprise apps that revenue drivers use daily, so you could say "important to the business").

However, the nature of these apps, apart from the value to the business, is more or less "general". They are not high end gaming apps, or apps that real-time render physiological/biological processes, etc. More or less it'd be fair to say they're "web apps". Pretty much everything we need is already built somewhere to some extent, and if it isn't, we generally don't have any problem using some combination of the available frameworks and tools to build what we need. Like most, we're heavily invested in webpack, and so on.

But, the switch doesn't seem to be painful for the kind of work I do. Update the versions, replace a little code, and it's more or less business as usual. We've been looking it over and we're not really concerned with switching here, and if there is something we can take advantage of, great.

Bazel...now there's another story. If you work in G3 (the Google Repo), and test/run/build apps, the configuration mechanism (which as far as I can see informs Bazel) was tediously configuration heavy. EVERY DIRECTORY needed some form of config file to inform the build architecture how to compile the app. True, many of the files were basically cut-paste-tweak. But the overall process added another overt layer of cognitive process to the overall delivery of the value. It's far from "set 'n forget". Hopefully the schematics will address this and so on. And, the forward moving versions of all that had incompatibilities; I personally had to completely retool the build config for an app that was barely a year old.

Sure, if you do it all the time, you say "what's the big deal". But most organizations don't have the luxury of shoving around deadlines autumn leaves, not to mention infinite money.

Myself, it's a step forward I somewhat dread. Our CI/CD isn't exactly the sample template from CircleCI, and we have some big repos with a variety of build targets. Switching to a configuration-heavy build system makes me sweat a bit.

Anyways, curious here. Compare and contrast with other frameworks like React is fine, too often I find the Angular crowd can be a bit myopic that way.