Angular is really a great framework. I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. I also wish the Angular team had just called Angular 2 something else, since the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back. I also understand that people just have different preferences, which is fine, too.
Out of the box, you get: routing with lazy loading, full TypeScript support and a TypeScript-first ecosystem, a great CLI that completely abstracts Webpack and the build process, easy and mostly automatic updates with the CLI, reactivity with RxJS baked-in and supported widely in the community, a great forms library, and, of course, a component-based approach to UI development. The uniformity is a big benefit. It's easy to ramp up on a new Angular project, and there are fewer decisions to make when starting a new one. The built-in parts of the framework are all high quality and an easy bet. There's no need to evaluate different routers, form libraries, HTTP clients, get back up to speed on configuring Webpack only to forget how until next time, etc.
It's also interesting to see the React community move towards some of the things that Angular has been doing for years: embracing TypeScript, extracting business logic to services (or you can call them Hooks), creating injectable shared state (or you can call it Context).
As a long time React developer, I second this. Especially this part:
> There's no need to evaluate different routers, form libraries
These two things have been the bane of my React development experience ever since the days of "flux". Every new React project I start I end up using a different set of libraries, and it's not just me either -- a very experienced React dev I work with just switched our React e-commerce SPA's form library out.
Coming back to Angular after a long time (I used to work with AngularJS) has been like a breath of fresh air. The project I'm using it on is clean, simple, consistent. The code is readable, every form and component works the same way.
If I was building something with less consistent / regular UX then I would still definitely use React, but Angular has really pleasantly surprised me.
I cannot upvote this enough. We have long decided what to do with our painful angularjs application with thousands of beginner mistakes due to people learning a framework while using it.
In the end, we were able to partially migrate to angular 4 at the time using ngUpgrade while still using parts of the application in angularjs 1.6. luckily we started looking into typescript beforehand, making it even easier.
It took us 3 months to completely migrate with only a tiny fraction of legacy bundle of code now still running on angularjs until it's being converted
Since then I have done every major upgrade without fears. I wholeheartedly recommend it for medium-large applications (we have around 50k cloc typescript now).
Angular + Typescript keeps us and our frontend saner than before.
One thing I sorely miss is the performance of my manual webpack / angularjs build, with 15seconds initial build and 1-2 seconds incrementals... It's now at least double with the angular cli, but at least fully managed.
> get back up to speed on configuring Webpack only to forget how until next time
Is this common? Thank goodness i'm not the only one! I keep telling myself next time i'm going to remember to bookmark the billion tabs I open on StackOverflow trying to figure out Webpack configuration, but nope I forget and start from scratch every time.
EDIT: Also I've coded a project in Angular 2 and Angular 4 respectively; I have nothing bad to say about Angular but I still prefer Vue for it's ease of use and friendlier syntax.
> It's also interesting to see the React community move towards some of the things that Angular has been doing for years: embracing TypeScript, extracting business logic to services (or you can call them Hooks), creating injectable shared state (or you can call it Context).
Huh? Hooks are just a way to use component lifecycle in absence of classes (note how React is pushing towards having components as functions as opposed to Angular's components as classes/objects). The new context api is basically just a replacement/improvement of the old context api, which has been in React for ages (React Router was built upon the old context api from get go), but has always been badly documented and considered a private interface, something you were not supposed to touch. As for embracing Typescript, the React community has extensively used static typing with Flow (since this is something that the React team itself uses) for a couple of years, which is very similar to Typescript.
Having CLI generators (such as create-react-app) is definitely something that React borrowed from other communities, but I am not sure whether Ember or Angular was the main influence.
I started working with angular 7 this February and I have to admit the learning curve was steep at first but after the slow start I quickly built my first project and now fully appreciate its power. I also think I am lucky to have taken a stab at it in its current stages, 4+ as I lost my patience for too much noise and too many changes. I also have many praises for Visual Studio Code. The reasons you mentioned are very valid and thats the reason Angular got adopted by enterprises. The uniformity the framework imposes on the projects makes it easy for other devs to jump in, to pick up a project done by somebody else, etc..
For all people who resent SPAs, continue using all jquery and other libs for small or existing projects but do consider a framework like angular if you want to build a stable web application (or a suite of web applications), you will appreciate it after your initial dive.
I also recommend a youtube channel with clear non ADD turorials: search for ‘kudvenkat angular’ on youtube.
This is actually something that bothers me a lot about Angular. Yes, you can extract components, but the process of doing so is a lot more... heavyweight than in React.
In React, I can trivially extract any piece of UI into a stateless functional component in the same file (and later on I can move it to another file for wider reuse if needed). It's just like extracting a method in non-web programming, it's something you do without even thinking about it.
In Angular, that component needs to live in a separate file with a bunch of boilerplate and it needs to be registered in the module. This is OK for big components, but it's enough work that it's not practical to create tiny helper components frequently.
I'm one of the people who've built apps with 1.x, and hasn't ever tried subsequent releases. The transition didn't help matters, but it wasn't the reason why I not only have refused to consider it again, I generally don't even consider working for organizations who list it as a part of their stack.
I tend to find that most libraries/frameworks have a few central notions about what the challenge of developing an application in their technical domain is. As far as I was able to tell from working on two projects, Angular's was that JavaScript applications were not written enough like Java applications, or put another way, there were not enough idioms from a static manifestly typed kingdom-of-nouns class-oriented language being used in a dynamically typed first-class-functions-from-the-start prototypes-too language.
TypeScript has its points, there's things to like about it, but its emphasis does the opposite of persuade me that central philosophy has changed. And while I get that complex applications are complex, and most need some organizing principles and Angular is one (or more) of several attempts to figure this out, this one struck me as... not one I wanted to live inside of, to keep things polite.
If I'm wrong about Angular's central philosophy at this point, I'd be interested to hear how.
I've really enjoyed Angular. Typescript is a no-brainer now, and now that I'm starting to explore RxJS a bit more, it's impressive how powerful it can be once getting over the large learning curve. Being able to subscribe to an observer, and make a web request, and make sure that only the latest request is taken, and being able to do so out of the box is really, really nice.
> I think a lot of people complaining about Angular haven't actually built an app in Angular 4+. [...] the 1 -> 2 transition frustrated a lot of people who jumped ship and never looked back.
I share this impression and feeling. Telling me that most of the stuff I learned for 1 was now useless (or worse, misleading) because 2 was doing everything differently was the first thing that soured me. The _promise_ of regular breaking changes soured me further, and the steep learning curve and high start-up cost sealed the deal.
With Vue, I can have a small proof of concept running without even a compiler in a few minutes. With Angular, I have to comprehend and set up the entire (new) project structure and sit down for hours learning concepts to be able to do anything - all that while remembering that the last time I learned their proprietary concepts, it all changed shortly after, and that the developers _promise_ that it will continue to change under me.
It _probably_ still makes sense for big projects, but damn, they're doing everything to keep people from trying.
The dealbreaker for me is no strongly typed templates. I have built big-ish apps (10-20k loc) in both React/Redux & Angular 6+ and I feel that there is still a lot of unsoundness in Angular 6 that I don't need to worry about with React & TypeScript.
I've been using Angular for a few months now and it's mostly been a good experience. We've been using Angular 7.
My biggest gripe, and this might just be my inexperience, is fighting the change detector to try and ensure reasonable performance when displaying a large number of elements. There are certainly mechanisms to do this but it does seem to take some work.
There's been a huge React/TypeScript community since day one, even before Angular2 was released with TypeScript. The only difference is it's optional with React.
> creating injectable shared state (or you can call it Context)
You get stuck on one project or in one startup for 2 years and Angular has moved 6.5 whole number versions
all while the rest of the job market is confused but kind of tolerating why you jump around jobs so much
if I'm using Angular, my "side project" isn't going to be using a higher version of Angular every 6 months. Its going to be using React or something to see what I'm REALLY missing.
Congratulations on the release! For all the talk of React and Vue I still like the 'batteries-included' approach of Angular.
I mostly do Kotlin in my day job so Angular aligns fairly nicely with the way applications are structured. I don't get the militant need for terseness that's seen in approaches like React Hooks. I also don't need the choice between multiple backwards-incompatible (or competing) routers, nor do I have a need for functionally pure reducers.
So, it may not be sexy, but It Works and that's good enough for me :)
I've been burnt by the non-Euclidian enormity of ExtJS, so I understand the desire for something simpler. On the other hand, when you leave the world of progressive enhancement and widgets (ie. jQuery), you find yourself needing a lot of common infrastructure and picking and matching that can be quite tedious (never mind dependency hell), which is something that react always had issues with -- and that seems to extend fractally, where it's not just MobX vs. React but then what framework/project setup you have on top of each of these choices. And now hooks.
Still, angular always struck me as going slightly too far into Java-land -- my Struts/J2EE/DI battle scars are larger than even my ExtJS mutilations.
And in between you've got VueJS/Vuex, which seems to move a bit too close to react at times, and EmberJs, which seems to move too slowly and/or without many people watching it.
I really want to go back to late-90s desktop UI development sometimes…
But Vue got the batteries included? You have a router included and you can just keep your store as an object or use Vuex for larger applications (if you feel the need for even more structure). All this is according to the official docs, thus included and best practice?
Ah...Kotlin on the backend? Can you share more details about your stack/experience? I've been keeping an eye out for it to crop up in production backend stacks, so I'm very interested in learning how well it works for you...
The main feature among many is differential loading, that will load different versions of the application depending on the capabilities of the browser.
This will avoid installing polyfills without the need for them and reduce the bundle size. There are reports of 40kb reduction in bundle size, which is a lot.
More than that, this release does a lot of preparation work for Ivy in version 9, which will bring a completely new rendering layer.
Also, there is a lot of preparatory work for the introduction of Bazel in the build pipeline, which will bring us fully incremental builds (recompiling only the part of the code that changed and nothing more).
> There are reports of 40kb reduction in bundle size, which is a lot.
It would be for libraries like react or vue that are already small. Angular is still big enough that even after being 40kb slimmer it's still fairly huge (I think the typical build is like ~550+kb).
In my opinion Angular's story is a story of how people invent problems and then valiantly tackle them.
- We want to re-write the whole thing from scratch. In TypeScript.
- And let's use Google's Closure Compiler for JavaScript. Even though it doesn't support TypeScript, modules, or anything, really from non-Google Javascript world (at the time)
- Oh. Then... Let's create a TypeScript to Closure Translator even though TypeScript doesn't let you extend the compiler and TypeScript and Closure are in general not entirely compatible
- Oh, and we use a weird combination of annotations and templates to work, so... we need to compile our templates into TypeScript (which we need to translate to Closure-compatible JavaScript which will then be compiled further down)
- Only the whole process is abysmally slow. Let's implement incremental compilation.
- It's probably still slow, complicated, and error-prone. We know! Let's use Google's Bazel! You know, the tool to build huge codebases in parallel on clusters. Yeah, why not use that to build JS code?
- Only bazel has no support for either Closure, or Javascript, or TypeScript, so we have to build tools and integrations to work with bazel!
I was recently at a Microsoft heavy tech conference and spoke to at least 50 .Net developers. Anyone who also did front end did so in Angular. I was surprised at how popular it is!
Literally just finished a huge re-write of an angular 4 app to latest Angualr 7 today, to revise the UI and improve everything. As I was about to merge it in I see this... time to upgrade!
I wonder what's the story behind delays of Ivy? Can somebody elaborate? It was first scheduled for v6 (don't remember , then for v7, now there is v8 and it's again rescheduled for v9.
I honestly had no idea this was still a thing. We jumped ship to riot.js back around Angular V2 and haven't really thought about another javascript framework since. All of our web tools have been vanilla JS/CSS/HTML with riot tying it all together for the last 3+ years now. It really does seem like the ideal way to compose single page web applications. We do use some 3rd party stuff like codemirror, momentjs, etc., but that's about it. Not even jQuery to be found unless some 3rd party component depends on it.
The advantages of not using someone's framework, language or module system is that we have a direct and stable surface (the DOM) against which to tie things together. Complex web interactions we attempted to do (and failed to do) using Angular directives/components/etc became trivial using our vanilla+riot approach. It almost feels like cheating by comparison, and then you don't care because your incredibly-complex web interaction that involves 5+ vendor libraries and 8 nested API calls just works and is easy to inspect directly.
Obviously, you need some discipline to manage something with less structure around it, but all it takes is a handful of code review sessions to get other developers synced up on how things work in this more 'open' world. There honestly aren't a lot of new things to learn either (there are definitely more things to unlearn coming from Angular). Productivity is also a huge plus. I don't have to spend an hour reviewing the semantics around some Angular construct before I do my work. After a few weeks away from some web project, I can jump directly into the HTML/JS/CSS, crank out a new .html riot tag file and be done with it in less time than it would have taken to re-sync my brain into Angular semantics land.
If you haven't tried riot yet, you should definitely take a look. Once we got our first application working on it and we understood the basics, it felt like we had escaped from frontend jail and could do anything we wanted to. For everyone who views front-end as a mosh pit of chaos and uncertainty, I strongly suggest trying this approach out on a throwaway project when you get some free time.
Angular is too abstract / has a steep learning curve. You need to learn too many design patterns at once (factory, provider, service, singleton, pipes, directives, observable, component, container, dependency injection). Trying something simple is trivial, but trying something more complex is overly difficult.
This feels like an argument made by somebody who has never built a serious project in either, and has instead formed an opinion based on quick glance at the respective syntaxes.
To me, Angular is what HTML and the DOM would look like if they had been designed from the beginning for application development:
- Custom elements backed by controller classes.
- Data-binding and event-binding syntax baked into HTML
- Component style encapsulation, on by default.
React seems far more like a project created by people who dislike front-end development: As I recall the genesis of the project was to replace traditional DOM mutation with a more PHP-esque approach of updating state and re-rendering everything, just as you would do on the back-end.
Apart from being verbose, why is that a bad thing? Spring is used to successfully build massive applications. You can meme about Spring's AbstractFactoryBeans all day, but in the end it does what it's supposed to do.
It feels familiar to Java developers, due to Typescript which is also statically typed (but much better IMHO) and due to the use of decorators and classes, which are an awesome way to describe a component.
Being familiar to a large base of existing developers is a huge feature.
[+] [-] pure|6 years ago|reply
Out of the box, you get: routing with lazy loading, full TypeScript support and a TypeScript-first ecosystem, a great CLI that completely abstracts Webpack and the build process, easy and mostly automatic updates with the CLI, reactivity with RxJS baked-in and supported widely in the community, a great forms library, and, of course, a component-based approach to UI development. The uniformity is a big benefit. It's easy to ramp up on a new Angular project, and there are fewer decisions to make when starting a new one. The built-in parts of the framework are all high quality and an easy bet. There's no need to evaluate different routers, form libraries, HTTP clients, get back up to speed on configuring Webpack only to forget how until next time, etc.
It's also interesting to see the React community move towards some of the things that Angular has been doing for years: embracing TypeScript, extracting business logic to services (or you can call them Hooks), creating injectable shared state (or you can call it Context).
[+] [-] davedx|6 years ago|reply
> There's no need to evaluate different routers, form libraries
These two things have been the bane of my React development experience ever since the days of "flux". Every new React project I start I end up using a different set of libraries, and it's not just me either -- a very experienced React dev I work with just switched our React e-commerce SPA's form library out.
Coming back to Angular after a long time (I used to work with AngularJS) has been like a breath of fresh air. The project I'm using it on is clean, simple, consistent. The code is readable, every form and component works the same way.
If I was building something with less consistent / regular UX then I would still definitely use React, but Angular has really pleasantly surprised me.
[+] [-] alceta|6 years ago|reply
In the end, we were able to partially migrate to angular 4 at the time using ngUpgrade while still using parts of the application in angularjs 1.6. luckily we started looking into typescript beforehand, making it even easier.
It took us 3 months to completely migrate with only a tiny fraction of legacy bundle of code now still running on angularjs until it's being converted
Since then I have done every major upgrade without fears. I wholeheartedly recommend it for medium-large applications (we have around 50k cloc typescript now).
Angular + Typescript keeps us and our frontend saner than before.
One thing I sorely miss is the performance of my manual webpack / angularjs build, with 15seconds initial build and 1-2 seconds incrementals... It's now at least double with the angular cli, but at least fully managed.
[+] [-] y-c-o-m-b|6 years ago|reply
Is this common? Thank goodness i'm not the only one! I keep telling myself next time i'm going to remember to bookmark the billion tabs I open on StackOverflow trying to figure out Webpack configuration, but nope I forget and start from scratch every time.
EDIT: Also I've coded a project in Angular 2 and Angular 4 respectively; I have nothing bad to say about Angular but I still prefer Vue for it's ease of use and friendlier syntax.
[+] [-] azangru|6 years ago|reply
Huh? Hooks are just a way to use component lifecycle in absence of classes (note how React is pushing towards having components as functions as opposed to Angular's components as classes/objects). The new context api is basically just a replacement/improvement of the old context api, which has been in React for ages (React Router was built upon the old context api from get go), but has always been badly documented and considered a private interface, something you were not supposed to touch. As for embracing Typescript, the React community has extensively used static typing with Flow (since this is something that the React team itself uses) for a couple of years, which is very similar to Typescript.
Having CLI generators (such as create-react-app) is definitely something that React borrowed from other communities, but I am not sure whether Ember or Angular was the main influence.
[+] [-] onemoresoop|6 years ago|reply
For all people who resent SPAs, continue using all jquery and other libs for small or existing projects but do consider a framework like angular if you want to build a stable web application (or a suite of web applications), you will appreciate it after your initial dive. I also recommend a youtube channel with clear non ADD turorials: search for ‘kudvenkat angular’ on youtube.
[+] [-] ripley12|6 years ago|reply
This is actually something that bothers me a lot about Angular. Yes, you can extract components, but the process of doing so is a lot more... heavyweight than in React.
In React, I can trivially extract any piece of UI into a stateless functional component in the same file (and later on I can move it to another file for wider reuse if needed). It's just like extracting a method in non-web programming, it's something you do without even thinking about it.
In Angular, that component needs to live in a separate file with a bunch of boilerplate and it needs to be registered in the module. This is OK for big components, but it's enough work that it's not practical to create tiny helper components frequently.
[+] [-] wwweston|6 years ago|reply
I tend to find that most libraries/frameworks have a few central notions about what the challenge of developing an application in their technical domain is. As far as I was able to tell from working on two projects, Angular's was that JavaScript applications were not written enough like Java applications, or put another way, there were not enough idioms from a static manifestly typed kingdom-of-nouns class-oriented language being used in a dynamically typed first-class-functions-from-the-start prototypes-too language.
TypeScript has its points, there's things to like about it, but its emphasis does the opposite of persuade me that central philosophy has changed. And while I get that complex applications are complex, and most need some organizing principles and Angular is one (or more) of several attempts to figure this out, this one struck me as... not one I wanted to live inside of, to keep things polite.
If I'm wrong about Angular's central philosophy at this point, I'd be interested to hear how.
[+] [-] mike1o1|6 years ago|reply
[+] [-] DenisM|6 years ago|reply
Could have called it "Rectangular". Opportunity, missed.
[+] [-] tgsovlerkhgsel|6 years ago|reply
I share this impression and feeling. Telling me that most of the stuff I learned for 1 was now useless (or worse, misleading) because 2 was doing everything differently was the first thing that soured me. The _promise_ of regular breaking changes soured me further, and the steep learning curve and high start-up cost sealed the deal.
With Vue, I can have a small proof of concept running without even a compiler in a few minutes. With Angular, I have to comprehend and set up the entire (new) project structure and sit down for hours learning concepts to be able to do anything - all that while remembering that the last time I learned their proprietary concepts, it all changed shortly after, and that the developers _promise_ that it will continue to change under me.
It _probably_ still makes sense for big projects, but damn, they're doing everything to keep people from trying.
[+] [-] cetra3|6 years ago|reply
[+] [-] bpicolo|6 years ago|reply
That's a great thing about Vue, too. vue-router and vuex are well-designed and well-supported / integrated. Makes a huge difference.
[+] [-] bpye|6 years ago|reply
My biggest gripe, and this might just be my inexperience, is fighting the change detector to try and ensure reasonable performance when displaying a large number of elements. There are certainly mechanisms to do this but it does seem to take some work.
[+] [-] rubicon33|6 years ago|reply
I built my business' web application (and android app) using Angular. It works so well both in the native browser, and in an Android wrapper.
My ONLY complaint about Angular is the initial load time.
[+] [-] ng12|6 years ago|reply
There's been a huge React/TypeScript community since day one, even before Angular2 was released with TypeScript. The only difference is it's optional with React.
> creating injectable shared state (or you can call it Context)
Or Flux/Redux?
[+] [-] rolltiide|6 years ago|reply
You get stuck on one project or in one startup for 2 years and Angular has moved 6.5 whole number versions
all while the rest of the job market is confused but kind of tolerating why you jump around jobs so much
if I'm using Angular, my "side project" isn't going to be using a higher version of Angular every 6 months. Its going to be using React or something to see what I'm REALLY missing.
[+] [-] royjacobs|6 years ago|reply
I mostly do Kotlin in my day job so Angular aligns fairly nicely with the way applications are structured. I don't get the militant need for terseness that's seen in approaches like React Hooks. I also don't need the choice between multiple backwards-incompatible (or competing) routers, nor do I have a need for functionally pure reducers.
So, it may not be sexy, but It Works and that's good enough for me :)
[+] [-] mhd|6 years ago|reply
Still, angular always struck me as going slightly too far into Java-land -- my Struts/J2EE/DI battle scars are larger than even my ExtJS mutilations.
And in between you've got VueJS/Vuex, which seems to move a bit too close to react at times, and EmberJs, which seems to move too slowly and/or without many people watching it.
I really want to go back to late-90s desktop UI development sometimes…
[+] [-] cjblomqvist|6 years ago|reply
[+] [-] microcolonel|6 years ago|reply
It's a different story when your application is huge and mostly made of batteries. ;- )
[+] [-] bdcravens|6 years ago|reply
[+] [-] rufugee|6 years ago|reply
[+] [-] vfc1|6 years ago|reply
The main feature among many is differential loading, that will load different versions of the application depending on the capabilities of the browser.
This will avoid installing polyfills without the need for them and reduce the bundle size. There are reports of 40kb reduction in bundle size, which is a lot.
More than that, this release does a lot of preparation work for Ivy in version 9, which will bring a completely new rendering layer.
Also, there is a lot of preparatory work for the introduction of Bazel in the build pipeline, which will bring us fully incremental builds (recompiling only the part of the code that changed and nothing more).
[+] [-] preommr|6 years ago|reply
It would be for libraries like react or vue that are already small. Angular is still big enough that even after being 40kb slimmer it's still fairly huge (I think the typical build is like ~550+kb).
[+] [-] marshallant|6 years ago|reply
[+] [-] dmitriid|6 years ago|reply
- We want to re-write the whole thing from scratch. In TypeScript.
- And let's use Google's Closure Compiler for JavaScript. Even though it doesn't support TypeScript, modules, or anything, really from non-Google Javascript world (at the time)
- Oh. Then... Let's create a TypeScript to Closure Translator even though TypeScript doesn't let you extend the compiler and TypeScript and Closure are in general not entirely compatible
- Oh, and we use a weird combination of annotations and templates to work, so... we need to compile our templates into TypeScript (which we need to translate to Closure-compatible JavaScript which will then be compiled further down)
- Only the whole process is abysmally slow. Let's implement incremental compilation.
- It's probably still slow, complicated, and error-prone. We know! Let's use Google's Bazel! You know, the tool to build huge codebases in parallel on clusters. Yeah, why not use that to build JS code?
- Only bazel has no support for either Closure, or Javascript, or TypeScript, so we have to build tools and integrations to work with bazel!
And the quests just keep popping up.
[+] [-] pier25|6 years ago|reply
With some exceptions, there is really no benefit in making a SPA but there are many drawbacks.
I don't say this lightly. I used AngularJS in 2015 and since then I've been making SPAs in React, Vue, and Inferno + Mobx.
[+] [-] holografix|6 years ago|reply
[+] [-] Sahhaese|6 years ago|reply
[+] [-] FiniteLooper|6 years ago|reply
[+] [-] zihotki|6 years ago|reply
[+] [-] bob1029|6 years ago|reply
The advantages of not using someone's framework, language or module system is that we have a direct and stable surface (the DOM) against which to tie things together. Complex web interactions we attempted to do (and failed to do) using Angular directives/components/etc became trivial using our vanilla+riot approach. It almost feels like cheating by comparison, and then you don't care because your incredibly-complex web interaction that involves 5+ vendor libraries and 8 nested API calls just works and is easy to inspect directly.
Obviously, you need some discipline to manage something with less structure around it, but all it takes is a handful of code review sessions to get other developers synced up on how things work in this more 'open' world. There honestly aren't a lot of new things to learn either (there are definitely more things to unlearn coming from Angular). Productivity is also a huge plus. I don't have to spend an hour reviewing the semantics around some Angular construct before I do my work. After a few weeks away from some web project, I can jump directly into the HTML/JS/CSS, crank out a new .html riot tag file and be done with it in less time than it would have taken to re-sync my brain into Angular semantics land.
If you haven't tried riot yet, you should definitely take a look. Once we got our first application working on it and we understood the basics, it felt like we had escaped from frontend jail and could do anything we wanted to. For everyone who views front-end as a mosh pit of chaos and uncertainty, I strongly suggest trying this approach out on a throwaway project when you get some free time.
[+] [-] pier25|6 years ago|reply
I wanted to try Riot but then I saw they were working on v4 with the Simulacra guy and decided to wait until the new version.
[+] [-] visarga|6 years ago|reply
[+] [-] revskill|6 years ago|reply
[+] [-] arnvald|6 years ago|reply
[+] [-] sheeshkebab|6 years ago|reply
[+] [-] stupidcar|6 years ago|reply
To me, Angular is what HTML and the DOM would look like if they had been designed from the beginning for application development:
- Custom elements backed by controller classes. - Data-binding and event-binding syntax baked into HTML - Component style encapsulation, on by default.
React seems far more like a project created by people who dislike front-end development: As I recall the genesis of the project was to replace traditional DOM mutation with a more PHP-esque approach of updating state and re-rendering everything, just as you would do on the back-end.
[+] [-] royjacobs|6 years ago|reply
[+] [-] vfc1|6 years ago|reply
Being familiar to a large base of existing developers is a huge feature.
[+] [-] vikingcaffiene|6 years ago|reply
[+] [-] dio123|6 years ago|reply
[+] [-] rafaelvasco|6 years ago|reply
[+] [-] Tade0|6 years ago|reply
[+] [-] adl|6 years ago|reply
[+] [-] i_can_c_sharp|6 years ago|reply
[+] [-] ousta|6 years ago|reply
[deleted]
[+] [-] sungju1203|6 years ago|reply
[deleted]
[+] [-] bricss|6 years ago|reply
[deleted]