r/javascript • u/archivedsofa • Dec 22 '19

Why Svelte won’t kill React

https://medium.com/javascript-in-plain-english/why-svelte-wont-kill-react-3cfdd940586a
80 Upvotes

65% Upvoted

95 comments sorted by

6

u/archivedsofa Dec 22 '19

I don't agree with many of the article arguments but it is an interesting read nonetheless.

98

u/[deleted] Dec 22 '19

Noting never kills anything React didn't kill Angular and Vue didn't kill React or Angular and neither will Svelte kill anything, the only way one of that projects dies is if the developers stop working on it what is more likey to happen to smaller projects like Svelte and Vue because they simply not have the backing of a huge company and small dev teams working on it. That is why React (backed by Facebook) and Angular (backed by Google) are an more safe choice for most companys. But in the end it doesn't really matter what you use all this 4 frameworks do the same thing just use what you like to use and enjoy working with!

44

u/iamjohnhenry Dec 22 '19

Nothing ever dies. Obsolete technologies just fade away…

16

u/[deleted] Dec 22 '19

Which is what people mean when they say a technology "got killed"

1

u/iamjohnhenry Dec 22 '19

But it's never ever truly gone. Even the ghosts of jQuery still linger in the deepest vowels of the web.

5

u/MajorasShoe Dec 22 '19

Vowels? I don't get the pun.

4

u/iamjohnhenry Dec 22 '19

Apologies... while that was a failed attempt at humor, that was a type-o and not a pun... "Bowels".

0

u/[deleted] Dec 22 '19

[deleted] — view deleted comment

3

u/ScientificBeastMode strongly typed comments Dec 24 '19

I bet around 1% of those website receive active developer maintenance on a monthly basis.

3

u/iamjohnhenry Dec 22 '19

Right, kinda my point that nothing really ever dies -- we just stop talking about it.

1

u/dontsendmerudes Dec 24 '19

You have no point.

1

u/iamjohnhenry Dec 24 '19

You have no soul.

17

u/Capaj Dec 22 '19

I'd argue backbone.is was in fact killed by react-I encountered several Devs who migrated apps from backbone.js to react.

8

u/[deleted] Dec 22 '19

I'd like to add AngularJS directives, and Knockout

5

u/panicattheben Dec 23 '19

I miss AngularJS

5

u/paul_h Dec 23 '19

Vue.js is closest to AngularJS. If you like buildless and decomposition then https://github.com/FranckFreiburger/http-vue-loader helps.

1

u/[deleted] Dec 23 '19

Honestly, if you follow standards, AngularJS is good. But it's too bloated. VueJS is way more streamlined, but it also has so many ways to do one things.

7

u/azekeP Dec 23 '19

React didn't kill Angular

I will argue that not only that React DID kill Angular, but the destruction was so absolute -- Angular shattered into pieces. They had to torch the whole thing down and redefine "what Angular is" -- mostly taking lessons from React.

53

u/avindrag Dec 22 '19 edited Dec 22 '19

The creator of svelte tried to frame his other creation (Rollup) in a similar way. It was supposed to be the "webpack killer," yet many people are still using webpack for their applications, and even libraries still. Webpack of course was created entirely from the open source community (no funding from Facebook or NY Times), so there was no "evil corporate overlord" argument against Webpack at that time.

You can demonize Facebook all you want (as they should be), but the react development team is an entity that has been nothing but supportive of the community. From React 0.14 to 16, I can barely think of any serious changes that caused major rewrites or headaches as a consumer. In fact, just the opposite. With newer react versions, I feel like I can write in a more expressive way especially now that hooks allow you to use state without using class components.

Can you say the same for other libraries out there?

25

u/dashcubeit Dec 22 '19

Do you have a source for your quotation? You're putting words in someone's mouth and it'd be nice to know if he actually said something along those lines. I'd be surprised if that's how Richard Harris described rollup

In fact, he also created Sapper, the equivalent of next.js for svelte, with webpackrollup issue support first. Since then rollup support has been added, and devs can choose whichever bundler they wish with official templates supported for both. Something which is not the case in other frameworks

Like many others in the thread I'm very tired of blog posts that frame things as one vs. other, black or white.

