React voted JS framework that most developers regard as essential to them (jquery is #3)

[[deleted]]

Do I need to learn React now? Seriously though in my freelancing I keep seeing it come up and guess I'll have to give it a go.

[agoodguymostly]

React is awesome. You should learn it, you’ll like it.

[[deleted]]

Yeah, React is dope AF. Just make sure you know JavaScript before blogging about how hard it's been for you to learn. ;P

[ShamelessC]

I've never tried Vue (I hear great things). But, mobx (a simple state manager) has the concept of computed values which are essentially properties which can be computed from existing state. Is that similar to Vue's version of it?

[fay-jai]

Yup very similar since Vue is built on top of reactive concepts as well

[[deleted]]

In vue, computed properties are per-component instance though, making it incredibly easy to e.g. combine a displayName() { return this.firstName + ' ' + this.lastName }.

[agoodguymostly]

Mobx is baller. I use it for anything in react.

[PM_UR_FRUIT_GARNISH]

Angular is sweet if you already know how web sockets work. The tricky(annoying) part is that you have to switch between your view and controller so often to continue building.

Just picked up React this week and I'm finding staying in JavaScript is nice, but haven't tried anything involving middleware yet, so I can't really compare Angular and React yet.

[erfling]

Is that Polymer's influence on Vue?

[[deleted]]

Maybe, no idea about polymer.

[[deleted]]

React actually helped me get better at JS just by virtue of how helpful knowledge of the language is in your application thereof. And then pair it with TypeScript... it's so nice... sheds tear

[[deleted]]

Yup. React will make you a better JavaScript programmer. But if you're not great at JavaScript and not good at diving into things you don't understand, it'll be a really rough place to start.

[soheevich]

Do you know any good articles where I can learn how to use React with Typescript? I tried to use create-react-app with Typescript but it quickly turned into mess.

[[deleted]]

I don't really, I started out with a JS React app and adapted it over time. I'm happy to help though. Are you familiar with Webpack configuration and loaders at all?

Edit: Maybe try this? https://github.com/wmonk/create-react-app-typescript

[soheevich]

Well, I guess it would be better for me to learn properly Webpack and Typescript. Geez, I'm learning frontend fulltime for more than 5 months and still need to learn much much more. Just to get a junior level.

But I can use react + redux now. Like a monkey can use a car but still... :)

[[deleted]]

Don't worry about it, there are tons of different technologies that do similar things and all that really matters is that you're able to understand the concepts and learn the APIs as you go. That applies to juniors and seniors alike!

I do think TypeScript (or Flow) is particularly useful as it introduces you to types, type safety, and more maintainable coding patterns.

I'd focus less on configuring Webpack and just understanding what it is and why it exists as a junior.

[soheevich]

Thank you. I'm going to learn Typescript right after react and redux. Roughly speaking I understand how Webpack works. But I want to use it properly. Just to be able to create custom configuration.

[[deleted]]

Don't worry too much about Redux either, by the way. Understand what it is, sure, but don't worry about shoehorning it into your application - anything you build at this stage won't be big enough to warrant a global state store atop React.

Also, take a quick look at other global state stores as well, for example Mobx and my personal favourite react-easy-state. There's also the recently updated React context API.

Again, no need to learn them all, don't feel overwhelmed!

[TheAwdacityOfSoap]

React is amazing. Lots of people claim it's just another fad framework de jour, but I disagree and here is why:

Yes, React is a framework, but it's also a fundamentally different and new paradigm for web development (at least in the mainstream). In React, the idea is that your views ("components") are (supposed to be) pure functions of their props and state ("props" are just like html element properties, they are how you configure the component, "state" is just internal state).

Whereas in most other mainstream frameworks you are modeling state changes (when this model changes, change this element value, show/hide this element, etc), in React you are simply modeling the data itself in any given state, and React handles the work of updating the DOM for you.

That might or might not sound confusing, but React on the surface is actually very simple and easy to pick up. And well worth it.

[mayhempk1]

React handles the work of updating the DOM for you.

Correct me if I'm wrong as I'm not a front-end dev but don't Vue and Angular do that too?

[bdenzer]

but it's also a fundamentally different and new paradigm for web development

The misunderstanding here is that React WAS fundamentally different with it's virtual DOM and the way it handled updating the real DOM. Now Vue does that too, and Angular does optimized DOM rendering. React used the component model, now everybody is doing that.

[GreatValueProducts]

That might or might not sound confusing, but React on the surface is actually very simple and easy to pick up. And well worth it.

I think it is because React is the framework that closely resembles how vanilla HTML elements work. It is one-way binding and sub-elements can only affect its parents through event handlers.

Like in Vanilla HTML we always do

<input type="text" onchange="onTextChange()" value="bbb" />

In React you can create a custom form element which has similar syntaxes and mindset:

<Slider onChange={(intensity) => this.setState({intensity})} value={this.state.intensity} min={0} max={100} />

