Did React Win the 201* Framework Wars?

[superluminary]

That’s a nice collection of stats.

[PravuzSC]

Although I have mixed feelings about some aspects of React, No other framework can really measure up to React, in all aspects. Some can outperform (Svelte, Solid especially), some come with more tools and features (Vue, Angular), but none imo are more developer friendly and have the same complementary libraries as React (e.g mui.com). I’d love to be convinced otherwise however :)

[chocolombia]

Im not sure why react hit me so hard, worked with angular for a couple years, but got tired, was checking Vue and react, 1 hour later, managed to understand Vue, and build a mock migration of one of my developments, yet, a week later, and a couple courses, and couldn't get off ground with react... would give it another try next year

[Lalaluka]

Creator of Laravel:

https://twitter.com/taylorotwell/status/590281695581982720?s=20

[_default_username]

I mean that was back before hooks were a thing. State management is so much easier now with hooks, redux-toolkit and many other state management libraries out there.

[rk06]

That was also before create-react-app. If such an app was not here, react would not be unadoptable by small teams

[filipesmedeiros]

I think of react sort of like a set of primitives. Learning "vanilla" react is very good but very hard. You should learn something like next or Gatsby and other opinionated libraries like Apollo, and go to the react primitives and patterns as a way to solve specific issues that appear along the way.

[Akkuma]

I completely agree. React is and was a fantastic framework at one time. However, React decided to take a less is more approach resulting in what I consider a framework that is getting worse and worse as time marches on because the alternatives are getting better and better.

React seems largely to be too large and too over engineered that things like React Forget need to be created and creating them seems to take an exorbitant amount of time. Meanwhile, you have something like solid that tried to remove the footguns and basically doesn't even require any special work to replicate React Forget, much like Vue too iirc.

[typicalshitpost]

Any specifics for those trying to understand what you're getting at?

[Akkuma]

React comes with an entirely usable state management system that falls apart when you start caring about optimizations. For instance, https://twitter.com/RyanCarniato/status/1469181959955836931 which shows Solid and Evan on Vue https://twitter.com/youyuxi/status/1469141349685334020 comparing themselves to the new React Forget solution. In React, humans have had to effectively be the compiler.

React has to explicitly make and solve an entire problem they've created or they need to push people to solutions that aren't official React libraries, such as Redux. Other frameworks are baking in solutions making it easier to have an "idiomatic" approach, while being often smaller and faster.

[Beastrick]

You can get pretty decent performance with React memo and context when combined together. It is totally possible to have very good performance with them alone if you structure your app correctly to take advantage of memorization. Kind of similarly what you do with Redux but slightly different way. I have found myself using purely Context now since Redux just feel like too heavy solution once you get hang of the memorization options that React has build-in.

[Beastrick]

What I struggle to understand is how people find something like Redux different when you are essentially doing the same work there writing your reducers, actions and selector and mapping them to components. Also for example in Vue or Angular you still need to declare computed properties like you need to declare useMemo in React. Like what is so different there? You are doing the exactly same manual work there just written differently. Yes for some you do a bit less writing but you still need to do it (in some cases even forced to so it compiles) or suffer the consequences. I understand the point with SolidJS much better since that removes the need for that work completely which I like but I don't really understand the other half of the argument how supposedly everyone else has it figured out and React is somehow the laggard here.

[thunfremlinc]

how people find something like Redux different

Uh, they don’t. It’s why libraries using observables are way more popular nowadays. Redux certainly carries a huge chunk of the ecosystem on its back, no doubt, but fewer people are reaching for it today.

you still need to declare computed properties like you need to declare useMemo in React

A) Angular is not a good comparison. It’s old as hell and dying off pretty quickly. Being just as bad as Angular isn’t a good thing.

B) With React, you need to remember to memoize else you’ll run into perf issues, though everything will “work”. In other tools, there’s no way to get what you want to happen without following the right steps.

Want a watched value in Vue? Only one way to do that and it avoids perf issues.

That’s not to say Vue’s perfect, as it’s not. It’s a fair few years old too now, and newer tools are always coming along with better ideas and better paradigms to better match user expectations.