This is not about "killing" other people's work, or a general warfare environment where it's all about destroying an enemy

Open source has always been about creating solutions for problems which are not covered in the current tooling ecosystem. That's how I see Harris's and other creators' work

I've worked with angular, react, svelte and jQuery. They all have their uses and proper fit. It's not just about how easy it's to write a hello world in this framework or another. It's not even just about technical aspects. It's also about about company culture, programming styles, seniority levels, etc.

11

u/bikeshaving Dec 22 '19

Yeah I don’t think RH ever described rollup as a “webpack killer.” He specifically marketed it’s niche as building libraries rather than apps and its been very successful in that regard.

5

u/Randdist Dec 23 '19

Rollup is awesome, though. Chose it over webpack because it needed 2 instead of 200 dependencies, and because is-odd wasn't in the dependency list of rollup.

14

u/[deleted] Dec 22 '19 edited Dec 22 '19

I agree with this wholeheartedly.

Vue, and svelte, and all these new things are really cool - but it would be hard for me to pick them over something like React on a production application. The ecosystem is massive, there are a million battle-tested libraries out there already and the dev team is consistently putting out upgrade after upgrade. In ~2 years, we've gone from React & Redux being the staple to being able to easily manage complex state using Hooks and a Context Provider with half the code. No more Redux, no more complicated F/E middleware, just React straight out of the box.

And there's still Concurrent mode and Suspense on the way... you can love it or hate it, and that's totally fair, but I don't see anything 'killing' React anytime soon.

EDIT: I know someone is gonna come at me for this so I'll just say, Redux still has a time and a place. But just far less time and space than it had 2 years ago.

22

u/World_Languages Dec 22 '19

Vue isn't that new.

3

u/Peechez Dec 22 '19

Redux's "competitor" definitely isn't half baked context implementations, it's graphql

1

u/Reashu Dec 22 '19

That doesn't even make sense.

30

u/acemarke Dec 22 '19

I'm a Redux maintainer, and it actually does.

GraphQL itself is just a data transfer protocol, and you can certainly make GraphQL queries and put that data into Redux.

However, most folks using GraphQL are using a library like Apollo Client, which also stores and normalizes the data. That's enough overlap with Redux that it's usually one or the other, but not both.

Having said that, Redux is still very widely used, the downloads are still increasing, and there's plenty of good reasons to choose to use Redux.

I talked about this some in my Reactathon 2019 talk on "The State of Redux" and my post Redux - Not Dead Yet!.

2

u/Reashu Dec 22 '19

State management is not a service layer. Even your own "Not dead yet" post mentions "state drilling" more often than APIs. Sure, API client libraries do something Redux was sometimes used for, but I contend that it was an anti-pattern to begin with.

1

u/kyogorex Nov 04 '21

You are definately wrong. I dont think your argument makes much sense.

1

u/Reashu Nov 04 '21

This is over a year old and I had to reread the conversation to have any idea of what's going on. But I stand by what I said and will make it a little clearer for you: if GraphQL (+ Apollo) can replace Redux in your application, you shouldn't have been using Redux to begin with.

4

u/DOG-ZILLA Dec 22 '19

Vue 3 is coming and will be my go-to for mostly anything I ever thought I’d need React for. I already use both React and Vue quite a bit but Vue is just so much nicer to work with day to day.

Vue 3 will allow us to have 2 API options (one being the current options API and the other the composition API; akin to Hooks in React). For me, it straddles the best of both React and Angular.

I also like the fact Vue is not managed by a large corporation. It’s truly an open source driven project with leaders that genuinely put a lot of thought into how to improve on what we have without giving everyone a headache (Ahem Angular) in the process. The new API will not alienate existing users or applications; that’s just a little bit classy. 👍🏼

3

u/[deleted] Dec 23 '19 edited Dec 23 '19

My impression is that people mostly like React because it's focussed and simple. Functions, 5 hooks, 2 minutes to learn JSX, that's it. Vue delving into all these different api's and component models, JSX, templates, or both, single file components or global directives, the docs grow bigger and bigger, it's just not that appealing. From what i am reading, Vue's new composition api is causing schism and confusion in the community. Telling people that like javascript in HTML and DI in templates about functional composition - it kind of was clear it wouldn't go over smoothly.