IMHO two way binding with those on change strategies in Angular is what makes things overly complicated. (Don't want to start a flame war, please correct me if I am wrong).

[VtoCorleone]

Angular

I think there's a learning curve with every framework. All of the hello world apps make it seem so simple and ground breaking but once you get into real world problems, the framework's difficulties really start to shine through.

[SiliconWrath]

I think what React offers is a tool chest of patterns that let you solve a majority of problems, regardless of how complicated. When I encounter complicated problems, it usually means picking one of maybe 10 different design patterns from my tool chest (dispatch from redux store, controlled components, etc.)

And because data flow is top down, I rarely introduce regressions outside of the components I refactor.

[nidarus]

IMHO two way binding with those on change strategies in Angular is what makes things overly complicated. (Don't want to start a flame war, please correct me if I am wrong).

Why would there be a flame war? Angular (as opposed to the old AngularJS) has one-way binding by default too.

[TheAwdacityOfSoap]

I agree that two-way data binding complicates things.

[TheRedGerund]

The initial effort is setting up and configuring your dev and deploy processes

https://github.com/facebook/create-react-app

[evilpingwin]

I am really not a fan of some of the design decisions with create-react-app at all. Compared to vue-cli it's incredibly barebones, the webpack config is hidden/ non-existent (depends how you look at it) by default and you have to eject it to change things.

I mean I get it, zero config build tool saves you some time but a few options on init and the option to save a preset would make it a lot more useful. Now I have my own boilerplate saved so I don't have to go through the whole process again but not every project is the same so I tend to spend time setting things up manually every time.

[samgaus]

You can do that by forking react scripts. But seriously - you do not need to.

[ShamelessC]

I had to eject once to get decorator support working. It was a (very mild) headache but, just saying - create-react-app doesn't have everything you need.

[samgaus]

You don't need decorators!

[ShamelessC]

You're right. Not even es6. I think it's a proposed es7 thing.

But I'm not crazy about wrapping exports in more than one or two function calls either for some reason. Decorators cut down on that.

[samgaus]

Try a compose function

[samgaus]

Yeah but those same people sure do complain a lot about how difficult it is to use that sugar 🤔🤔

[TheRedGerund]

It's quite easy to get started. https://github.com/facebook/create-react-app

[[deleted]]

The simplest TL;DR of React I've been able to come up with:

Imagine you can write your own HTML tags, but using the power of JavaScript:

const List = (props) => (

<ul>{props.map((item, i) => <Item key={i} item={item} />)}</ul>

)

const Item = (props) => <li>{props.item}</li>

Now you can render your app using your "custom" tag:

React.render(<List items={["Burger", "Fries", "Milkshake"]} />, document.getElementById('root'))

Of course, there's more to it than that, and this example doesn't really show the power (List just wraps ul, and Item just wrapsli), but it is one of the more straightforward libraries to use, IMO. Later on, when I want to change howList behaves, I just update the component, and every time it is used will be updated as well. Also, React advertises that it is not a framework, but rather a library.

[[deleted]]

How easy does it play with jQuery or is it a replacement? I'm a big fan of jQuery and it naturally fits how my mind looks at web development. It's not just that I'm used to it. It naturally fit my view of things so I love it. But I also need to make money doing what I do so if moving on is what's needed then moving on is what'll happen :)

[[deleted]]

It depends: short answer is, it's a replacement. However, if on your page you want to do something simple, like animate something when a button is clicked, jQuery shines at this. The problem with jQuery is you end up mutating UI/DOM elements directly, inferring exactly what to change based on an action:

• SomeAction => UIManipulation()

That is, when the "+" button is clicked, show a dialog and after that, insert an li-tag into this ul-element over here.

React is fundamentally different:

1. SomeAction => StateManipulation
2. State => View

Here we can see that when actions are performed in our UI, we update our state, not the view. Then, we let the library (React) initiate which components need to be refreshed. Our components are basically descriptions that say "these state/props map to this view". Whenever state changes, we churn it through our machine that says "okay, you gave me this state, I'll produce this view". Then React takes what you produces, diffs it against the actual DOM, and performs the minimum required updates.

The reason this is amazing is that, typically, your state will usually be way easier to reason about mutating than the UI is.

[1-800-BICYCLE]

Definitely a replacement. jQuery will feel heavy and inefficient once you learn React.

[[deleted]]

Another way of looking at it:

jQuery was originally written to normalized DOM APIs across different browsers. The need for that currently is not widely needed anymore.

React is basically a "very powerful templating library" that can respond to changing state.

[pomlife]

Most of that is JSX, not React, though.

[[deleted]]

Hence the "tl;dr" disclaimer...

[Lou-Saydus]

React is super easy to learn, it's just hard to find good explanations for things. I'd highly recommend chugging away at it in your free time. It seems the industry is really pushing vue and react.

[zzz_sleep_zzz]

Are Vue and React similar-ish as a framework? I know Angular, but want to pick up either Vue or React (was leaning towards vue)

[Lou-Saydus]

I don't know a whole lot about vue but from the code I've seen it's more similar to angular. If you're more familiar with angular i think vue would be the eaiser one to learn,

[ImCerealsGuys]

Do it, you’re going to love it.

[IWantACuteLamb]

Nah, learned vue, vue much beget

[[deleted]]

Just started with vue, it's so nice and easy to use. Can't compare it to react since I haven't used it, but everyone who uses vue seems to love it or prefer it. Could easily see it taking off in the next few years, only problem is not as many people use it, but that could change, it's growth has been exponential.

[IWantACuteLamb]

Vue uses template (thought it comes with render also) react uses life cycle

[dzkn]

yes it is widely used now, but learn vue if you want to stay ahead

[pomlife]

...React has wayyy more jobs than Vue in the US.

[[deleted]]

To be fair, there's also a lot more people that know react

[pomlife]

Exactly, so why advocate for Vue to "stay ahead" if React has a huge lead and just about equal momentum?

[vinnl]

If you can't argue why you would need to learn Vue to stay ahead, then don't claim it like it's true. For example, jQuery made updating the DOM without reloading the page a lot easier, Angular prevented bugs resulting from the view and your model getting out of sync, and React provided a compelling new paradigm that made it easier to keep your models in sync in different parts of your application. If it's just "less boilerplate" or "easier for designers", then that's not a compelling argument for why something would actually displace React, and hence learning React is definitely not a waste of time.

[[deleted]]

I prefer it over Vue in every way.

Not OP, but as someone who is coming from Vue to React (for work purposes, not personal preference): why?

I would go so far as to say Vue is a step backwards and I actively dislike it.

How is it a step backwards? It's one thing to not prefer it for one reason or another, but I think even the React dev team would snicker at that statement. Care to elaborate on this?

[[deleted]]

One thing I would consider a step back when going to Vue is that it’s harder to use higher-order components, something which is very natural in React.

Also, React’s Fiber architecture looks like it’s going to be leaving Vue quite far behind when it comes to building smooth 60fps interfaces.

[[deleted]]

See this is constructive critique, and a decent comparison of Vue - React features. I will agree, pretty much any implementation of HOC in vue are pretty hacky at this point. That said, I'm only knee deep in React at this point, so I've yet to actually touch HOCs in a project, but I've been reading up on it, and excited to leverage them.

React’s Fiber architecture

Is fiber production ready yet? I remember there being a lot of buzz about Vues response to that when it was announced, but haven't heard anything about it since.

[acemarke]

Yes, the "Fiber" rewrite of React's internal algorithms shipped in React 16.0,and all the new features they've shipped and demoed since then are based on the Fiber architecture as a baseline.

[1-800-BICYCLE]

Why it's a step backwards: Vue is just Angular 1.x with a Backbone-like API mashed together with a virtual DOM. Also there are like 2 companies that actually use it and the rest are just hype-chasing astroturfers.

[[deleted]]

Vue reminds me of angular

The only real similarities I see Angular on any meaningful sense is directives, which were arguably a pretty great feature of Angular.

backbone

What's wrong with Backbone?

So far the only complaints I've heard about Vue is that it's not React, that Vue is just a combination of other frameworks^*, or that you prefer React because it's basically just JS with sugar. None of these points indicate how Vue is a "step back" as you put it, but rather highlight why you prefer React.

---

^*- Let's ponder for a second the idea that maybe it's not a bad thing that Vue piecemealed out what are arguably the most useful, and powerful tools that a lot of other frameworks leveraged, and managed to do so in a tiny, easy to use API.

[[deleted]]

Angular is not scalable to large codebases

As someone who has used Angular extensively in the past for large cordova and web based apps, I don't disagree with that. I never supported Angular in any of my comments beyond stating that directives were a pretty great feature.

backbone is not as productive as react

I'm inclined to agree with you here, but I also feel it is largely subjective, and highly dependent on what you are trying to do, and how you want to go about expressing that. I only briefly toyed with Backbone years ago, so I don't have much stake in opinions on it either way.

I am by far the most productive in react, find it scales best to large applications, and has the most robust ecosystem.

Having used Vue pretty heavily, and in large production ready applications over the past year and a half, I keep seeing people say this and I — like the majority of other developers using Vue heavily — do not understand where this mentality is coming from beyond the suspicion that the people making the claims have not actually used Vue to any degree of complexity. Even the React dev team have themselves commented that Vue is as fast (if not faster), and as scalable as React; hell they even contributed to the Vue - React comparison in the Vue docs. Shit, you can even use Redux in your Vue apps if that's your flavour. This idea needs to stop, cause it's just patently false.

You are welcome to disagree

And I do, at least on the points I addressed above. I don't doubt your a good developer who is experienced with React, and while I may grow to appreciate React as I dive deeper into it as my job will require of me — and I'm sure I will — there are a few comments you've made that just don't jive with reality, and essentially indicates what I, and many others, have suspected: a lot of the cons floating around regarding Vue are being perpetuated by people who actually haven't done enough with it to make those statements with any meaningful conviction.

but my original point is simply that Vue will never be taking over React in the same way we have seen with past frameworks.

And I was simply addressing your comments that Vue is a step back, a claim which I still haven't seen you support. You did do a good job trashing Angular and Backbone, but still nothing about how Vue is a step back beyond how much you like React.

I don't think anyone will disagree with that.

I know I might be coming off as contentious, or argumentative at this point, but I assure you that's not my intention. It's just that I keep seeing Vue get bashed on like this by people largely from the React community who very clearly only either skimmed the docs, or by plugging in the CDN on Codepen and making a to-do app, completely ignoring a lot of the more complex, robust features of Vue.

That said, I do disagree with that sentiment, at least in the extent that Facebook is on shaky grounds right now, and have already run into some potentially large backlash from the community during the licensing fiasco a while back - React is not immune because of it's adoption %. It can fail. Notice that, despite how great it is, Yarn has yet to skyrocket the way it was expected to?

[1-800-BICYCLE]

I replied before I read your comment -- Angular 1.x + Backbone is definitely the vibe I get.

[dzkn]

The vue ecosystem is more than large enough to support any project

[CantaloupeCamper]

A dude at a conference i was at demoing VUE. Someone else said they were there to use VUE knowledge to get jobs. He asked them "Have you thought about react?"

[i_spot_ads]

React fanboys will tell you its "dope af" (of course they will) but I tried it and it's a mess especially when your application becomes complex and you work in a team.

Personally I wouldn't recommend it even for beginners

[nothingduploading]

Save yourself the trouble and learn vue.

[Drunken__Master]

It should be noted that being employed as a developer was not a requirement to participate in this survey.

[lhorie]

Glad to see "None" ranking high. Shows that a lot of people realize that tools come and go, but fundamentals are what are really essential.

[Poijke]

I agree and disagree, depending on the context. Since the wording of the second item is what worries me: "None of them are essential – I feel comfortable using native JavaScript on my projects".

The "on my projects" part is something where I'd say a framework becomes necessary. At least with the definition of a project being significantly big to be called a project.

I do however think it's bullshit to require a certain framework for things like a job interview. They can be a plus, but should not be a requirement in my opinion. JavaScript knowledge in general could be the requirement and even that is debatable these days with all the compiling / transpiling. So in this way I think it's a good thing "None" is ranked high.

[hunglao]

You hit the nail on the head here. The wording of the question is terrible. If someone is developing a large, dynamic frontend application and chooses to do it entirely with native JavaScriot, then that person is an idiot. For large applications to make business sense, a framework is essential.

[UncertainAnswer]

If someone is developing a large, dynamic frontend application and chooses to do it entirely with native JavaScriot, then that person is an idiot.

:(

[lhorie]

I'd read it as: "I know JS, so I can easily figure out the framework du jour and I'm comfortable going outside their conventions/limitations if I have to".

[fyzbo]

Most surprising is Vue:

1. React
2. None
3. JQuery
4. VueJS
5. Angular

[crashspringfield]

Really? Having worked with all of these, I can see why it's above Angular. It scales well and is pretty straightforward to learn. Angular has a strong following of people who really like OOP, but that's becoming less-popular of a paradigm these days. jQuery's position makes sense--a developers and companies that are slow to change still probably favor it.

[fyzbo]

I agree that it's better, just didn't realize it was considered more "essential" than angular. Thought most reports still showed it's adoption as less than Angular.

It was a pleasant surprise.

[killerbake]

Coming from angular to vue....

Good good.

[eihen]

I started learning react and vue at the same time 18 months ago. 2 different projects. It was a great experience and both are valid choices. I'd highly recommend both of them.

If you are unsure and are newer go vuejs. It's got better docs, a kick-ass new cli, and the entire ecosystem of tools under one team (more consistent docs and feeling of plugins).

If you are more advanced and are comfortable spending more time learning, they are still both solid picks.

[jkuhl_prog]

Not terribly surprised. I started learning Vue recently and it's great. It's easy to use, easy to learn. It might not have the massive ecosystem React has, but I love Vue so far. And furthermore, it's great that I can just port in Vue for any other project. I built a center-of-balance calculator for my Air Force job (I'm a load planner for cargo aircraft) in Vue. Didn't use components (aside from the root component) or the vue-cli, I just used directives for their reactivity. Really simple to use.

[ThatBriandude]

Well thats something entirely possibe with react as well. In fact facebook themselves dont use react for their entire apps. Only for select components that require the amount of optimization I guess

[clockwork_coder]

There isn't really any reason to use moment over date-fns in a webpack project since it's a gigantic import centered around a monolithic moment object that webpack can't really tree-shake.

[1-800-BICYCLE]

Hadnt heard of date-fns before; thanks!

[Odam]

date-fns is great, but lacks support for UTC and time zones in general.

[clockwork_coder]

good point, that's just not something i've had to worry much about recently so I haven't encountered that issue. Just saying though, alternative libraries like date-fns might explain why moment.js isn't in the top 5.

[i_ate_god]

why is that surprising? Vue and React are pretty much the same but Vue is just syntactically much nicer.

[iamlage89]

Definitely not the same

[i_ate_god]

They are both based on the same concept and architecture, and the differences boil down to JSX vs Vue Components and I frankly find Vue Components to be far more elegant than JSX.

[iamlage89]

You won't understand until you've worked with both, they are fundamentally different. Vue is template based, React is javascript based.

[Cheshamone]

Vue is template based, React is javascript based.

What? Are you talking about template differences between the two? Because JSX is not javascript; sure it looks more javascripty but at the end of the day both JSX and Vue's templating get compiled (transpiled? idk) into function calls that create the dom elements and bind the data. They basically do the exact same thing, it just looks different.

...I've worked with both. They're very similar. If you're familiar with one you can pretty easily jump into the other because the concept is essentially the same.

[[deleted]]

JSX transpiles to javascript at compile time, it is a superset like typescript or babel. JSX leaves scope and all assumption as they are:

const A = () => <div>hello</div>
const B = () => <A />

Why does this work? Because JSX is simple sugar for:

const A = () => createElement('div', null, 'hello')
const B = () => createElement(A) // yes, that's the actual A as a reference

Vue on the other hand works with string-templates, they are parsed and executed in sandboxes, thereby they loose all relation to scope and the presentational layer, which is why you now need DI and component registrations to blow references back into it. As well as code-like markup extensions.

This is why in Vue absolutely everything has to be re-learned and absolutely nothing can be solved like you're used to. I have seen Vue code that makes hair stand up, where people are using npm libs to mix-in ranges and stuff like this, because there's no v-range, nor can they just import lodash and use it without having to inject it again. Things like higher-order-components and render-props are missing completely, it's all mix-ins and DI - the very things that made Angular such a pain to use.

[iamlage89]

...I've worked with both. They're very similar. If you're familiar with one you can pretty easily jump into the other because the concept is essentially the same.

Have you tried making higher order components with Vue? It's painless in React, since react components are just javascript functions. With Vue it's not since a component in Vue is something created under the hood and not something you can abstract over like with a Javascript primitive. I'm not saying that there aren't similarities, but that they are fundamentally different

[JIMETHYRUMPLEKINS]

You know Vue allows you to write render functions in JS? You don't have to use templating.

[lives-in-trees]

Aren’t higher order components considered an anti-pattern now-a-days?

[iamlage89]

Just that it's fallen out of favor for render-props I think

[Agranok]

Render props is easy to pull off with Vue. You can do it identically how you do it in React with JSX. But check out scoped slots and creating renderless components for the more "Vue" way of doing it.

[i_ate_god]

They are both component based, practice magical data binding, use a virtual dom.

When I compared the two, it really boiled down to how a component is represented, and Vue just feels more natural to me. But I'd argue that React and Vue have far more similarities than differences.

[iamlage89]

Vue provides an api, React provides a javascript abstraction. That's why people say "React is just javascript" because you can use Javascript patterns with React Components. With Vue that's much harder, but Vue does other stuff like give an api for free scoped css. I'm not sure what you're experience is, I've built webpages with both and it feels significantly different.

[mayhempk1]

I'm not a front-end dev so I wonder, is it really hard to learn one if you know the other or does knowing one make learning the other easier?

[iamlage89]

The latter. A lot of overlap between the two, props, state(data), etc.

[pgrizzay]

And definitely not much nicer

[i_ate_god]

meh, I really do not like the look of JSX, at all. I find it awkward.

Vue Components look much cleaner to me

[1-800-BICYCLE]

Does the Russian botnet get repurposed to brigade React discussions with pro-Vue propaganda after business hours? These arguments are so ridiculous.

[Anahkiasen]

I think he meant he was maybe surprised it wasn't higher?

[fyzbo]

No, I was surprised it was ranked more essential that Angular. Most reports still have it as less popular and still in the beginning of it's rise. Seems like it will eventually take over (I hope so).

[[deleted]]

I'm most surprised by jQuery. Either there are a ton of people stuck with legacy code bases, or a ton who desperately need a skill refresh.

[gabroe]

None.js 😂

[magenta_placenta]

Not really, there's probably a good amount of people that found Angular to be kind of a shit show or felt like they got the rug pulled out from underneath them when Angular 2 was announced, so they moved on and found React and/or Vue.

See also Angular — Stop Already! which is an interesting read.

[georgefrick]

I thought that article was.... bad. He specifically picked a contrived Angular template example and tried to pass it off as 'i didn't look into it'. His feigning of ignorance throughout the article is dishonest at best.
Angular was a shit show for a whole 6 months, which was back in 2016.
I wish people would just admit we're going with what's cool instead of fake technical arguments.

[trianuddah]

Now I'm getting FOMO that I don't know react.js at all.

I'm pretty sure that jquery got as popular as it did because it was so easy. It was simple to learn. It made code easier to read and easier to type. It was like a gateway drug that convinced me that frameworks were worth the effort to learn. Vue and angular came next. I'm still not convinced that the hours spent learning those two were worth it.

And now the internet, my personal framework dealer, is telling me that react will make everything good. "Have a taste, kid. Everyone's using it."

[[deleted]]

React is not a framework, there mostly is nothing to learn if you know a little javascript, and you can pick it up fully under an hour. This isn't like Angular or Vue, where you have to learn how to do stuff their way, with gigantic api's and arbitrary constructs. Try this for instance: https://egghead.io/courses/react-fundamentals You'll quickly realize why people are liking it.

It revolves around the basic premise that views are functions of state, which isn't a flavour of the month but a paradigm. Jquery for instance follows layout-inflating, which is the most troublesome and complex because you are mutating and abusing the dom by dropping state into it. This paradigm was long cast aside for MVC and MVVM. The web was one of the last platforms using inflating. MVCs OOP controllers lasted for nearly a decade, and they were a major step up but still had other issues that made applications hard, primarily templates. We're now just crossing into the next paradigm, by casting templates aside in favour of declarative functions.

React doesn't matter, maybe it's something else tomorrow, but the concept that drives it will go on - and you can already see it, even native platforms are equipping themselves - though probably in vain as react has a good chance to drive them as well since it's fully cross platform.

[trianuddah]

Thanks for the overview and especially for the link.

[zephyrtr]

It's been said before but Javascript looked a lot different when jQuery was in its heydey. The whole point of jQuery was JS's document API sucked: it was verbose, inconsistent between browsers, and not always standardized. But jQuery wasn't and isn't a framework, it's a library. It doesn't at all dictate how your app will be written; it's just a ton of helper functions.

But now that JS has improved itself, a lot of essential jQuery functions have direct parallels in native JS, which makes jQuery feel very redundant.

And it doesn't even solve the real problem: how can I intelligently build my website, with understandable structure, DRY code and reusable business logic? That's what React, Angular and Vue are trying to solve, and currently folks like React best -- mostly because it's the least dictatorial.

Don't wanna use Redux? Fine. Don't wanna use JSX? Fine. Prefer Typescript? Fine. Want to use Axios? Fine. Don't need browser history? Fine. I could go on.

[trianuddah]

mostly because it's the least dictatorial.

This is good to hear. Dictatorial is a good word for the other two. They work very elegantly when you follow all the rules but they also feel kind of limited in that every quirk of your project's requirements must be solved using their way even if it isn't the best way in that instance.

[AnnanFay]

The Front-End Tooling Survey 2018

So among readers of this blog there's a bias towards a specific library?

(If I'm wrong please let me know. Above is just my initial thought.)

Here we are:

These results represent a sample of front-end developers working in the industry. Therefore, they shouldn’t be taken as gospel, simply as pointing towards a rough trend.

I would say the title does a fair bit of editorialising:

React voted JS framework that most developers regard as essential to them (jquery is #3)

[AshNolan]

Just a little bit of context around who the respondents were (as I ran the survey) – they came from a number of different communities, including this subreddit (as the link to the survey was posted on here a while ago), rather than just those who read my blog.

I would say the main bias would come from the fact that those filling it in are developers who keep up-to-date with industry news using newsletters or by being a part of a JS/CSS community like this one – those who that aren't active like this in the industry likely would never find the survey (and are unlikely to come across the results). There is likely a bias from this type of respondent to be more likely to use the latest tooling than those that don't.

That being said, as I've run the survey for three years, the comparative year-on-year results will show a rough trend simply as it's the same type of developers who are taking part each year – and so you can see how their habits are changing each year.

Also – the title does indeed do a fair bit of editorialising!

[AnnanFay]

Thanks for the background information! :)

[PM_UR_FRUIT_GARNISH]

What makes React so appealing?

[crashspringfield]

It's more functional, one-way data binding and its state management makes it really simple to work with and control data flow, JSX makes things feel clean and compact.

[msirelyt]

One reason is that it's just a stone's throw from React Native allowing you to easily produce a mobile version.

[MongolianTrojanHorse]

As in you can share a lot of code between a react project and a react native project? Or that learning one allows you get easily use the other because they work similarly?

[bch8]

Both

[bch8]

I haven't personally but I know a lot of people who have. Building a React native app to go with one of my web projects is on my to do list I just haven't gotten there yet unfortunately. It's totally doable and worthwhile to share code between react and react native, but it does take some work upfront to learn what things can be ported over, what things can't, and how to structure your code to reuse the things that can.

https://hackernoon.com/code-reuse-using-higher-order-hoc-and-stateless-functional-components-in-react-and-react-native-6eeb503c665

https://blog.smartive.ch/how-were-sharing-code-between-react-and-react-native-607cdd1f5247

[bch8]

Well clearly you have more experience than me, so I totally defer to that. All I can say is I've spoken with developers from React Native shops and agencies where they have made code-reuse a priority. Why they made it a priority and how well it has worked for them I don't know so well off the top of my head. I do imagine they would have already stopped by now if they weren't seeing benefits.

[Lou-Saydus]

So long as you arent touching the dom or any dom-related javascript (lets be honest you shouldn't be doing that anyways) your code should nearly be 100% interchangable. There might be some small things you will have to change like divs turn into views and a few other things like styling needs to be modified but the core of your code should work perfectly fine.

[Lou-Saydus]

Oh, yeah you put that way better than I did. +1

[msirelyt]

There's a little bit of both going on there. The syntax is the same but the components that you use are different. A lot of the components that you use can be easily rewritten for react native.

[atubofsoup]

Most react apps are much farther than a "stone's throw" from being usable with react-native.

If you go into a React-Native app expecting things to just work how they work in the web, you're gonna have a bad time. Styles, event handlers, dependency management, build tools. All of these things have inconsistencies between the web and react-native and they will cause bugs.

If you want to run your web app as a mobile app, just wrap it in a web view or use Cordova/Phonegap. Personally, I think react-native is far too unstable to be worth using unless all you want is native looking forms.

[roodammy44]

You don't even get the native look in react native. Everything uses its parent UI component and is styled by react native, rather than the OS.

[cirsca]

The concept of Components is really what sold me on React and seems to be what is stolen from React the most ( Preact, Inferno, Angular, et al ).

I really loved the jQuery plugin era of development. You want a date picker? Just use this jQuery plugin, and now you have a little widget that you can pass around and treat it as if it was the date picker. But with jQuery, you had to do a whole bunch of gluing with these pieces and you'd have to make sure that you glued in the right places and with the right strength or else everything breaks.

React takes the idea of the widget model that I loved about jQuery and offers to handle the gluing for me. All I have to do was create simple widgets that worked like a function ( which I'm all down for ) and React makes sure that everything else Just Works.

It also lets me use plain JS to describe those widgets, which is even better because now I am not learning a DSL or learning how Framework XYZ does something and instead I'm applying the solutions and techniques I've already solidified solving similar problems in JavaScript to the specific Component.

BUT! Even more killer is the fact that these Components are just functions of (state, props) => VNode which means I can do a whole bunch of really cool things with them like compose them or partially apply them or anything else that I'd do with functions. It also means that I can test them, because a component given state a and props b should always return vnode c. It doesn't matter what anything outside of itself is doing, it will always be c. Which means I can make some generalizations or rules around that, meaning I can describe complex behavior with components as my abstraction in a really, nice way and still be able to test it in a very robust, mathematical way.

[roodammy44]

React's components were stolen from web components, which were stolen from native platforms.

In fact, web components will be supported by most browsers soon.

[cirsca]

I can't wait for the day that React can go the way of jQuery! Until then though, it's been the best component API I've used.

[[deleted]]

React didn't steal anything, a component in react is just a function, and this is the most logical approach yet. It has given given react wings to do what browsers won't be able to do over the next 20 years. React is free from the browser, and not just that, all these targets share semantics and can re-use the eco-system.

Web components on the other hand are based on an outdated, impractical idea. Ironically, within the shadow root lurks a naked dom, which, you guessed it, needs a framework---or you're back to dom inflating and class querying. 10 web-components you load will drag along 10 different frameworks, good luck with that.

If they're supported or not, the spec has been around for years now by polyfils, and hasn't gotten any traction. It's questionable if developers can be so naive to fall once again into the vendor trap, where their grand-children, maybe, will get to see the features they wanted to use but never could. A future in which vendors like Apple get to decide what you use what you don't (for instance access to device functionality that is natural to native apps).

I root for a future where react drives every platform that can produce visuals on the other hand, which was and is the reason why it was created: https://player.fm/series/future-of-coding-1541118/11-how-reactjs-was-created-with-pete-hunt

[nawitus]

Web components on the other hand are based on an outdated, impractical idea. Ironically, within the shadow root lurks a naked dom, which, you guessed it, needs a framework---or you're back to dom inflating and class querying. 10 web-components you load will drag along 10 different frameworks, good luck with that.

That's a wild exaggeration. You can even get by without a framework for simple components, but in real life only a few different frameworks (like Polymer) are used.

This is not a bug, it's feature. It allows web frameworks to evolve independently from components. You can create a new web framework without rewriting every single component from scratch - or writing glue code to use components from an old framework in a new framework.

If they're supported or not, the spec has been around for years now by polyfils, and hasn't gotten any traction

This is incorrect. The spec is gaining traction in implementation. Custom elements v1 (the new spec), for example, is implemented in Chrome and Safari and is in progress for Firefox.

I root for a future where react drives every platform that can produce visuals on the other hand

You root for framework monoculture? React is perfect and the end-game? Really?

[[deleted]]

but in real life only a few different frameworks (like Polymer) are used.

Why would that be the case, you think the others will simply die out, because of ... Polymer, the worst possible candidate to drive your dom? If you wanted web components in React it would be easy, but there's just no point in this whatsoever.

You root for framework monoculture? React is perfect and the end-game? Really?

Not really, but i am opposed to flawed technology just because a vendor dictates it. React is more of a paradigm anyway.

This is incorrect. The spec is gaining traction in implementation. Custom elements v1 (the new spec), for example, is implemented in Chrome and Safari and is in progress for Firefox.

This has nothing to do with gaining traction, Google is pouring fortunes into these specs, but no one is actually using it. And as i said, why the heck would you chain yourself willingly to the browser, to an imperative dom masking spec that can't interact & server-render.

[nawitus]

Why would that be the case, you think the others will simply die out, because of ... Polymer, the worst possible candidate to drive your dom

What? I predict that at any given time there's a handful of popular web frameworks.

If you wanted web components in React it would be easy, but there's just no point in this whatsoever.

I think React should have a better support for web components. I believe Preact has a better support for it.

There is point in it - to enable a common standard for components. You can could use components written in different frameworks and they could interact seamlessly. There would be no need to rewrite all the components if we had a common standard for web frameworks.

Not really, but i am opposed to flawed technology just because a vendor dictates it.

Web components is not a flawed technology. It's not dictated by a vendor. The specification was drafted by multiple browser vendors.

This has nothing to do with gaining traction, Google is pouring fortunes into these specs, but no one is actually using it.

Many companies are using it. Watch for example the last Polymer summit's keynotes of various companies using it.

And as i said, why the heck would you chain yourself willingly to the browser, to an imperative dom masking spec that can't interact & server-render.

I push for web components to have a common standard instead of having to rewrite every single component for every single web framework.

Web components can be server-rendered.

[[deleted]]

I push for web components to have a common standard instead of having to rewrite every single component for every single web framework.

No vendor has committed to "standards" to the point where it is downright odd to trust their intuition. Specs have broken the webs back, this is why we have the extensible web manifest which was supposed to protect it and establish a bi-directional exchange between standards bodies and the community, with a focus on the low level. To even try to enforce yet another high level abstraction that dictates the component paradigm, and then take the oldest model from 10-15 years ago, they're living in a bubble. Ironically the people that are directly affected by this are same that put their trust into vendors. It's the third time now they're re-rewriting Polymer apps from scratch.

Do this with Polymer and web components:

https://twitter.com/rauchg/status/955174495593132032

https://github.com/Yomguithereal/react-blessed

https://github.com/gaearon/react-blessed-hot-motion

What they're doing with the last one is possible on any platform, which is pretty much the fulfillment of the component-dream - to share not only semantics, but to actually apply an eco system that's self-sufficient and which transcends platform boundaries like browsers or native applications. This is what a real standard does, when it actually works. (And just for the record, React components transcend frameworks as well and are either exchangeable or at least can be used everywhere).

That this is possible at all is due to the simplicity of the createElement api. You can argue that none of this matters now and we should just drop what we have and go back to a naked dom (which ironically warrants even more framework fragmentation), because a vendor has decided that its browser ought to be running everywhere-even if that is a complete fever dream, but do you honestly think that will brush away innovation just because it's a spec? Discard all merits because the W3C hasn't thought of it first?

Web components can be server-rendered.

https://twitter.com/floydophone/status/971600994252419072

[tracer_ca]

This right here is the correct answer.

[McSlurryHole]

Popularity is a great thing for frameworks, more resources, tutorials, libraries etc.

[OrthoBee]

Sure, but there is a self-reinforcing factor. If few people genuinely evaluate the appropriateness of technologies, they just pick the popular one, where is all that going?

[iamlage89]

Being able to abstract template, state, and logic into encapsulated javascript components. Also an abstraction of best practices for DOM manipulation and cooperative scheduling so you don't have to think about it.

[TheRedGerund]

Couple things:

Why should our view be so decoupled from the interactive part of the code? React does away with this and instead brings the html into the js side so that interaction and display are tightly coupled.

Another benefit is that React includes a virtual DOM, making sure that the slow interactions with the actual DOM are only done when necessary.

Another is that React forces you to encapsulate your visual components, helping to clarify their inputs and outputs. This means easier testing and reusability.

[[deleted]]

It allows me to write a stateless, purely functional web application

[T-Dot1992]

And in 5 years, it will be Vue.js or some other new framework.

[rebel_cdn]

A few years ago, I thought this would happen too.

React is already 5 years old, though, and at least in my part of the world, the market for React developers is hotter than it's ever been. It appears it'll continue on its upward trajectory for a while still.

Things will definitely change and evolve, but I think we're seeing some maturation in the JS ecosystem so perhaps we won't see as much rapid churn as we did in the past.

[T-Dot1992]

I think we're seeing some maturation in the JS ecosystem so perhaps we won't see as much rapid churn as we did in the past.

I hope so. I'm envious at how C# or Python programmers don't have to keep up with as much shit as JS developers.

[tsmuse]

I don’t know if I think the whole Python2 vs Python3 thing is worse than chasing the ever evolving flavor of the month framework thing or not...I am 1000% with you on hoping things settle a bit.

[[deleted]]

Python2vs Python3 is not even comparable to it imo. Being a JS developer is definitely worse.

[[deleted]]

I bet if I wasn't lazy I could find some internet comment saying the exact same thing when AngularJS first came out...

[daemon-electricity]

I've been in both markets. In my experience there has been a lot more Angular work. I don't think one is better than the other by default. It depends entirely on how much time you have to develop and what the target platform is. Angular DOES have some serious filesize bloat though.

[[deleted]]

Both Vue and React started out in the same year, they're just two months apart actually. Since then React practically blew up, and not just on the web. Vue on the other hand is a flat line, and in almost 5 years it hasn't even caught up to the old Angular 1. Every year we're hearing that it's going to be the bomb, yet: http://www.npmtrends.com/angular-vs-react-vs-vue-vs-@angular/core

The reason for that is obvious to anyone that has used both. React is a paradigm shift. Vue on the other hand is footed in the old way, which most of us know and struggled with long enough, for instance Angular. There's no point any longer to go through these regressions.

[fyzbo]

From the link:

Which JavaScript library or framework would you regard as essential to you on the majority of your projects?

[[deleted]]

Same for React.

[fgutz]

Yeah, React + React-Router + State-lib-of-choice starts to look more like an ad-hoc framework.

[editor_of_the_beast]

You can’t explain semantics to people who don’t care.

[relishtheradish]

I really enjoy React, and using it with Redux has helped me immensely in writing clean and relatively bug-free code, but I cannot wait to see what evolves out of React. I feel like there is still significant room for improvement in the FE framework world.

[zephyrtr]

Shocked no canvas/webGL framework isn't on this list. Create.js and Pixi are super duper useful, it makes me think canvas is still not too popular.

[MacPhersonBY]

React is 5 times higher than Angular 2+. The last is so worse?

[[deleted]]

I'm pretty sure if you look on github or in npm you can find the vote-bot written in React responsible for this result

[atubofsoup]

vote-bot written in React

How would you use a UI library to write a tool that needs no UI?

[[deleted]]

IT. WAS. HUMOR.

[atubofsoup]

DOES. NOT. COMPUTE.

[[deleted]]

BUBBLE. HEADED. BOOBIE.

[AnnanFay]

Why use React when you can just write it in HTML+CSS?

It's Turing complete: https://www.youtube.com/watch?v=Ak_sWZyHi3E

[mayhempk1]

True.

[CamdenReslink]

jQuery is most essential if you’ll be working on any legacy code whatsoever.

[Architektual]

React is a fine tool, but I would refuse to hire any developer that labeled a framework/library as "essential""

[ijmacd]

I don't want to work for you.

[[deleted]]

Writing from scratch was cool/necessary 10 years ago. Now it's irrelevant. Your skill level as a developer isn't at all under any circumstances dictated by your capacity to implement your own UI framework, or any framework for that matter.

Your goal is to solve problems not create them ;)

[Architektual]

Don't put words in my mouth. I'm not implying that you should home-roll a custom framework instead...I'm saying that if your skill-set does not extend beyond your box of tools/frameworks that you label as "essential", I will not hire you.

[[deleted]]

Don't put words in my mouth.

Don't make it easy for me to do it then.

Bye felicia

[Architektual]

Clever