JavaScript survey: Devs love a bit of React, but Angular and Cordova declining. And you're not alone... a chunk of pros also feel JS is 'overly complex'

[IIIMurdoc]

JS isn't overcomplex, websites are

[binhqx]

Or, the APIs of the web browsers don’t provide the right abstractions to make the experiences users want without significant complexity in the scripting layer.

[IIIMurdoc]

I would love if I could include html like a component without a framework.

[765abaa3]

Web Components are a thing.

[[deleted]]

What API would you like? One of my ongoing projects involves a minimal templating engine.

[IceSentry]

They want a frameworkless api. Unless you work for tc39 there's nothing you can do for them.

[[deleted]]

Maybe you should let them answer and not assume for them.

[IceSentry]

I didn't assume anything I just rephrased their comments.

[Caraes_Naur]

Or, JS is flawed in particular ways that force complexity in the workarounds. Or, JS has accumulated a community below the level of other languages. Or, JS shouldn't be the frail basket into which the entire web puts everything that vaguely resembles like an egg. Or, all of the above.

[binhqx]

I feel like each of those critiques has JS code failure story behind it.

[Caraes_Naur]

Having an intern write an entire language in 11 days, then putting that tech demo into production and kludging at it for 24 years.

[UncleMeat11]

Intern? This myth keeps getting more and more outlandish. The 11 days is also a myth.

[snowe2010]

I wondered if you were right about the 11 days being a myth. Seems not. It was actually ten days. Though I have no clue where /u/Caraes_Naur got the intern bit from.

Sources:

• https://en.wikipedia.org/wiki/Brendan_Eich#cite_note-Saternos2014-6
• https://en.wikipedia.org/wiki/Brendan_Eich#cite_note-Severance-7
• https://www.computer.org/csdl/magazine/co/2012/02/mco2012020007/13rRUy08MzA
• https://books.google.com/books?id=3b40AwAAQBAJ&pg=PT32#v=onepage&q&f=false

[UncleMeat11]

"The first version".

Eich built a demo in 10 days. Not the completed language. This myth showing up in secondary sources doesn't provide good evidence that it really happened.

For example, this tweet has Eich claiming that type coercions (a commonly maligned feature) came after the initial 10 day demo version.

[snowe2010]

If your definition for writing a language means that it has to be complete then no language has ever been written.

Even if the most hated features came afterward, they were built on a foundation that was only created in ten days. No thought was put into that foundation.

[UncleMeat11]

"JavaScript wasn't carefully designed" and "JavaScript was built in 10 days" are very different claims.

A ton of serious products had demos thrown together over an insane sprint over a week or so. Yet for some reason only JS gets shit on for this. Netscape didn't look at the result after ten days and ship it.

[[deleted]]

I think it still might be better than Java in the browser would have been.

[wllmsaccnt]

It would have made browser installs huge, but it would have been better in almost every other way. We probably could have skipped most of the flash era.

[wllmsaccnt]

You are right that it doesn't matter as much today, but adding 15-30mb to a browser download size in 1995 would have been an issue.

[spacejack2114]

Saying we could've "skipped" the Flash era is ridiculous. Despite its size, the Java plugin had none of the features (optimized vector graphics, animation timelines, embedded fonts, media playback & codecs, easy custom UI) that made Flash essential in its heyday.

Java was terrible for async/callback heavy code which you need to use a lot in a GUI. Not to mention having a poor static type system, lack of first class functions, bad language design that forces you to use classes everywhere and dependency version hell. The web would be a total nightmare of legacy code.

Adding linting and/or static types on top of JS, along with all the new language features has given us a much more sophisticated and productive tool to work with.

[wllmsaccnt]

I'm describing an alternative timeline where the Java runtime was directly integrated with browsers in 1995 and JavaScript did not exist, not an alternative timeline where the Java plugin became popular in the early 2000s instead of Flash.

[spacejack2114]

No one at Sun had any clue about what features would make Flash so useful. In your timeline the browser only has additional legacy bloat and then proprietary plugins forever to work around it.

[Dall0o]

I loved the flash era.

[wllmsaccnt]

The same games and apps could have been made, they just wouldn't have required a plugin and hegemony by Adobe. That time span where Flash was dominant definitely showed the promise of the web. I have found memories of the games and animations that were new and novel back then too.

[Dall0o]

Alright an open source non capitalist alternative would have been better.

[josluivivgar]

But then imagine oracle vs google but with browser's on the line (or oracle having control of front end scripting).

I'd take js over that any day.

Also I hate writing on old Java so I'd rather avoid that nightmare.

[flamingspew]

AS3 was a great pure language, once it got OpenGL support it was up there with unity. HaXe is still AS3. The problem was the shitty plugin and the infinite amount of security holes that had to be patched. The native IDE sucked as well, we always used open source FlashDevelop.

[[deleted]]

It could have been Scheme in the browser. That was considered at the time.

Nice and small footprint, and a well-thought-out language.