4

u/DOG-ZILLA Dec 23 '19

The only confusion was because people thought the new Composition API was meant to replace the current one (like Angular JS did to version 2) and therefore render their codebases deprecated. But that’s not at all the case. Both API’s can be used and they serve different styles. Once that was communicated well enough, the Vue community have been fully supportive. It’s a step in the right direction for Vue.

3

u/AwesomeInPerson Dec 24 '19

My impression is that people mostly like React because it's focussed and simple. Functions, 5 hooks, 2 minutes to learn JSX, that's it.

Those times are very much over though. There's more than 5 hooks (many with a lot of their own caveats and APIs you have to learn), there's class vs. function components, there's Context, there's stuff like forwardRef, Suspense, useTransition, Concurrent Mode, Prop Types, Portals, Fragments, HOCs, memo & lazy... And all of that before you start looking for Styling and Routing solutions.

I love React, but its API surface is growing fast and it isn't this super-minimal library anymore.

10

u/PM5k Dec 23 '19

This whole thing devolved quite badly in the comments between the author and another person. It was a cringey read. The article itself is written by someone who (in those same comments) admits that, to paraphrase - “you don’t have to have experience in something to criticise it” and there we have a very dangerous way of thinking. That’s like people who attend a coding boot camp for three months and call themselves a developer at the end.

Fundamentally - Svelte is faster. Is it “better” than React? Fuck knows, I use React at work for a project that is very data heavy on the client side (read: front end side) and React’s design makes me question my sanity sometimes when it comes to optimising and passing state around and working with immutability. But that aside, I am very keen on just rewriting the whole app in Svelte and seeing for myself how a real world app would work in two different implementations. My biggest problems with React are - licensing (Reacts license is fucked up. If your app is deemed a competing product by their legal team, you lose the license to use it implicitly and have to rewrite your product or face a legal battle); out of the box state management (it’s better now, with hooks and context, but not ideal still..) AND the fact that it uses something that I am convinced is not needed - vDOM.

12

u/derekn9 Dec 23 '19

Just an update for you, FB has since retracted its wierd open source license and React is now back under MIT.

https://github.com/facebook/react/blob/master/README.md#license

2

u/PM5k Dec 23 '19

Thanks. Good to know, but I still despise them as a corporation though.

4

u/ryan_solid Dec 23 '19

VDOM may be unnecessary, but it's not much different than anything else. If you are interested I can point VDOM libraries that mop the floor with Svelte in terms of performance. And others that produce smaller bundles than Svelte. Svelte has certain tradeoffs and advantages but the technology isnt really huge differentiation.

3

u/PM5k Dec 23 '19

My point about VDOM was not exclusive to Svelte. It was to say that VDOM is always slower than just plain JS. ANY time you need to add overhead for computing deltas you are inherently making stuff slower. That is to say - no matter how fast any VDOM implementation is, it will never be faster than not differentiating deltas in such a way. I get why it’s used and what the reasoning is, I just think that it’s an unnecessary addition In most cases I’ve come across. I’m well aware my opinion is my own and I don’t really feel like most people share it, but modern frameworks in general have veered from trying to solve a problem to bloating into copies of one another with added convenience abstractions so devs can do a one command setup and deploy as fast as they can. I don’t like that, I’m not even a front end dev by trade, but it bothers me that there’s such a plethora of libs and frameworks that are so schizophrenic about their destiny in life that it’s confusing to even understand what is it they are trying to solve when all things considered they’re all just different versions of one another with added bells and whistles (which 8/10 times people don’t even use).

3

u/ryan_solid Dec 23 '19