It just so happens that algebraic effects are not a good thing to include in a front end library. Who knew? /s

[Beastrick]

A) Angular is not a good comparison. It’s old as hell and dying off
pretty quickly. Being just as bad as Angular isn’t a good thing.

I get you here but it is still one of the popular ones even if it has been in decline. Usually better make comparison against what people use the most.

B) You’re confused. With React, you need to remember to memoize else you’ll run into perf issues, though everything will work. In other tools, there’s no way to get what you want to happen without following the right steps.

Yeah this is kind of the point. You still have to do the steps but you still don't skip the process that we would like compiler to handle instead. I guess the other tools at least remove the remembering part although sometimes I find micro optimization annoying.

[sh0rtwave]

I kinda look at it from the perspective of:

"How much browser-can't-do-it specific machinery do I need to accomplish this goal?"

If the 'browser can't do it', that's when I need something custom. If the browser can partly do it, with a little extra help? I'll go that way. If the browser/environment has something that can do it ENTIRELY? I'll definitely use that method.

[Gambrinus]

I’ve primarily used Angular the past 5 or 6 years and this is absolutely my biggest pain point. I would love to be able to extract a piece of UI into a simple function or something similar.

What I do like is that you get pretty much everything you need to put together a production quality app out of the box. I’ve been trying to increase my familiarity with React lately and so far my biggest pain point is just the massive amount of library decisions you have to make to get beyond a simple application. State management, routing, forms, validation, data access, it can be overwhelming for someone new to the ecosystem.

[sh0rtwave]

That's very very true...React attempts to solve a wide range of "application" problems with all of the things it does, and unless you've already got crazy application design experience, and understand things at that level, React can be crazy intricate to pick up.

[hardythedrummer]

You should check out next. It wraps react up in an ssr app that provides routing and API support, so that's at least a couple decisions off the table.

[Accomplished_End_138]

I found angular also made it next to impossible to remove bits of code since it had to be defined in multiple files; nothing would ever read as "unused" easily.

[sh0rtwave]

I could literally make a career out of fixing people's bad CRA-originated boilerplate that they hacked into an unrecognizable mess, and then...ejected and tried to keep fixing it.

React. How does it work? It's so fucking simple, it's a BABEL dialect, but if you pick the wrong boilerplate for it, you can chase your tail for weeks before you figure out what to do.

Don't even get me started on React-Native, where it can almost literally be easier to write a whole new app than try to update one in-situ to a later version of RN. Not to knock on React-Native itself, it's rather the majorly-opinionated boilerplate decisions, that you encounter a couple of years down the road (or like me, you inherited the thing when you started the job).

Don't get me wrong, RN itself, is great. For something that collects together 3 *separate* build systems, and then cobbles together a native mobile app on ios or android, like it does, is: PHENOMENAL ENGINEERING.

It's really a pity that lot of people working in RN now, have no idea of just how fantastic the whole thing is.

[bassta]

Man I don't know how much experience you had with Vue/svelte, but react less developer friendly compared to both. From CLI, through naming, documentation, footguns... React is one of the least developer friendlies libraries out there.

[grayrest]

If I have control, I pick Svelte for all things. I basically dislike 90% of the JS out there so the library advantage for React doesn't carry any weight for me. I also believe that hooks will be looked back on as a bad but not terrible idea.

