I just prefer batteries-included and fewer decisions. Angular already compiles components at build-time using the Angular CLI, and the new upcoming (November) Ivy engine is going to produce bundles that will rival in size with any framework.
The webpack build that the Angular CLI uses internally is completely transparent, you don't have to know Webpack at all. Just do ng build --prod and you have your optimized bundles will all the bell and whistles.
Webpack is even going to be replaced by Bazel but we won't even notice it, all we have to do is ng update and live goes on the next day after the release.
The Angular ecosystem with the Angular CLI is just so stable and complete, with hardly any API changes in years, it's just a joy to work with. The CLI even integrates with Sass and other CSS processors.
You can really focus on the application, and forget tooling. I think the take of Angular on batteries-included tooling & their take on incremental upgrades are such a huge advantage over other ecosystems, AFIK nothing else comes even close.
There is something close, even better, when overall API design/architecture is considered, that is ember.js. Check ember-cli/embroider which angular-cli initially forked from. I give it 1.5 years for ember to pretty much dominate SPA development, In the last two years some people were laughing at me, now Im laughing at them.
Our company trialed Ember this year alongside React, Angular, and Vue for a new SPA. Ember was the worst of the bunch:
- It is stringly typed. All over the place you're globally registering names as strings (or worse, using strings that implicitly resolve to filenames). You'll write `store.createRecord('mymodel')` instead of just importing things using standard ECMAScript imports.[1] This means static analysis is out the window, which makes it labor-intensive to find usages or do even simple refactors like renames.
- It leans on global state and object mutation way too much, instead of using functional state updating. This was the way older frameworks like Backbone, YUI, etc worked. Web development is moving away from this paradigm, and for good reason.
- Static typing support is non-negotiable in 2019 (and 2015 for that matter, but I digress). Support in Ember is just not there, and I don't see much promise for the future either. React and Angular have had good support for Typescript and/or Flow for a good 5 years now.
- One high point for Ember: the in-browser testing beat the pants off any of the other frameworks. We ended up going with React/Jest/Puppeteer, but this meant we (meaning, I) had to write 150 lines of boilerplate that Ember gives you for free.
Overall working in Ember honestly felt like being transported back in time by 10 years. I guess if you're a solo dev it's easy to whip up a quick demo that seems fine, but you'll hit the wall very quickly where the project becomes write-only. I think it's unlikely a brand new build system, no matter how fancy, can make up for these architectural problems.
I dont see this as a problem, it's an implementation details. If the software works well (fast enough) and provides a nice API, I dont care much about the internals.
> - Static typing support is non-negotiable in 2019
Agreed, but I'd like to combine this point with the first.
There are 3 places where one can say ember is stringly typed:
1- controller/service dependency injection(no more with octane).
2- ember data API(store.createRecord(modelNameString) and serializerFor(modelNameString)). I don't mind it results in less imports and API might change in the future.
3- this.owner.lookup('$abstractionName:$fileName') => I like this one. It removes the need for an extra line of import code and import path could have been very verbose for something far away in dependency tree.
Therefore, I don't think it is a serious issue anymore.
Majority of the ember source code and internal packages are in typescript and there is a good typescript support for app development via addons. As a person who wrote an ember-cli alternative, I can say with confidence that you can build ember apps in typescript. Despite all that, the type analysis performance overhead/cost of typescript compiler today isn't worth the type benefits for really big SPAs yet in my opinion. I think instead those frontend teams should optimize their hiring and mentoring practices until we have a very fast typescript compiler.
Addon/package authors can write their code in typescript and make it work with JS or TS ember application code today.
TLDR for the ones who made weak typescript arguments here against ember.js:
Don't be a hypester and claim certain things without making a good research.
I dont care about fashion too much, I care about code, maintenance and community quality more. It is in my opinion the only way to build good and sustainable development teams in the current environment. Contrarian opinion I know..
I don’t, what’s the relationship between having an opinion in the minority and not caring for fashion (chasing hype)
For something to dominate it needs some hype but having hype doesn’t lead to dominating the market
Someone who "give[s] it 1.5 years for ember to completely dominate SPA development" and is laughing at people who doubted it clearly cares about fashion.
> Angular [...] You can really focus on the application
I don't know about the newest versions but I have to disagree for Angular 1, the framework was so badly designed and overengineered that my team and I had to constantly check the doc to remember how to write x or y or what were the best practices to do z.
React does less than Angular but it's way more intuitive and straightforward. The doc is a one-time read.
> forget tooling [...] The webpack build that the Angular CLI uses internally is completely transparent [...] nothing else comes even close
React has create-react-app. Vue probably has something similar. Same for Ember. Last time I had to setup a build pipeline myself was like 3 years ago.
But if he thought angularjs was over engineered, he will definitely find angular over engineered. They improved a lot of things, but simplicity isn't one of them.
The problem I am running into with Angular is there is no middle ground.
On one hand, you can yarn install and ng create and you've got a project.
On the other hand, the largest software company on earth uses it.
In the middle is a wasteland. I've worked with it for years and have been waiting for Google to document to the angular compiler (angular/angular not the angular/angular-cli with a million webpack presets). To this day there remains zero documentation other than source code. https://github.com/angular/angular/issues/29623
The webpack build that the Angular CLI uses internally is completely transparent, you don't have to know Webpack at all. Just do ng build --prod and you have your optimized bundles will all the bell and whistles.
Webpack is even going to be replaced by Bazel but we won't even notice it, all we have to do is ng update and live goes on the next day after the release.
The Angular ecosystem with the Angular CLI is just so stable and complete, with hardly any API changes in years, it's just a joy to work with. The CLI even integrates with Sass and other CSS processors.
You can really focus on the application, and forget tooling. I think the take of Angular on batteries-included tooling & their take on incremental upgrades are such a huge advantage over other ecosystems, AFIK nothing else comes even close.