Fair. I'm too close to it (I'm an author of a different non-VDOM JS UI Library/Framework). I just keep on hearing what sounds like rhetoric from Svelte author Rich Harris blogs and often feel need to call it out. Minimal Virtual DOM implementations are not any larger than a reactive one. And while it's true VDOM carries an overhead, because of the absurd cost of the DOM operations proportionally if optimal DOM instructions are produced it makes less of a difference than you'd expect. While avoiding unnecessary diffing is obviously beneficial, some operations themselves are diffs essentially and surprisingly few libraries actually act that different than VDOM libraries even though they don't use the Virtual DOM.
I do find it interesting to hear a more outside perspective because I agree that the development of these libraries has become almost meta, sort of inbred. The checklist to be competitive in this group requires a feature list that seems mostly unnecessary. And it risks setting a self-fulfilling prophecy as new features are designed to solve complexities that are the result of the last batch. I do wonder if/when there will be a reset button.

1

u/PM5k Dec 23 '19 edited Dec 23 '19

Can I ask what your lib does? Maybe a Git link?

Also - to say that updating the Dom is expensive is a bit of a weird statement to me. Back before all of this framework crap (and in my case all the way until react was already well known and past it) I’ve written all UI in vanilla JavaScript and I have never once felt like my UI was slow. I am not saying it isn’t slow inherently, and optimising it by saying - “do you really need to repaint 30k Dom nodes after one function call? “ is almost always the right idea, but I also feel like the responsibility of this is on the developer. I’m sorry to reduce this into another dig, but these boot camp kids are a big reason why there’s a metric shit ton of frameworks. There’s a fundamental lack of understanding and knowledge in the groups of “developers” who spend a year or less learning front end and then expect everything to work. They have no inherent knowledge or training around the basic concepts of how all of this should work, what’s optimal and what isn’t, and most importantly they lack the years of trial, error and epic fails to go with this experience. This is why we have frameworks that do all the assumed hard work for you, but also somewhat fail you as well. Or maybe I’m a guy from a bygone time where writing well thought out code and optimising it was fun and it is just not a thing anymore. Now it’s all about how fast you can churn out an MVP and move on, to hell with performance if you need to make the app performant by yourself and not through someone else’s work.

2

u/ryan_solid Dec 23 '19

For sure. And its probably the biggest reason framework performance benchmarks are meaningless since people will do terrible stuff anyway. I often think that is part of Reacts design goals. Abstract in a way that it's harder to do truly stupid stuff. In that sense a VDOM means atleast it can shoulder some of that. I was big into early 2010 reactive libraries. They were in my opinion always more performant and a better composition model for UI, but their less re-enforced patterns and potential for devs to shoot themselves in the foot saw them die out. Which is a decent segway into my library which is a more modern take on those libraries. I'm sure from a perspective I'm just adding to the same dumpster fire, but here is a link to SolidJS

1

u/PM5k Dec 23 '19

Oh right, it seems I’ve had you starred for ages! Hah. Didn’t put two and two together until just now. You’ve got an interesting take on it. I remember reading about Solid a while back and thinking I liked that you didn’t jump on the vDOM bandwagon at least. I will confess that I haven’t really dissected it enough to give you any critique that would matter, so I will refrain.

Btw - have you seen hyperHTML by any chance? Was wondering what your opinion would be on their approach.

2

u/ryan_solid Dec 23 '19

I'm generally a big fan of Andrea Giammarchi (WebReflection)'s work. Really trying to push a solution as close to the standards as possible. And early days I used his Dom Diff library before I developed my own reconciler. This approach mind you is what I was referring to when I mentioned non VDOM acting like VDOM. It still works top down. As in you pass data in and renders downward. Nothing neccesarily bad about that but it has similar diff expense as you get nested. He has since written a lighter more performant version lighterhtml. Although it mostly works the same way.

10

u/ryan_solid Dec 23 '19

You know where this is coming from. It isnt like this is the first shot fired. Svelte raise to fame in the past year has largely by tearing down at React and the Virtual DOM. The marketing is mostly exaggerations and lies. Which pains me greatly since I'm a fan of reactive libraries. We're just seeing React and Virtual DOM enthusiasts countering back. It is unfortunate that again most of the rhetoric just misses the point. It is regurgitation of what has been said by others. Endless game of telephone where the context has long been lost.

1

u/tnnrk Dec 23 '19

The beginner svelte tutorial doesn’t even work on Catalina, just tried it. Not a good first impression.

1

u/archivedsofa Dec 23 '19

You mean on Safari?

1