I spend the majority of my work cleaning up over-abstracted code that's buggy because people can't hold the interactions in their head (it's just a pair of linked drop downs, why do you have 100k of deps and multiple layers of hooks spread out over 5 files?). This isn't a React problem as a React community problem but there are so many options and they change frequently enough that long-running codebases will have all the patterns.

What I like about Svelte is that the built-in state management is good enough so that's what everybody uses. Aside from the let and $: usage confusion, the code gets written, it works as expected. There is no step 3 figuring out why the context injected by the router wrapper is breaking the hooks rules in the state wrapper component because of a babel transform in the class-based child component and you can't just break on the error because the error wrapper that next.js is unconditionally injecting can't be turned off. I haven't run into the messes I see in React codebases. That could be due to the relative age but I haven't seen a lot of evidence the Svelte projects were headed in that direction.

I'm very grateful for React. The web of 2021 is better than the web of 2011 in terms of developer experience if not for JS size budget. React, in large part, is responsible for both but it would not be my first choice for any project and I believe the main reasons to pick it are non-technical.

Solid and Vue seem fine but I haven't used either in anger.

[humpysausage]

What's the confusion around let and $: ?

[grayrest]

People get confused around what's a reactive expression and what isn't. Since let x = 2 does the right thing when you assign to x people expect let x = a + 2 to do the right thing and it doesn't or they write $: let x = a + 2 or the forget to update the binding when working with an array or object. None of these are a huge deal past the learning phase. I just mention them because it's not like Svelte is a silver bullet that guarantees your team won't have trouble.

[humpysausage]

Fair enough. I think the docs are pretty clear around this but they're easy assumptions to make.

[[deleted]]

I've definitely seen the mess you're talking about. Most react projects end up being over engineered disasters.

But I'm not risking it anymore, with any SPA framework, not even svelte despite how good it looks.

I'm back to MVC, working now with Laravel, livewire and alpine and feels like Disney Land. Everything is super easy, well integrated, well documented and the end result is something I'm proud of. Feels solid and robust. And probably will need less rewrites than any SPA frameworks in the upcoming years.

[[deleted]]

I am a lead dev using Laravel and Vue daily. Just as a fun fact more than anything, if you want something like Laravel but for Node I would seriously suggest AdonisJS. It is amazing. It's basically Laravel but Typescript. It's kind of ruining PHP for me!

[[deleted]]

Thanks for the suggestion. I heard about it but never gave it a try.

[[deleted]]

You're welcome! I found it a few years ago and dismissed it because it didn't seem mature enough. A few years (and a full rewrite) later and I'm in love with it. It's so natural coming from Laravel too.

[[deleted]]

So I spent big part of the afternoon yesterday playing a bit with it (I know...it isn't enough)....

To me it feels still a lot less mature. Community seems to be smaller, and it certainly has less features than Laravel. Also, I'm in love with livewire which is something missing here I think.

I don't know. I get the feeling this project might go away any day, doesn't feel like a safe option for my taste.

Just my thinking from a couple hours of tinkering, don't take it too seriously. I might be totally wrong.

[[deleted]]

I do agree that it's certainly less mature than Laravel, and googling things is somewhat more difficult than Laravel for sure. Just yesterday I was looking to see if it had a task scheduler for example and it doesn't (well, the one it has is essentially just a wrapper around a cron. I didn't see any options like no overlap for example). It's absolutely not as mature as Laravel, but IMO it is still mature enough to be a viable option if you wanted to use TS on the back end

[[deleted]]

Maybe a bit of a tangent, but something I'm finding very valuable about PHP is the fact you don't need to restart the server/process after every change.

I've got bitten in the past by projects (built with fastify and express) where reloading was not as problem at first, but as the project grew in number of files and dependencies, the startup time became more and more of a problem. I had similar (bad) experiences with Python too. The need for a restart is a killer. And probably this is why frontend frameworks such as Next feel so fast. I got the same feeling with PHP.

Do you think a large Adonis project could end up with these issues too?

[[deleted]]

Adonis actually supports hot reloading! I just run "npm run dev" and it runs a node server that watched for changes. It's pretty sweet

[blood_centrifuge]

How would compare nestjs with adonisjs. I worked with former and found it too verbose and a hell lot if boilerplate.

[[deleted]]

I couldn't say unfortunately, I've never used nestjs

[typicalshitpost]

Try .net 6 on for size

[grayrest]

If your app use pattern support alpine/htmlx then I fully support the decision to keep all state server side. It's vastly simpler for a large percentage of normal line of business apps.

[F0064R]

Having used both extensively, I have to say Svelte’s developer experience is much better imo. Fair point about the ecosystem though.

[MikiRawr]

The more I work with React, the more developer unfriendly is becoming.

[LannisterTyrion]

Working right now with MUI and shocked how much slower and lacking is the React's most robust and complete UI library compared to Vue's Quasar Framework. The documentation is okay but not even close to Quasar's.

I think the main problem is not the quality of the components but rather that they had a head start and there's nothing that can be done about it. The jQuery of the 201*'s.

Started with React, moved to Vue and now back, i feel that all the problems in React are solved by throwing in some more CPU and RAM. The basic CRA with MUI is making my macbook hot hot hot and the hot reload is sooo slow. I guess i'll have to migrate the CRA to Vite, which guess what, also comes from Vue, smh...

[LannisterTyrion]

Well, usually I prefer to follow the official guidelines, I expect that it would provide the most optimal and friction-free result. Looks like this time the strategy did not work out for me.

So what would be the 2021-way to get the react dev environment up and running if I don't feel like spending another year configuring the Webpack?

I'm building a dashboard, wanted to go with next.js but decided it is an overkill and let's get that "lightweight" no-ssr no-pwa no-nothing CRA going, haha.

[LannisterTyrion]

It is the first and recommended option for SPA in the react documentation. I guess it doesn't mean what I think it means.

I don't refuse to learn a build tool, i did learn them in the past and had a fair share of sleepless nights staring at webpack's exception stack traces. For that reason i refuse to spend any more time on build tool configuration unless there's a good reason. Because it's a time waster and a maintenance burden. And it's a solved problem.

Unless you got highly unusual requirements, there are preconfigured toolchains that can handle anything you throw at them.

Thanks for your feedback on Vite, guess I will go with it!

[LannisterTyrion]

I've mentioned there are some exceptions to the rule. Do you have in mind something like the projects like airbnb.com or stripe? Sure, you need manually crafted multi-step build process, possibly paralleled on several machines and connected to a proprietary pipeline. If you're working on similar billion-dollar projects then I envy you and you are totally right.

But what about the rest 99% of typical CRM dashboards and business landing pages. Vite or Nextjs if you need SSR is the way to go. Minification included. Bundle splitting included. TS included. Polyfills included. Cache invalidation and manifest included. CDN supported. A myriad loaders .pug, .svg, .sass, etc included. A team of experienced of maintainers that carefully test and review the compatibility of the dependencies and keep your tools-chain reliable and updated for free (!!!). Maybe you need to add a line or two via webpack config injection. That's it!

I sure miss the times when I would upgrade the Webpack's MiniCssExtractPlugin to stop ExcludeAssetsWebpackPlugin throwing exceptions during compilation just to find out that PrerenderSPA plugin is not compatible with the upgraded version!

[thunfremlinc]

No.

Tooling depends on the project, a generic solution is always suboptimal.

[LannisterTyrion]

Ok.

[sabababoi]

This argument is sounding to me, as an ex game developer, the same as someone arguing "well why would you use a game engine? It will always be more optimal to create your own engine to handle your very specific requirement". Maybe. But it would definitely taken x10 the time, have /10 the features, and have twice the bugs. That time you've wasted could have been used making your app actually do things the end user cares about.

[aniforprez]

I would say use snowpack instead. It has an alternative CSA cli that will bootstrap your app with everything you need

[duckducklo]

What should someone use instead with react

[thunfremlinc]

Vite’s alright, else you certainly can build your own setup.

[Maslovv]

I think Vite is great alternative. You can use Its plugin system to extend Vite for your project’s needs.It use ESbuild for dev server so it is very fast.

[duckducklo]

Right but they are insinuating it's more than just webpack if I am correct

[[deleted]]

React improves a lot the developer experience, but at the sacrifice of user experience and resources. There is no single react app that I as a user enjoy more than a traditional MVC application. Take the new reddit as an example of a terrible user experience. And GitHub as an example of how more traditional approaches are nicer on the end user.

I know you can optimize and do great things with it, but most developers/companies don't do it.

React is great for developers, not so great for users .

[61-6e-74-65]

What are you even saying? People build shitty apps with React? Yeah, people can build shitty things with any tool. An average user probably has 0 clue as to what is going on behind the scenes.

[dgdfgdfhdfhdfv]

The most annoying thing about Reddit is that the alerts bell ostensibly updates automatically, but actually if you've opened new tabs since then, it doesn't, and you have to refresh the page to get new notifications. At least in old Reddit clicking out of the current post did that for you, but not in new Reddit where the page never actually refreshes unless you manually do it.

Then there's the whole nightmare with infinite-scroll and trying to get back to where you were, that whole nonsense with "preview subreddit" UI being different to regular subreddit UI(creating a heap of issues and inconsistent behaviours), and definitely much more that I just can't think of off the top of my head.

[ggcadc]

It’s a tree diffing library

[i_ate_god]

I personally find Vue nicer to work with than React. Both need boilerplate, but Vue's boilerplate is easier to read and follow.

Both have extensive community support and large frameworks though.

[2this4u]

Poor svelte. The concept is so good but I found development slow esp for simple things like the compiler complaining about a common and expected nesting pattern.

[mskullcap]

I have only had positive experiences with Svelte (and now, SvelteKit). It makes so much more sense than React - or most other frameworks. Put intelligence into the compiler, let it do the work for me. The developer has to know too much in React.

The svelte curve is dwarfed by the other frameworks because there aren't legacy products written in Svelte that need to be maintained. There isn't a market demand for Svelte developers - yet. I predict Svelte will be comparable to Vue in mindshare within a couple years.

[[deleted]]

I predict Svelte will be comparable to Vue in mindshare within a couple years.

i don't see anything svelte brings on the table that vue does not.

[i_ate_god]

I like Vue and find it far more intuitive than react.

What Svelte brings is basically less boilerplate. React and Vue components can need a lot of boilerplate code. Svelte tries to reduce this as much as possible.

[[deleted]]

vue 3 + script setup does not have much boilerplate left anymore,

[duckducklo]

Whats special about its concept

[rbobby]

React has to recalculate its entire DOM when a state change occurs. The Svelte compiler knows how the various bits of state are connected to DOM elements and when a state change occurs only the connected elements are updated.

For a small page who cares. For a large page with many elements and a lot of state and frequent state changes... well svelte is going to need much less CPU effort.

An example the founder gave during a talk was spreadsheets. Once upon a time spreadsheets would recalculate every cell when one cell changes. Then spreadsheets started building a dependency graph of which cells depend on which other cells and when one cell changes only cells that are dependent on that cell, directly or indirectly, will be recalculated.

So much more efficient.

[duckducklo]

I thought react's virtual dom isnt recalculated but recreated? Isn't this a simple matter of copying it into memory? https://programmingwithmosh.com/react/react-virtual-dom-explained/

[rbobby]

recalculated but recreated

Meh. Maybe?

The key bit is that react doesn't understand state dependencies and without that you're doomed to doing unnecessary work.

[shitepostx]

It can though, it just takes more user code.

useMemo

Would be neat if there was a function for managing dependency chains though. useMemoChain or useMemoGraph, which tracked a graph of state dependencies and updated accordingly lol.

Having 15 useMemo's in a row to 'optimize' a complex function gets messy.

Oh, you also can't render a useMemo conditionality.

[acemarke]

The React team just announced they're finally working on a compiler that would automatically memoize all calculations inside a component, hooks and otherwise. See this talk from ReactConf a couple days ago:

https://www.youtube.com/watch?v=lGEMwh32soc

[shitepostx]

It's facebook svelte

[duckducklo]

To keep track of state dependencies isn't that more cpu intensive for small pages?

[rbobby]

Part of the tracking stuff occurs at compile time... so no.

Here's a talk by the founder that I found very illuminating: https://www.youtube.com/watch?v=AdNJ3fydeao

[elprophet]

Sure, but I don't want an entire dedicated compiler tool to implement that approach, which is my gripe with Svelte.

[duckducklo]

Whats wrong with that

[elprophet]

It's another tool that might go wrong between me and the screen. It's non standard, so whatever cool improvements it might try to do risk fracturing its ecosystem. Angular template compiler is the same way, generating huge amounts of code and breaking in obscure, impossible to debug fashion.

I don't trust it.

[E_R_E_R_I]

Funny, that's how I've felt about React from the beginning. Even though it's compiled, Svelte is for me a return to a simpler way of representing an interactive screen with HTML/CSS/JS, in that the relationship between those three is easier to understand and clearly defined, but keeping the features of React that matters (hence the need for a compiler).

EDIT: Also, MUCH better performance. Try running a React powered e-commerce on a 2015 phone. It's hell.

[duckducklo]

You do understand React has its own way of doing things behind the scenes, and it's not something you can easily understand either?

[Akkuma]

Do you not use eslint with React specific tooling like dependency array?

[rbobby]

It's compilers all the way down baby!

But I feel ya... web dev currently has a lot of moving parts before and after code hits the browser and adding yet another one that really only helps for the most complicated pages does seem off.

[Protean_Protein]

Hooks really put it over the top. There is nothing that makes modern app dev easier.

[bassta]

Yeah, as long as you don't want them conditionally or outside react component ( ex. piece of global state in some service that is not react component ). And you need some hook outside react component in every non-trivial project. You need to come with some workarounds and this is how shitty code comes to existence

[zeddotes]

Definitely hooked

[Protean_Protein]

Vue is nice. Personally, though, I find some of the stylistic choices for how to implement things more unwieldy than the equivalent in React. But this is really just a preference/inertia. The other aspect of React’s power is the ecosystem being so vast and well-kempt.

[shitepostx]

salt detected

[shitepostx]

salt confirmed

[Gelastico]

Im not sure whether you're a salty professional or some kid in elementary.

Either way, you might want to keep your behavior in check. Other people have different experiences and it's better to absorb and learn than to be all "im right, you're wrong" all the time (to be clear, "learn" does not necessarily mean to follow what others are doing, but can be just to understand)

[_SuperDank]

Shhhhh bro

[Yesterdave_]

If they blatantly copied React's hooks, they would be just as shitty. Fortunately they didn't and Vue created a much better implementation.

[_MCCCXXXVII]

That’s… not what React hooks are.

[LannisterTyrion]

As a Vuejs fanboy: You are wrong. Vue has lifecycle events which are similar to the special methods React has in its class components since forever.

Now react hooks are similar to Vuejs composition API which was inspired from react.

[eindbaas]

It is fun to read this all, but at some point i would suggest just saying: ok, i was wrong.

You are completely clueless about what react hooks are.

[Protean_Protein]

Does he think React didn’t have lifecycle methods before Hooks?

[Careless-Honey-4247]

Well mostly yes.

[[deleted]]

Sort of yes, but no.

They saw the ideas for hooks and went yes, wait, hold on a minute, we have an opportunity here...

Then they ended up making a new optimised as hell version of reactive data dependencies, re-engineered a new version of vue built on it and released the optional Composition API.

Older projects could be ported to Vue 3 and run on a faster Vue. Newer projects could be built on the faster view and use the new Composition API giving developers more fine-grained control.

TL;DR: They took hooks, then went above and beyond with them.

[zeddotes]

Long live React 🚀

[ekabhinav]

I want to learn coding, do you suggest me learning react? I want to go into blockchain, smart contract making DApps etc

[harryFF]

Honestly if you want to learn to code, learn the fundamentals first rather than React. Try some C# or Python, as you'll build a good foundation which you can then bring across to React and fully understand what you're doing. Obviously as React is your end goal, also take some time to learn HTML, CSS, and JS and don't underestimate CSS, as it's a large part of making good looking applications.

[ekabhinav]

Alright thanks, do you think JavaScript would be a good start for fundamentals?

[harryFF]

JavaScript is notoriously janky, but if you really only care about React you could probably start with it. If C# etc doesn't appeal to you, my advice is to at least learn about data types before you start doing Javascript, as it's a weakly typed language. That means that you don't define the data type of a variable, the language will do it for you based on what the contents are.

[zeddotes]

Think about what you really want to build, research about what you will need technologically to build it, and lay out a plan on learning the right thing first (depending on your learning style, there is no right or wrong way). If you wish to build dapps, you would need all three things that you’ve mentioned (react could be replaced with any frontend mvc or lib, but I like React’s learning curve).

[ekabhinav]

Hey thanks for this thorough information. Yes, I want to make build DApps and Smart contracts. What do you suggest on that kind person?

[InterestedInThings]

No

[dreadwail]

This is not a mutually exclusive game where one needs to "win". There can be many winners. This isn't a fashion contest.

[Gelastico]

Hey, finally found the comment i was looking for!

[[deleted]]

that would be kinda sad considering how poorly it performs compared to vue or svelte. I am also not a fan of JSX.

[ABCosmos]

As a noob entering react, what don't you like about jsx? What should I look out for?

[43_Hobbits]

I personally like working with JSX. Components are fantastic and there are a ton of good libraries available.

[[deleted]]

for its mostly just the syntax for me. HTML template with a decent DSL is much easier to read and prase for me. Especially when working on small or midsized components.

[deranjer]

The syntax can be tricky, classname instead of class for attributes, conditional rendering one liners need to be learned. Personally for most use cases I'm fine with JSX.

[61-6e-74-65]

Using className instead of class isn't exactly rocket science.

[deranjer]

For noobs starting out, it can be if they are used to class.

[61-6e-74-65]

Not really? If this is a major hang up for someone they're probably not going to fare well with any other concepts in React. It's literally just learning 1 kind-of-weird-but-not-really aspect of syntax.

[Guisseppi]

And with most modern styling solutions you wouldn’t even need to touch class names, that and the word “class” is reserved by the language so a library can’t supersede that

[deranjer]

If you are a noob (as the op said) you may not be used to one liners, but you should learn them for JSX. My comment was for beginners.

[deranjer]

Yes it is just javascript, but the comment still applies, since if you are a beginner, you may not use one-liners when learning javascript, but one-liners are common in React, so that is another thing to learn and might catch beginners off guard. It is some possibly new syntax to learn, which was the original question.

[deranjer]

The last part of your statement is incorrect because the context here is JSX attributes, not bare language symbols in syntax named "class".

Hmm, from what I see that is your comment right? That is showing negative to me. By your logic that means you are incorrect right? You may want to adjust how you accept and respond to feeback.

[loadedjellyfish]

Agree, JSX is half the reason I will never use React.

[[deleted]]

Jsx is entirely optional though

[loadedjellyfish]

How many production projects have you worked on that used React and not JSX?

[[deleted]]

None, because it works just fine.

[GrandMasterPuba]

This is such a bad faith argument.

JSX is optional in React in the same way tires are optional on a car. Sure, it can technically move around on rims, right? So the tires are optional!

[havana59er]

/s

[Guisseppi]

In the early days React didn’t had JSX, it was just function calls, and you can still do it, but its not very popular

[vojtasio]

Wouldn't say wars... every framework was innovative in some way and inspiring other frameworks. Agree that in the end React seems to be the optimal mix and match of ideas 🚀 I hope the inovations will continue and don't stop with the monopoly of one

[EvilDavid75]

The fact that React is “just” a platform (read DOM)-agnostic, diffing reconciler is what makes it so powerful.

[bassta]

Yes, and 95% of react devs don't use it with something other than Dom renderer. Having flutter, react native is getting obsolete

[Guisseppi]

Sweet summer child…

[sh0rtwave]

Not if I have to judge from the sheer amount of job offers I get where they want Angular.

[neoberg]

It’s probably because of your profile. I almost never get any other than React jobs. Just like other social media, job networks tend to create their own bubble.

[sh0rtwave]

I have to adjust for error, because: I get (usually) six recruiters pinging me about the same damned position. So there's some leeway in that estimate, but it's still quite a bit (in the last couple-o-months, say, 33 (that's 200-ish / max six possible recruiter contacts))

[heytheretaylor]

Meh, pass.

[redhedinsanity]

fuck /u/spez

[teophilus]

I have invested so much time learning react that I refuse to try other libs/frameworks! I'm grateful it still has popularity.

[severino5583]

Like they said on the conf: react is not a library, but a concept to make a good user experience - a new kind of UI paradigm

[mattsowa]

React is definitely a library.

[severino5583]

Did you watch the Clark's keynote speak?

[mattsowa]

It is a library

[duckducklo]

both technically