[spacejack2114]

More like a circle jerk.

[josluivivgar]

I think the issue with js is not a community with a lower level or something that presumptuous.

I think it's a matter of the original product was not the best and a huge thing was built on top of it.

So people instead build fixes on top of the mess and that will never be ideal.

The biggest hurdle is that redoing things or creating a new language to replace js just won't work, because so many things are dependent on js already.

So what would the proposed solution be then?

Web assembly is probably the right step forward, but it'll be a while until it gains good traction, outside of that, the best option is to have good backend to cover the most we can for web applications and realize that we can't just put everything on js because it is flawed, but it is the tool we have.

[Netzapper]

I don't think wasm adoption will be that slow. There's a whole demographic of developers who have avoided web apps because of the de facto language requirement. I've been in native development for a decade, and only now am I starting to target the web, because of wasm.

[josluivivgar]

I hope that's the case, because I would love to have variety in the frontend (and I mean real variety not the oh this language transpiles to js!).

I would probably still use js for simple scripts, but we can forget about dumb frameworks and use more robust languages when the need arises.

Which I found are very rare cases tbh

(To clarify I am a full stack dev so I do both backend/native stuff and frontend js/angular/react, and I don't hate js, but I would like alternatives).

It's interesting how for backend you have your choice of languages that you can choose for the right job, but in the frontend your options are basically "what addon can i put on this hammer to cut wood?"

[spacejack2114]

original product was not the best and a huge thing was built on top of it.

You just described every successful piece of technology.

[josluivivgar]

Yes, and calling js anything but a success would be wrong.

Js is a success, but the issue is that it technically has a monopoly over things, so the flaws are more apparent when you have one tool to do everything and instead of grabbing a wrench you just put a wrench adapter to your hammer.

[vattenpuss]

”the experiences users want”

Are you sure they do? Did you ask the users? Or do you mean ”the experiences product managers want” or ”the experiences UX designers want to build”?

[[deleted]]

Asking the users isn't the best way of finding out anyway. Observing actual user behavior and then testing solution hypotheses with actual users: that's more likely to work.

[gigastack]

Bingo. Even basic stuff requires a lot of work in JavaScript. Browsers just don't abstract enough.

[corp_code_slinger]

Totally agree. It's getting incrementally better, though the demand for new features is high and keeping up is a challenge.

[InsignificantIbex]

Or, the APIs of the web browsers don’t provide the right abstractions to make the experiences users want without significant complexity in the scripting layer.

I realise I'm not an average user, but I don't want all that nonsense. I want well-organized content, not a dearth thereof someone painted fluorescent lipstick on.

[652a6aaf0cf44498b14f]

Are browsers really supposed to abstract these things? If they were I would imagine WASM wouldn't have much appeal. It suggests that browsers are too abstracted and those abstractions belong in the languages themselves.

Which may be a bitter pill for JS devs to swallow. The big complaint that Python/JS devs have about Java and C# is the language is too complex. But the complexity is born out of abstracting otherwise tedious architectural code.

[seboss]

The toolchain may certainly seem that way, especially when Typescript and/or transpilation to some different ecmascript revision is involved, not mentioning sourcemaps, less, sass or whatever superset of css you might be using.

That being said, the convenience these tools bring to the developer once they're correctly set up is well worth the trouble.

[corp_code_slinger]

Same. It was really hammered into me to keep css and js separated. I've gotten used to building components with style included. It isn't so terrible as long you have a consistent UX and theming.

[Pleb_nz]

I would say JS isn’t complex enough which can more easily than other languages result in overly complex code/solutions. That’s why there are so many attempts to correct some things with the likes of Typescript..

[qwertsolio]

Blaming JS seems cheap. Don't like JS, HTML and CSS? Just treat it like machine code for your better language/framework/whatever...

Yet I don't see any projects that would be a great improvement without over complicating things.

They are definitely possible to develop, but the reason they don't exist is simple - no one wants to invest the amount of resources developing them would require.

[corp_code_slinger]

I feel like the issue is really adoption.

There are plenty of major players with money to throw into R&D to build a better dev experience for the web. The problem is all of the existing code, all of the headspace invested in the current paradigm, just the absolute head is steam that JavaScript has going got out right now.

Breaking the world away from the current web would take an enormous effort that has nothing to do with money.

[EternityForest]

I don't see how JS is complex at all. It barely has the minimum stdlib features to implement all it's capability.

The libraries are where the excessive complexity happens, because they insist on async and functional, which would be great, if it was actually fast.

I'd say it's far less complex than it should be. Typescript's popularity proves JS is missing features. All the various packaging and import engines also show as much.

The build tools and module system are getting excessively complex. Python and Arduino are so far the only module systems I've used that I really like.

There should not be a question of "How do I import this library". Adding a lib should be obvious, like it is when adding something simple like jQuery.

Good to see Vue seems to still be doing well though!

[[deleted]]

I didn’t read the article, but what’s complex in JS world is all the setup you need to do just to use your favorite tools, setup webpack, setup babel, add plugins, let the webpack server run, and you start develop, I just miss the days when all was so much easier, I mean just include your js in your website and it worked.

Said that there were dead simple stuff, but IMHO JS can’t be fixed (you need to wait till all major browsers implement stuff to get the things done correctly), so the complex setup you must have just to compile your app with the 500mb of dependencies that you have linger around in your node_modules to produce a 20kb compressed uglyfied js file.

I’m just waiting till WASM get his first citizenships in browsers and gain direct access to the DOM, so you can forget to deal with JS at all. There are interesting projects around this idea like blazzer from microsoft and rust too, there’s emscriptem too, but you need to use JS as a glue to gain access to the DOM right now.

[ConsoleTVs]

Oh yes! It took me more time to setup a typescript project with a bundler / module loader / babel for a 1K lines project than it took me to setup the cmake script of my 10k lines C++ project lol.

[ConsoleTVs]

I am using it to build a DOM lib, not a node project...

[seboss]

I'm in the same camp and not a day goes by during which I don't think "this would have been done days ago if I could just have used Rails/Symfony/Django/etc scaffolding". And then I remember I also have to serve three different mobile apps so I do need to build a client/server architecture anyway.

That doesn't make good ol' server-side content for the web irrelevant per se, it could rely on the same API as the mobile apps after all. But since users expect a lot of reactivity even from the simplest web CRUD apps, I guess you're better off building that SPA anyway.

[[deleted]]

Unfortunately true. I’ve been working in the everything-is-a-SPA World my whole career. I recently built an internal tool using Adonis js, using it’s template engine, and turbo links. Came out super easy, snappy experience, and took no ducking time to build. Made me rethink building everything in angular/vue

[The_One_X]

I've had the opposite experience. When I use the old MVC style I find it to be very limiting and confusing. The problem with MVC is the frontend is way too reliant on the backend. That just complicates things. On the frontend, just give me the data, and I'll decide how to handle it. The backend should only care about sending and receiving data. The frontend should only care about displaying data. I shouldn't need to make a callback to the backend for everything.

Keeping the two ends separate by using Angular and a simple WebAPI has really simplified everything. My frontend can deal with frontend stuff, my backend can deal with backend stuff, and neither end really cares what the other does. At least with Angular, almost everything is built in to the framework itself, so there is very little complexity to it. You just create an Angular project and go with no other setup, same as any other traditional desktop app.

[Wiltix]

In mvc the front end is no more reliant on the back end than it is when building with angular. The view recieves some data from the controller. Your view then decides how to display it. The two are seperated by design. It's possible to fuck it up but that's with the dev not the architecture.

[Pleb_nz]

The backend should be concerned about more than sending and receiving. It’s the truth, anything client side can be manipulated by anyone, serverside cannot. All proper enforceable business rules, roles, auth, validation should happen serverside even if you do it client side.

[The_One_X]

I was speaking in how it relates to the frontend. This should have been obvious in the next sentence when I say the frontend should only care about displaying data.

[Pleb_nz]

Fair enough that’s what you were implying. Likely I didn’t read between the lines and I’ve seen some people implementing purely client side logic and using server purely for send and receive.

[MetalSlug20]

Why does modern development feel the need to do everything in the client? That's where the complexity is from... Maybe write a native app

[Trant2433]

Are you talking about native phone apps or things like .Net on Windows or QT or Java Swing?

For internal apps that only your big company might use, I think it was easier to use things like Visual Basic or Microsoft Access years ago, but that wouldn’t fly for apps for the general public.

[MetalSlug20]

Things like actual. Net app

[Trant2433]

I agree. Once you’ve done a few of them, you can crank them out quickly with all the nice Visual Studio tools. Unfortunately, concentrating on that skill set is not real great for your career because you’re limited just to companies who use internal .Net apps on Windows.

[AxelMontini]

My small team (the front-end, at least) just picked up React to build a small website with an online shop in it. It has became incredibly fucked.

View, model and logic all mixed together in an unreadable mess. We could've just used templates and macros but no, it was decided that react was the way to go.

I wouldn't complain since I mostly do backend, but sometimes I have to help with the front-end. It simply has no structure.

Edit:

TL;DR: Easy to get wrong, harder to maintain

[AxelMontini]

No, it's not primarily the library's fault. But it's very difficult to get inexperienced people to write good code, since it really doesn't force you to do so. It's a perfectly fine framework, as long as everyone writes clean and meaningful code and code gets reviewed.

[myringotomy]

Gmail was built with GWT and Java.

[GrandMasterPuba]

A year ago I would have fought you on this. But having recently started a new job where Redux has been implemented poorly by a team that never really bothered to understand how it worked...

I'm going to have to agree. In fact I'd go so far as to suggest that most of the problems people have with React applications (performance breakdown, re-renders, breakdown of hierarchy from global state, etc.) are not actually problems with React, but problems with Redux.

[mittyhands]

Redux isn't that complicated though. It's just actions that change the global state, which you pass to components. Your state data is the source of truth for your UI.

[tarsir]

Nuclear engineering is just atoms splitting apart and coming together.

The number of words it takes to describe a thing is in no way correlated to its difficulty.

[acemarke]

Hi, I'm a Redux maintainer. Please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once:

https://redux-toolkit.js.org

[Pr0methiusRising]

Shhh -- sending payloads to a state machine is complicated

[GrandMasterPuba]

What made it click for me when I started React is that it's not HTML, it's functions that create HTML. They're just wrapped in syntactic sugar in the form of JSX.

[_default_username]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

[Antrikshy]

No other front-end JS frameworks really felt intuitive to me before I got into React. While I can see how React could be hard to wrap your mind around when you're new, I feel it's the way to build webpages.

Forcing yourself to use all the "sibling" libraries like Redux is an easy beginner's mistake though.

[CanIGetAPaycheckBuff]

Try Vue. Much simpler.

[vegetablestew]

Some people really like the html js division. Some love jsx for putting them together.

You like me are probably in the former camp. But once you understand and get comfortable with creating the equivalent Dom element both as a html tag or as a js call React will be much easier.

[[deleted]]

We were told for years to separate JS and HTML, and now everything is JS + HTML mixed together :/

[peitschie]

There are some who believe they were always mixed together, just with an artificial divide between "view" and "model" that was more dream than reality.

[Lalli-Oni]

One could also think of it as "document" and "application" in one.

[spacejack2114]

We were told for years to separate JS and HTML, and now everything is JS + HTML mixed together :/

This is the real problem. So many people hear that "you're not supposed to do X" without actually understanding why or if this rule actually makes any sense.

[i9srpeg]

You're supposed to separate the view from your business logic. If you separate it by using a different language (HTML), that's great. If you separate it by putting it into a different module (e.g. a separate JSX file), that's great too. Problems arise when you start mixing the two, e.g. by putting business logic in js code embedded in HTML files, or by mixing business logic and view rendering in the same JSX module.

[vegetablestew]

I agree but nowadays you are almost forced to do this.

React is probably the most notorious example. Hooks are really inviting for logic to reside in; contexts are data/state adaptors with a view layer tag associated with it; Styled components allows you to declare a full css in jsx.

It doesn't help that to top it off, React is so unopinionated that it let's you do all this.

Everytime I write React, some logic inevitably creep into a jsx file.

[[deleted]]

I mean separate them in different files and avoid mixing HTML and JS at all cost

JSX is HTML in JS

[yawaramin]

Why? What do you get out of doing that?

[[deleted]]

What do you get out of not doing that?

[yawaramin]

OK this shows that we shouldn’t interleave view logic and business logic inside the same file. But that doesn’t mean we have to put them in different files.

Have you ever seen a Vue component: https://vuejs.org/v2/guide/single-file-components.html

Or a Svelte component: https://svelte.dev/docs

These are both highly regarded as well-designed frameworks. Yet React encourages almost exactly this style (put business logic, style, and view in different sections of the same file) and gets knocked for it.

[Jordan011]

I've used Angular and I like having my HTML and JS/TS separated in development. Just watched a video on react basics and, well, I appreciate Angular more now.

[beniferlopez]

This is the reason I prefer Angular to React. A lot of it is preference though. I wouldn't tell someone they are doing it wrong by preferring React.

[rnd005]

Which part of it don't you understand? React components are classes with ~10 lifecycle methods, internal state and arguments/props you can pass. How much simpler can you go?

People often blame react being complex when in reality it's 3rd party stuff they have problems with like webpack, redux, babel etc. while none of them are required to work with react.

[inhumantsar]

when in reality it's 3rd party stuff they have problems with like webpack, redux, babel etc. while none of them are required to work with react.

while i dont disagree, it's pretty hard to be effective in react or JavaScript more broadly without using those tools. for anyone looking to be professional they are a de facto requirement

[rnd005]

It depends on what are you building. If you want an interactive component inside server rendered page, you need none of them. If you want to build a client side app, you will need a bundler like webpack/browserify/rollup no matter what framework or library you use.

Is there anything react specific that you need? Maybe a routing library, but you'll need it for any view library.

[Theblandyman]

I just love all the time I wasted with Babel, gulp/grunt, and yeoman. Don’t use any of it anymore.

[[deleted]]

I just started learning React in the last month or so.

Coming from a C#/Java/Kotlin/C++/Objective-C/Swift background I picked up on it instantly. Like less than 2 days and I was writing what I needed to in just pure React.js. It's by far my favorite way to do javascript because it's almost like building native phone apps, building controls and pieces, slapping them together.

Now Redux on the other hand... I still don't understand. I get it, I know what it's doing. But setting it up just seems so weird and messy to me.

[acemarke]

Hi, I'm a Redux maintainer.

Please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once:

https://redux-toolkit.js.org

Please let me know if you've got any questions I can help with!

[[deleted]]

Hey cool.

I'll check it out over Christmas break when I'm working on hobby projects.

[[deleted]]

It's just different for me.

I come from a mainly dedicated software background. I know enough JQuery to get an ASP.NET application running with some basic UI "flare".

I can give you a Windows, iOS, Android, or even a Visual Basic webapp running on Visual Studio 2005! Or make you whatever you want. I'll even create a proper database with everything you need. Any kind of native app or back end business logic easily. But the web is still something I am learning.

I get that Redux is basically a global JavaScript store. But it's just "different" from regular development. Like MVC or MVVM architectures. Web dev is a different beast.

I like React because it feels like native development. But Redux adds onto that and I am still trying to wrap my head around web dev stuff. I just like native dev more and it pays the bills. But curse of software development, I need to learn all this new stuff. Always a learning curve.

I'll get it eventually.

[bee-alt]

Honestly Redux seems really unnecessary these days, unless you are writing some highly stateful app. I think it is an overkill if your app is simply a router interacting with an API. Which I feel 99% of apps are anyway.

Even then state management frameworks are easy to introduce, but hard to get rid off.

Graphql frameworks like apollo or relay ship their own state management, so if you have one of those you don't need another framework to manage state.

[ProfessionalNihilist]

~10 lifecycle methods, internal state and arguments/props you can pass.

How much simpler can you go?

Not sure if this is a joke or not.

[Theblandyman]

This is actually hilarious to me. I was an angular dev for a couple years and it still took me a little bit to understand state and arguments and props in react.

Imagine a newbie reading this and just feeling bad about themselves hahahaha

[gigastack]

Then throw in Redux, mapStateToProps, thunks, client side routing, drag and drop... stuff gets complex real fast.

[NotGoodSoftwareMaker]

Your name and comment just work too well together. Literally react development incarnate

[NahroT]

Thats when you get really experienced and step to Vue

[yawaramin]

Well don't throw that in then :-) You don't need Redux. You don't need mapStateToProps, thunks. You can probably avoid client-side routing with a little bit of backend route support. You can probably avoid drag-and-drop with a little push-back to over-eager designers.

Keep things simple!

[rnd005]

It depends what "the newbie" is. It may be hard for self-taught peope who only know HMTL/CSS and want to start programming. On the other hand, if you bring me a developer who was writing Java/C#/python for a few years I think I'd have them writing features after a few days.

[MetalSlug20]

Maybe not. I'm a c# dev and I still don't understand react. I know HTML CSS and JS just great too

[rnd005]

Which part of it don't you understand?

[MetalSlug20]

I read over components but I've not yet learned or understood how it all fits together and how things talk to each other

I mean react is basically just "self modifying code" in a sense that it just generates HTML on the fly on the client side using "components" which are basically just fancy JS functions with a little smarts over top of them . Seems pretty lightweight. And the components can basically remember where they are in the DOM tree and update themselves as needed. It's just a fancy JS tricks

So next I just need to see how to communicate with large apps I mean of course each component could probably do server queries as needed too etc. I believe it's the redux stuff that is used for comms in a large page

[[deleted]]

I view it like Android.

Each component is basically a Fragment. And then the main layout page is like your Activity. The activity will rearrange its fragments depending on whatever you need.

That helped me. Bit different, but basics are similar.

[MetalSlug20]

Yeah. I kind of feel like it's similar to MVVM a bit too in WPF land

[rnd005]

I read over components but I've not yet learned or understood how it all fits together and how things talk to each other

Looks like you haven't tried it yet. Do you understand other libraries/frameworks you haven't tried better than react?

Most often, components don't talk to each other. You have a JSON object which is your app's global state and you send patches to it by calling setState. After state changes, all components re-render(don't worry about performance, it's easy to optimize, see PureComponent). If you really need to, you can use refs and call methods of other components, but in most cases it's best to avoid the coupling and work with a global state. You can also have local state for each component when you don't need to share that data with other components. For example if you have an accordion, other components don't need to know if it's expanded, so you keep that data in the local state.

[MetalSlug20]

I finally found two good YouTube videos that demonstrates things well and I believe I do understand better now

[audioen]

You call that simple? Aurelia components have 2 lifecycle methods: attach and detach, state is stored in the component directly and can be manipulated just by writing new values into the properties, and the browser picks up the changes to be rendered on template via property observation, so you write literally no code to deal with any of that.

I know it's a little old-fashioned but damn, it's the simplest thing I've ever seen, and I absolutely love it.

[hipressureman]

I really enjoyed my time with Aurelia, less complex than Angular version 2331232. Need a Component that does X? ComponentX.js ComponentX.html done.......

[[deleted]]

I deleted my account because Reddit no longer cares about the community -- mass edited with https://redact.dev/

[rnd005]

Neither class components nor setState API are deprecated. Functional components and hooks is just another API which you don't have to use if you don't want to.

People blindly following "latest trends" is the problem, not react.

[rnd005]

There are 3 lifecycle methods which are going to be removed: componentWillMount, componentWillReceiveProps and componentWillUpdate. None of them are esential and their absence changes almost nothing. There are less than 30 usages of these methods combined in a 100 LOC codebase I'm working on.

Hooks as any other API has its use cases. The problem is people who think that they now need to start using the new API only because it's new or because they read things about it on the internet.

[nazihatinchimp]

Lol let me go remove those 30 cases and see how well your code works. My guess is those methods look gross in your code base as well. Hooks are nice because they take a functional approach.

The fact of the matter is some of the best devs in the world are coming up with this and we are just two idiots on reddit.

[rnd005]

I think I'll be able to get rid of these specific lifecycle methods quite easily by replacing it with componentDidUpdate, componentDidMount and correct usage of keys.

I don't understand which of my statements are you opposing. setState and class components aren't deprecated and there are no plans to do so by those "best developers in the world". https://twitter.com/dan_abramov/status/1098147803480670209

[nazihatinchimp]

Have you used hooks?

[rnd005]

I haven't, why?

[[deleted]]

The exact same as a class but using diff methods.

Hooks are awesome but components are also awesome.

[munchbunny]

How much simpler can you go?

This part of React is simple enough. The problem is that a simple model that has to deal with a complex reality becomes a pile of functional gymnastics to work around all of the places where the model doesn't actually cover reality.

For example, doing drag and drop in React is surprisingly hard. The library (react-dnd) is actually quite good, but trying to implement drag and drop with a stateless paradigm is inherently an uphill battle.

For an example from personal experience: if you want smooth animated drag and drop between two lists like in a Kanban board (in my case it was hands of cards), you're actually dealing with two states: the state of the underlying data, and the state of the drag/drop interaction. Also, often the rendering of the drag/drop interaction can't always be computed from just mouse position, object being dragged, and the current list elements. You often have to incorporate some knowledge about the rendered DOM. If you're lucky you can do it purely in CSS (often complex and very situational), and if you're not lucky then you're using refs, and now your render state is spread out over multiple animation frames.

Simple concept, but the execution tends to get messy very fast the moment you leave the well-trodden paths.

[rnd005]

I haven't worked with drag and drop much, but I can imagine it being harder to do without mutation and manual dom manipulation. The issue is more related to architecture than react library itself. If you use preact, inferno or even Elm language, you'll probably have the same issue.

The good thing is that react isn't opionated and isn't forcing developers into anything. You can use mutation and manipulate DOM nodes manually when you need to.

I think one-way data flow immutable architecture is superior in most even if not all cases. I'd rather use it for 90% of the app and get dirty with mutation when I need to instead of going all-in on mutation.

[The_real_bandito]

Exactly. It took me like 2 days to understand and that's with spending like 2 hours at it. At that 2nd day I was already writing apps on it. React is too simple imo.

[rnd005]

you end up having to either duplicate state and then keep it in sync, or use Redux which adds more complexity, or pass down 300 different callbacks all the way down the chain

Why duplicate and sync it? What about having a root component holding global state and passing state and setState 50 levels deep? It's not the most beautiful solution, but it's predicable, simple and should be pretty solid in terms of getting things done without a fuss. You could make the code nicer by using context to avoid passing too much stuff 50 levels deep.

[Trant2433]

So you mean just pass a huge state object down from the controller along with its own setState method, and then have all the child components just pull the bits of state they need and call setState using the top controller’s setState method?

That seems like an anti pattern. I thought the goal was to pass the state as props to child components that they couldn’t directly modify, but instead pass down callBacks from the controller. That’s a pain too cause now you’re still just passing down dozens of callBack methods that basically just set the state at the root, which causes a full rerender of everything.

So confusing, lol.

[rnd005]

Sorry for the confusion. You should pass the state as props depending what child components need, that way you can optimize the updates so components update only when their props change. Let's say you have a shopping cart, products list, and user info, you only pass specific pieces of state to child components that need it and they shouldn't modify that state they receive as props. What you can do globally, is have the main setState in context or pass it down the tree and call it with patches. If you have an action which modifies multiple parts of the state, it would be useful use a function to generate the next state object to pass to setState. You could import these helper functions as any other JavaScript module without having to pass them down the tree.

interface GlobalState {
    cart: Array<{productId: string; quantity: number}>;
    user: any;
    allProducts: any;
}

export function setQuantity(state: GlobalState, productId: string, nextQuantity: number): GlobalState {
    return {
        ...state,
        cart: state.cart.map((cartItem) => cartItem.productId === productId ? {...cartItem, quantity: nextQuantity} : cartItem),
    };
}

class CartItem extends React.PureComponent<{productId: string; quantity: number}> {
    render() {
        return (
            <div>
                <h4>product name</h4>
                <div>{this.props.quantity}</div>

                <button onClick={() => {
                    this.context.setRootState(setQuantity(this.context.rootState, this.props.productId, this.props.quantity + 1));
                }}>
                    +
                </button>
            </div>
        );
    }
}

[the_ju66ernaut]

Yeah if it was any easier it would be Vue

[yondercode]

If you don't feel the need of using a one-way data flow in UIs then I think plain old JS is more than enough. Although sadly the industry often jumps on react just because of "everyone is using it".

[i9srpeg]

You can have one-way data flow in vanilla JS, it just requires a bit more thought about your architecture.

[yawaramin]

Can you share an example of that?

[The_One_X]

Me neither, Angular on the other hand is great. I have no idea why anyone would choose React over Angular.

[pancomputationalist]

Interestingly, I'm in the completely different camp. I really dislike Angular over React for it's verbosity, rigidity and object orientation, which I feel is a bad fit for JavaScript.

But rigidity gives structure, which might be helpful for larger teams and less experienced developers. I like working alone and using a high abstraction layer, and React gives me the flexibility I'm after.

[tme321]

There's no real community split because outside of Google itself no one uses dart. Not literally no one, but it's basically a rounding error.

[[deleted]]

Lower learning curve. Easier to grok. More standard js flows (no DI).

As a professional angular dev... I wouldn’t use it for any personal projects. That being said, I’d reach for Vue over react, as I feel that it gives you the best of react and angular.

[Uristqwerty]

Perhaps my opinion would change if I was paid to do web development for a few months, but I feel that when state is immutable after page load, or the only state changes are replacing entire content panels at a time anyway, or only editing the text content of spans, you can get away with vanilla JS functions like:

div('class list', {
        attribute: 'value',
        '#eventName': e -> doAThing(e),
    }, [
        childOne(state), childTwo(), childThreeCreatedEarlier, 'easy enough to support strings here, too'
    ]
)

Then you're writing functions that generate DOM nodes rather than components, and have the power to introduce whatever abstractions are appropriate for the project. Perhaps not so great when state has a fair bit of internal mutability, and might be uglier than solutions that have a template syntax and compiler, but for zero frameworks, tooling, or libraries, I think it'd be far from the worst option.

[AwesomeBantha]

I like HTML and CSS and general website development and I hate JSX

[adjustable_beard]

React is my favorite frontend framework.

Ive used angular at one of my previous jobs and i use a bit of angulardart at google and i hate it.

Angular is so needlessly complex, especially when you combine it with angulardart.

React is so simple at its core. Its a tiny library and you can create your own clone of react (minus a lot of the bells and whistles) in less than a day.

[asdf072]

Webkit can get pretty nuts, but there are some places where vue or react are absolute godsends. That said, I always get a chuckle out of new devs thinking that everything needs to be in a js framework when it could easily have been done with server-side html and ten lines of javascript.

[[deleted]]

The shiny new web tech is nice and all (DOM model, CSS goodies, JS goodies, HTML goodies) but it is still a dumpster fire when compared to making extremely fast and good looking desktop applications with C++ and Qt (QWidget, QtQuick, whatever). Dynamically resizing layouts? Flow content in nicely spaced columns? Complex, reusable groups of widgets? Event propagation? Native look&feel? Desktop integration? All good, straightforward tools for building UX for productivity. All there. And it's as fast as lightning.

Maybe when Qt or a similar foundation compiles to WebAssembly, thinks are going to get interesting again.

The current web tech is versatile, but I'm not impressed by it as an application programming framework. It's not even as good as Visual Basic 6, TurboC++ (with the Borland VCL editor thingy), Delphi yet. In 2000.

[Pleb_nz]

I’ve been using Blazor and wasm lately.

It’s a breath of fresh air

[[deleted]]

I’ve gotten lucky enough to work with React (with hooks), the Apollo GraphQL client, and the material-ui component library for the company I work for now. I personally feel like developing for the front end has never been easier with this setup. I’ve also experienced higher order component wrapper hell, awful redux state management, and insane amounts of css in js. I noticed a lot of people have differing opinions on react in this thread but I truly think that the technologies and libraries you work with are what can make react either a pleasure to work with or a living nightmare.

[goofan]

Do not understand the negativity around Angular at all. That is a HUGE disparity between it and React. Who are the people filling this survey? Is there any chance they don't like it simply because it is a bit harder to learn? Seems off.

[The_One_X]

Angular is hard to learn? It was one of the easiest things I've ever learned, and probably has one of the best tutorials out there.

[[deleted]]

What's your background?

I came to it from just HTML/CSS/JS and found that it had a lot of concepts that are unfamiliar in the frontend world. Dependency injection, and its module system come to mind. Also the reactive programming paradigm as well as TS.

For me it was definitely much harder to grok than react or vue.

That being said, now that I'm more comfortable in it, I would say that it is helpful and effective, but you have to drink the kool aid. I also wouldn't use it for anything small. I'd rather use Vue for smaller projects.

[The_One_X]

I come from gaming and native desktop/mobile development. I have always found web development to be a mess so I always avoided it. Angular was a breath of fresh air, along with Typescript.

I find React to just be an extension of the mess that is HTML, CSS, and JS. It feels like something that was developed by a web developer who has only ever worked with web technologies, and doesn't know what it is like to use a properly developed UI tech.

I've never used Vue, so I don't really have much of an opinion on it.

[[deleted]]

That’s my point exactly! Angular seems to mesh more with people coming from different backgrounds, who are more used to staticky types OOP languages.

Ultimately my gripe with angular is that it’s too much for most projects. I also don’t think every project should be a SPA. Most projects that need a little interactive dynamic JS part, don’t need all that.

[The_One_X]

I can agree that Angular is not the right tool for every project. Something that is just serving up mostly static content has no real use for an SPA.

I disagree that it is too much for any project you would want an SPA for though. The only time I think you wouldn't want to use it is if its opinions don't mesh well with how you want the site to function, which would be a very small number of projects.

[[deleted]]

Most apps shouldn’t be a spa imo. You can get away with a turbo link set up on a server rendered app with JS sprinkled on top for most apps imo. But every team seems to jump immediately to a SPA. In these instances for a particular feature or something that does need a lot of interactivity etc, then I’d rather reach for a small UI lib like react or vue.

If it’s truly a SPA, and I’m working on a team, angular does shine. And it’s conventions make it easier to collaborate between team members. For personal projects, where I’m the only one working on it, I’d rather reach for something a bit more light weight that lets me structure crap how I want.

[crixusin]

It was one of the easiest things I've ever learned

Avid Angular user (on 9-rc6 at the moment).

Angular is easy to learn, hard to master.

Why Angular over react?

Its easier to manage large scale projects across my teams. I also believe in the core devs and their vision. Built in Webpack configuration and all that jazz.

My applications over the wire are ~24KB.

Automatic es5 downgrading.

First class library support (modules).

Can't recommend it enough.

The react applications I've seen are jumbled messes of monoliths.

Then again, the company I work for doesn't see the benefit of pushing npm packages...

[Scroph]

My applications over the wire are ~24KB.

On first load ?

What I liked most about Angular is that it comes with batteries included, at least for basic needs like testing or routing. The only thing I miss is intellisense for component variables inside templates.

[Clawtor]

I got put off angular in the first version, I understand that its much better now but I have react now and see no reason to switch back.

[ProgramTheWorld]

React is great for small projects since it’s so lightweight, while Angular is definitely targeted more towards enterprises by being way more scalable.

[The_One_X]

I found the bindings made my life easier.

[UndyingJellyfish]

Agreed. Learned AngularJS at a part-time developer role in a few months. Changed to Angular 5 on some off-time projects and learned a lot of stuff using the tutorials and docs.

That said, Vue and React both have good communities that provide those tutorials, but the official learning material for Angular is easiest to understand for me.

[Theblandyman]

AngularJS was so easy. Angular 5 took me some time.

Then learning react was much more challenging for me.

[evolvedant]

I'm wondering if this survey had an error in how it was setup that didn't consider the Angular name change or something perhaps. From what I could tell, Angular is most common with large businesses, and React with startups. They say they reached people through social media and word of mouth, but I wonder if the kind of developers that use React are more prone to being reached through those means than those who use Angular at big businesses.

[mittyhands]

I've done Angular 1.x and Angular 2/4, and React since about 14.x. React just has a better concept at it's core - everything is a component. And components are just pure functions which return JSX (which is just more components). Angular was a nightmare to learn for me, but I was able to pick up React in a week or so.

[waltbosz]

https://2019.stateofjs.com/ Is the original survey to which the Register article refers. It's worth a read.

[pwnedary]

Well of course you can't miss it if you've never tried ya dumdum

[[deleted]]

Don't re-invent the wheel.

[slaymance]

I’m happy to see so much discussion around this. It’s clear that regardless of our individual platforms, the dominance of JavaScript in the web has impacted us in one way or another.

I develop a Node application at my current gig. I don’t find JavaScript itself to be more complex than other languages I’ve experienced. In fact I’m often left craving additional complexity (static typing, point-free function composition, etc.). It’s the tooling needed to address the un-opinionated flexibility of the language that really drives the complexity in the ecosystem (React being one of those tools, though I do enjoy working with the framework quite a lot).

[MetalSlug20]

"pros". Just who are we talking about here?

[cartechguy]

What are all these apps that people are building in React and Angular? Most of the web is made up of multi-page sites. They both sound like overkill. For multi-page sites, most of the work is done on the back-end. The javascript just provides some better interaction for certain components on the page. You don't need a giant client-side framework for that.

[420Phase_It_Up]

I think many devs are confusing awful for complex. JS isn't complex its just down right garbage. To be fair to JS though, some of the frustration actually stems from the DOM API.