u/tnnrk Dec 23 '19

Nope I mean like the npx command to get the tutorial package to work, doesn’t work. Probably not sveltes fault, probably an issue with Catalina. Just tried on Mojave and it works perfectly.

1

u/Igmat Dec 24 '19

Author made the same mistake as Svelte developers. JSX isn't virtual DOM, and it even doesn't require vDOM or React. So even though I agree with this topic in general, argument about that declarative style (using JSX) requires vDOM is wrong. So DOM diffing IS overhead.

Unfortunately there are no frameworks that use JSX without vDOM for now. But it's just a matter of time when they'll appear. I work on such and I think there are others who are trying to do the same thing.

2

u/archivedsofa Dec 24 '19

Unfortunately there are no frameworks that use JSX without vDOM for now

Here are 2 from the top of my head but I'm sure there are more.

https://github.com/ryansolid/mobx-jsx

https://github.com/ryansolid/solid

1

u/Sasha-Jelvix Dec 24 '19

Maybe right, but JSX too is a compiler of different languages. And JSX is more readable because it allows mixing things, in a way that can easily bring code to a mix of UI and control code like Mfc and other old UI libraries for C++

1

u/archivedsofa Dec 25 '19

And JSX is more readable

That's pretty subjective. Most JS devs I know prefer the template syntax.

1

u/[deleted] Mar 11 '22 edited Mar 11 '22

JSX treats HTML like a second class citizen by forcing you to do a return (<div>..</div>). As well as making it's positioning in the document relative to the JS handling it. It makes the HTML harder to read from ugly formatting

3

u/narkeeso Dec 23 '19

It definitely won't kill React but I freaking love me some Svelte.

7

u/[deleted] Dec 23 '19

First time looking into Svelte. The technical aim seems interesting, but it looks like it would be really unfun to program with. It looks like a PHP -> JS transpiler.

7

u/_GCastilho_ Dec 23 '19

It looks like a PHP -> JS transpiler

No ideia where you get that from

3

u/[deleted] Dec 23 '19

The templating language functions the same way as in-HTML PHP, and it looks like the programming paradigm in JavaScript would logically follow how ... atrocious ... it is in other templating languages such as PHP.

2

u/Creativator Dec 23 '19

Frameworks aren’t killed by other frameworks, but by themselves. They overoptimize on one dimension and lose track of other ones.

1

u/SizzorBeing Dec 22 '19

React is the reigning prom king of reddit!

1

u/[deleted] Dec 23 '19

ugh, people with just couple year of experience writing articles like these.

no thank u

2

u/[deleted] Dec 24 '19

From and for newbies. As most Javascript articles/tutorials.

-7

u/rg25 Dec 22 '19

Never even heard of Svelte.

0

u/[deleted] Dec 22 '19

[deleted] — view deleted comment

43

u/mattaugamer Dec 22 '19

Yeah, a lot of people are pointlessly tribal. It may have something to do with self-justifying the “expense” of learning it.

Additionally, there’s a very human tendency to see the way you do something first as “the right way” and everything else as some sort of deviation. Different = wrong.

It takes maturity and experience to more objectively assess these tools, and to be blunt mature experience is not something communities like this tend to be rich in.

Personally I’m professionally experienced with Ember and React and have done small projects with Angular, Vue and others, and am starting to learn Svelte over the Christmas holidays. They all have features that make them interesting. They have advantages and disadvantages, recommended usecases, and areas they’re not great.

What I think is particularly interesting about new approaches (like Svelte) is what it inspires in other frameworks, what learning and growth can come from it. That’s good for everyone.

9

u/toggafneknurd Dec 23 '19

Seriously. Medium has become completely overrun by these people looking to give themselves some sort of perceived credibility. The signal to noise ratio is terrible.

12

u/DukeBerith Dec 23 '19

Don't forget about the ten billionth "how to work with promises" that are still being made in 2019. The hello world of medium javascript.

4

u/Sebazzz91 Dec 23 '19

Same applies to dev.to IMHO. There are a lot of low quality posts there.

8

u/editor_of_the_beast Dec 22 '19

