4 ms·
I just prefer batteries-included and fewer decisions. Angular already compiles components at build-time using the Angular CLI, and the new upcoming (November) I
by vfc1 7y ago
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.
- izelnakri 7y agoThere 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.
- davidpolberger 7y agoThat appears unlikely: https://trends.google.com/trends/explore?date=today%205-y&q=ember%20javascript,react%20javascript,angular%20javascript,vue%20javascript https://trends.google.com/trends/explore?date=today%205-y&q=...
- izelnakri 7y agoI 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..
- noncoml 7y ago> > > I give it 1.5 years for ember to pretty much dominate SPA development > > That appears unlikely: https://trends.google.com/trends/explore?date=today%205-y&q=.. https://trends.google.com/trends/explore?date=today%205-y&q=.... > I dont care about fashion too much Do you see the problem here?
- zaphirplane 7y agoI 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
- jakelazaroff 7y agoSomeone 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.
- oldmanhorton 7y agoThe fact that ember doesn't integrate natively with typescript means that probably won't happen...
- howdydoo 7y agoOur 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. [1]: https://guides.emberjs.com/release/getting-started/creating-a-new-model/ https://guides.emberjs.com/release/getting-started/creating-... EDIT: I regret taking the time to write this. Should have checked submission history first…
- izelnakri 7y agoEDIT: I was going to respond to you then I realized your account is created on May 2018, so I decided not to.
- lucd 7y ago?
- cies 7y ago> It is stringly typed. This is a big issue. > - It leans on global state and object mutation 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. EDIT: thanks for typing your reply. :)
- paulddraper 7y agoThe 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 https://github.com/angular/angular/issues/29623
- ggregoire 7y ago> 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.
- winrid 7y agoWhen folks say Angular they aren't including v1. That is called AngularJS. Also, you still configure webpack for your React app right?
- kabes 7y agoBut 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.
- winrid 7y agoReally? I found it very easy to pick up and use. Much simpler to develop with and less mental strain than with AngularJS.