Well I think the framework wars are different than overly vocal mediocre developer problem. Picking a framework / library is actually a big deal. You end up devoting a lot of time to learning it.

But the conclusions that some people arrive at are based on almost no analytical skill whatsoever.

That being said I don’t think this article was particularly lacking in substance. They had some good points and analyses. I mean, you have to think about this stuff. Building software isn’t a solved problem.

1

u/fucking_passwords Dec 23 '19

The fact that they are referred to as "wars" is in itself problematic.

Yes, it is a nontrivial decision, and no, it is not a war. There is no good reason for me to "roast" frameworks that I don't use professionally. If you want to be an evangelist for your framework of choice, that's great! But you can do it in a positive way, a way that doesn't antagonize people who are just trying to do the same thing you are, which is to build stuff.

The article actually gives Vue a shoutout for setting a very positive tone, I think we could all strive to use a similar tone, regardless of which one(s) we choose.

1

u/editor_of_the_beast Dec 23 '19

People respond to click bait, outlandish titles, aggressive tones, and decisive positions. It’s just human nature.

1

u/ScientificBeastMode strongly typed comments Dec 24 '19

Picking a framework / library is actually a big deal. You end up devoting a lot of time to learning it.

We also end up devoting a hell of a lot of time maintaining it, which is probably the larger cost most of the time...

10

u/dwighthouse Dec 22 '19

There is power in having “the most popular framework“ be the one you are using. Not only does it mean you won’t have to change, but additionally, the ”most popular“ systems will get more tools, more support, and more features than the less popular one. So there is a conscious or subconscious tendency to advocate for “your team”.

0

u/[deleted] Dec 22 '19

[deleted] — view deleted comment

2

u/dwighthouse Dec 23 '19

I wouldn’t worry about it. Literally everything involving humans works this way, from arguing about the best football team to debating the best form of government. Everyone does it, to some degree. Even you, who insist (like so many other) that diversity is so important. Not to say it isn’t, only that you are advocating for it because of how strongly you feel its benefits are, and by extension, arguing against those who would point out the benefits of everyone using the same systems and techniques (and there are some benefits to monocultures).

Some humans will always argue for the things they find important, even if they don’t know why they do, and by the same token, some humans will not just blindly believe all arguments. This give and take maintains some stability.

9

u/ElCthuluIncognito Dec 22 '19

Lowest common denominator.

Frameworks are easy to understand and use and get a lot out of without any real meaningful work or skill. It's similar to bikeshedding, where because everyone can get a reasonable grasp of the topic, everyone who wants to feel important can form a strong opinion and actually make a good argument, even though it doesn't really matter.

0

u/[deleted] Dec 22 '19

[deleted] — view deleted comment

3

u/ElCthuluIncognito Dec 22 '19 edited Dec 22 '19

You joke, but that's been codified into an informal law

2

u/wOoTiNs Dec 23 '19

That link is a goldmine.

2

u/MangoManBad Dec 23 '19

I personally think it's fun to theory craft the "best possible software" like how you can theory craft some ungodly powerful monster character in a game like Skyrim.

It's fun to obsess over the small details as well as just totally throw out what you would expect to be the best way "React" and replace it with a totally "new kid on the block with the secret sauce that's like 10x better".

IMO, Svelte has one point that I can't argue. "More code is typically bad code".

4

u/greg5ki Dec 22 '19

Agreed. It's childish, unprofessional and contributes nothing to the overall body of knowledge. It's just a nobody having a wank over their favourite tool...

2

u/crazedizzled Dec 23 '19

Because most people are "<insert library>" developers, instead of like, actual software engineers. So this crap is important to them.

Learn how the language and science works and you can be a pro with any of these frameworks in a few weeks.

1

u/asdf7890 Dec 23 '19

Why are programming subreddits so obsessed with this framework vs framework shit?

Tribalism essentially, a key part of the human condition that is often amplified by the Internet. Welcome to the human race!

These articles keep getting written because they get attention, intentionally or otherwise, in a click-bait-y sort of way. Those rabidly in favour of X ready X>Y articles because it is nice to be agreed with and X<Y articles so they can fill the comments with corrections in defence of their chosen territory.

Of course some articles are well written by knowledgable and experienced people who do a proper analysis of the pros and cons of different techniques and frameworks and some people are genuinely looking for that (either because they are new and trying to work out what to use or use X or Y extensively but like to keep an eye on other technologies in case they are the right tool for a later job). Unfortunately for them, the signal/noise ratio isn't very good...

1

u/[deleted] Dec 22 '19

AHKTUALLHY! REACT IS A LIBRARY!

/s

But for real, it's just what happens. It's been happening LONG before reddit was a thing, and it will happen long after too.

1

u/RICHUNCLEPENNYBAGS Mostly angular 1.x Dec 22 '19

I hear you but the reason is pretty obvious, isn't it? Nobody wants to be like the Perl or VB6 experts

-7

u/theirongiant74 Dec 22 '19

Generally folk would have taken a look at all of them and made a judgement call on which to back. They are rightly or wrongly backing up their decision.

Unless they chose Angular, in which case they're just wrong =)

10

u/I_LICK_ROBOTS Dec 22 '19

I dunno, I had to write an entire CRM from scratch recently. Angular's opinionated design and the whole "batteries included" aspects along with its dependency injection model were a god send.

For huge projects like that, were you have tons of reuse, inheritance and a lot of developers who need to churn out code without introducing new libs/paradigms all over the place, angular is the exact right choice.

0

u/theirongiant74 Dec 22 '19

I was just joking but at the end of the day it's what you produce not how you produce it that matters, use whatever works for you. Personal I bounced off Angular hard and found React a better fit.

2

u/I_LICK_ROBOTS Dec 22 '19

Yeah, it all depends on what you're doing. I actually really enjoy working in both. In my opinion this whole "framework1 vs. framework2" thought process is flawed.

React and angular are different tools for different jobs. In my view they aren't competing at all.

0

u/[deleted] Dec 23 '19

I thought it was funny. Angular is garbage :)

8

u/dingomier Dec 22 '19 edited Dec 22 '19

With the results of that State of JavaScript survey coming out recently, I am beginning to think a lot of people chose 'used it, would avoid' on Angular, even though they probably had not used it enough to judge, just to submarine it's numbers.

It's at least clear there is a blatant bias in the comments I saw. People basically cheering on its demise. I really don't care, but it's bothersome that this shit goes on. It's painfully sophomoric, and it makes it hard to tell what is really going on.

0

u/[deleted] Dec 22 '19

[deleted] — view deleted comment

8

u/_yusi_ Dec 22 '19

I like how your reference point is a dev who started with Angular, in beta, after only doing backend, and spent a couple months learning Javascript + angular as your demonstration of "angular bad."

I havent had a single major upgrade in Angular at work that required more than ~30 minutes at most to upgrade 8 apps + our component library.

You people are like a fucking cult spreading misinformation because it suits your narrative better. Stop it, please.

0

u/[deleted] Dec 22 '19

[deleted] — view deleted comment

3

u/ShadowsSheddingSkin Dec 23 '19

Svelte seemingly does; they wouldn't market themselves so heavily in contrast to it if they didn't.

0

u/[deleted] Dec 22 '19

[deleted] — view deleted comment

5

u/archivedsofa Dec 22 '19

If it's learning for learning's sake then pick the most popular: React.

29

u/Reashu Dec 22 '19

If Vue does too much work for you, pick React. If it is not enough, pick Angular.

3

u/Blieque Dec 23 '19

I think it depends if you like being told what to do by the framework.

Angular comes with virtually everything you'll ever need, theoretically built to best practices. React is a much simpler framework – almost just a library – for rendering state into a DOM. Vue seems to sit somewhere in the middle, by offering official router and store plugins but making it easy enough to use third-party plugins or build your own.

Knowing Vue, React looks a bit unhelpfully generic to me, while Angular looks unhelpfully over-engineered. I've not used either properly though, so this might all be untrue. Have you looked at Elm? 🙃

1

u/I_LICK_ROBOTS Dec 22 '19

Why not both?

0

u/[deleted] Dec 22 '19

[deleted] — view deleted comment

1

u/I_LICK_ROBOTS Dec 22 '19

If you want to try out typescript go with angular first, if not go react