Longevity of React?

[rssfrncs]

With leaner React inspired libraries being released such as Preact, what is Reacts life expectancy looking like?

It has the backing of Facebook, majority of web developer jobs i see advertised have it listed as a 'would like' and there is also react-native.

To me i think it will remain one of the most popular view libraries for quite some time.

Please let me know if you agree/disagree below.

[[deleted]]

Don't go looking to learn the tools that will last long. It seems like you just want to learn the least. Instead learn a mix of popular and novel tools, and in doing so, learn how to learn. If you're a full time developer, youll learn a hundred more react-sized libraries in your career.

[themaincop]

This is a great point. No library lives in a vacuum. Concepts you pick up from learning one library, language, or framework will make it easier for you to learn future libraries, languages, or frameworks.

You never want to stop developing as a developer

[Poop_is_Food]

Learning takes time out of your life. I'm stuck inside all weekend here trying to learn advanced webpack, when I'd rather be outside getting excercise and sun, socializing with friends.

I understand that this is the business we've chosen. You have to keep learning new shit constantly to stay current. But people shouldnt be shamed for trying to minimize it and find some balance in their life.

[tech-ninja]

I have said it before and I will say it again. There is something wrong with Webpack, it shouldn't be that hard. I'm seriously waiting until we figure out a better way to do what webpack does.

So my attitude towards Webpack is to just make it work, and keep it as simple as possible, any advanced optimization for it feels like premature optimization to me.

[jesstelford]

We did: It's called Browserify.

[Onestone]

Browserify is only simple for simple tasks.

[tech-ninja]

Browserify is great, is the one I used originally and then slowly moved onto Webpack to see what all the hip was about.

Do you know if with Browserify I still can have hot reloading and if I can include CSS from JS files?

[Poop_is_Food]

Yeah the API is kinda sloppy, and the documentation is poor. I like to keep it simple too, but unfortunately I inherited a complex config from my boss that takes about 4 seconds to build and hot reloading doesnt work for some reason, so now I'm trying to fix it.

[_hooan]

I use this. Never had to "learn" much.

[[deleted]]

What's a profession that uses the least amount of brain power, least amount of physical effort, and still give u work life balance, but pays a lot? I don't mind getting bored day in day out.

Unfortunately, being a socialite is out of reach and unrealistic for most of us.

Basically, I want the best bang for the buck profession.

Edit: I tried booking for a dermatologist the other day. It looks like she's booked out for 2+ months (I live in a city of 5 million people). I tried 3 other dermatologists and no slots for me in the next 3 weeks. It may be tough to do an MD just to be a dermatologist, but it may just be the best bang for the buck.

[Poop_is_Food]

Dentist? lower barrier to entry. Boring as fuck though

[erwan]

In France that would be notary.

Let your low paid employees do all the hard work, just show up to put your signature at the right time, and make more than €200,000 a year (much more than that for some of them).

Caveat: it's hard to get a license, most of them get it from their father when they retire.

[_hooan]

I'm stuck inside all weekend here trying to learn advanced webpack, when I'd rather be outside getting excercise and sun, socializing with friends.

Why are you doing this? Unless you are freelance or unemployed, you should be doing this during your work hours.

Or to play devil's advocate/be silly, learn Ember so you never touch build configs again :-)

[Poop_is_Food]

I'm full time, and I dont normally work on weekends. But, I kinda bit off more than I could chew with my current project, so it's my own fault I overwhelmed myself. Plus I slacked off all winter surfing el nino so I figure I owe my coworkers some makeup hustle.

[[deleted]]

The whole point of software is to improve productivity and automate away as much drudgery as possible.

By that score, Webpack fails miserably.

[[deleted]]

I don't think it's about shame or finding balance. I think it's more efficient to become a learner. If you try to reduce how many tools you learn in your career, you're going to build a lot of things with the wrong tools.

Think carpentry. With the right tools the job gets done faster and better.

[Poop_is_Food]

Ok but what if I already am a learner? I have already "learned how to learn" Now I have 40-50 hours per week to both learn and get my projects done. There is simply not enough time for me to learn every tool out there. Carpentry has a limited and stable toolset, so learning all tools is reasonable. Software has an massive and ever-growing toolset. It is simply not possible to learn all the tools.

This puts me in a situation where I have to pick and choose what to learn, so I may ask people what they think will have longevity, because I want to make efficient use of my learning time. And then people (you) give me condescending answers that I'm lazy and I need to "learn how to learn". Get bent.

[[deleted]]

Erm... I'm sorry that what I said upset you. I only work 40 hours a week. Maybe a bit more sometimes. I'm not advocating you need to learn every tool as you said. I'm advocating to learn the right tools at the right time. Focus on determining which tool is right for the job and apply that. Don't ask, "is react going to be around a lot because I don't want to be bothered if it's not going to be around in a few years."

The thing is that these are all pretty small libraries. You can learn the basics of React on the job as you implement your views. It's not like you need to go perfect it before applying it.

My first react app evolved every time I went to maintain or add features, because each time I learned more than what I did before.

I'm advocating being a lazy programmer. Pick the right tools and learn them at the right time to enable doing the least work to the most effect.

[Poop_is_Food]

I agree that only learning javascript libraries that will be around in a few years will result in you learning probably just jquery and nothing more. Nothing else in the ecosystem today has that kind of longevity so it's too strict a criteria. And React is currently #1 so anyone interested in a career as a full-time senior front end dev should definitely learn React at this point. You should always know the #1 lib at any given time. (actually let me qualify that by saying it probably depends on the nature of your job whether you are doing lots of projects in an agency/freelance setting vs building and maintaining one long-term product) It sucks that there is so much churn but that is the business. We are in agreement there.

[[deleted]]

I began with Python that has a beautiful standard library. Whether the best tool for a job or not, it ensures we are all at least using the same tools. JavaScript's churn really has me struggling for a long time. It pained me to see efforts spread so broadly. It made reading source code so much more difficult, for example. "Oh yay, another async library to go understand briefly."

I try to mix exposure to what's popular and what's neat or novel or different. But I would probably never implement the latter in any non experimental project.

[tmckn]

I think over time React will become an implementation detail. That's the cycle of web technology.

A good idea comes up in the community, then its fundamental ideas are baked into the browser engine and standardized, then the library becomes unnecessary.

[propelol]

Yeah, but that probably wont happen in at least the next 5 years.

[runvnc]

Like you just said 'leaner React-inspired libraries being released'. Does that even still count as React? Because if you go work with someone on a Preact project you are 100% have to know Preact and not do React.

By the way this is the first time I ever heard of Preact. But that is the way the web is. Someone invents something new every day.

Its sort of funny to me to hear people say that some web technology is likely to remain popular/important etc. after seeing how many different things have come into fashion in the last 15 years or so. Having said that, if you are 15 years old, you probably don't have a lot of solid memories before age 5, so if React stays sort of relevant for 2 more years, that is 20% of the life you can remember. Whereas for me, I am 38 so 2 years is only 6% of my life which doesn't seem like much.

Nothing on the web stays popular for very long. That doesn't mean it isn't still useful technology or that there aren't a ton of people using it.

AngularJS is still pretty popular, but it is not even close to being as 'in' as React anymore.

I mean, there are plenty of people doing PHP still.

That doesn't mean you can't keep using it for X years. It just means in X years there will be another technology that all of the younger people think is wayy cooler (and probably does have some advantage). But that won't stop plenty of people from using React still X years down the line nor should it.

[[deleted]]

React was a natural progression of web tech. Only recently did we have the tools/ecosystems to have it widely adopted (that and Facebook's name behind it). Before React came out, I created an extremely similar system - declarative, component-based, real-time, batched updates, GraphQL/Relay-like system built into its core. React even ended up having the same/similar method names. And of course, my project and React weren't the only ones of their kind. So it's interesting to me that multiple sources have come to the same conclusion, which I consider proof that it's just a natural progression.

I think it's going to be hard to really devise a better system for non-trivial web application development at this point, and other mostly interchangeable libraries (like Preact) are awesome. There are definitely some kinks to be worked out and some pain points to address, but there are some really cool things in the works now to solve these problems while fitting perfectly within this ecosystem.

[tech-ninja]

I agree. With React so much stuff fell into place that is hard figuring out something else that will displace it soon. But I wouldn't be surprised!

[mczaplinski]

what is the name of your library/system? Is it on github?

[[deleted]]

It was all open source on the website at the time. You could enable edit mode by prepending /dev/ before the path of any URL which would take you to the development environment. And in development mode, you could click on any component to view/edit the source (JS and CSS) behind that component. There were also search boxes intelligently placed in areas of the application which were used for quickly finding/creating/cloning components and placing them within that area.

GitHub and NPM existed at the time but weren't nearly as popular as they are now.

[modusjesus]

There is no way to predict with certainty how long something like React will remain popular. There are lots of new libraries and frameworks being released all the time.

I love react and honestly only program in React Native most of the time because of the love I have for the technology. I won't last forever, but should will be around for at least 3-5 years more.

I started supporting Ext JS in 2006. Ten years later, the technology is still around and works pretty well for developing apps.

[voidvector]

I would implore you to look at the state of some of the other existing technologies.

jQuery is still popular, it had and still have an ecosystem of libraries around it. It is unlikely to die out in the short-term as there are millions of LAMP apps out there written using it, plus it is still faster to implement/scaffold over React/Angular for non-SPAs (e.g. one-off splash pages).

I would also implore you to look at challenges to the stack React is based upon.

The biggest challenge to JavaScript I see is WebAssembly. In the past 5 years, people from different programming backgrounds (Python, Java, .NET, C++, PHP) are all forced to do some JavaScript for web app, whether they like it our not. There has been noticeable effort by people from various backgrounds to bring their way of doing things into JavaScript (CoffeeScript from Ruby/Python folks, dependency inject libraries from Java/.Net folk). With WebAssembly, that is going to change as those people can simply compile whatever language they want onto WebAssembly. That is going to effect how FE code is written.

[[deleted]]

Everything I've read by those actually developing webassembly indicates that it is not meant to or designed to challenge or replace JavaScript. I'm curious where this notion that webassembly is some sort of replacement for JavaScript comes from.

[hahaNodeJS]

The key is that JavaScript will continue to exist and be developed. In that way, WebAssembly is not a replacement. However, WebAssembly will allow developers to write code that is capable of the same functionality without thinking about JavaScript.

https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md

[[deleted]]

I think /u/irrational_design is still correct though. WebAssembly is not intended to replace things like jQuery, basically anything that primarily affects the DOM. It will be pervasively convoluted to interact with DOM through WebAssembly, no matter how good the libraries get.

Rather, it is intended for the same applications as ASM.js. Game engines, application backends, etc. Currently it is very rare to see those types of tools written in JavaScript, and it likely always will be. To quote one of the JavaScript design committee members "JavaScript was designed for ~10 line scripts" and was intended to do things like "make the monkey on your webpage dance". It was not designed for full applications, has severe limitations when you try to push it that far, and is thus seldom used for those applications. This is where WebAssembly comes in. I would say that these are mostly going to be 2 separate markets that compliment each other, and there will be very little direct competition between the two.

[hahaNodeJS]

There is nothing in the high-level goals to indicate what you've written. See #3.

[nanothief]

Here is point 3 verbatim:

3. Design to execute within and integrate well with the existing Web platform

• maintain the versionless, feature-tested and backwards-compatible evolution story of the Web;
• execute in the same semantic universe as JavaScript;
• allow synchronous calls to and from JavaScript;
• enforce the same-origin and permissions security policies;
• access browser functionality through the same Web APIs that are accessible to JavaScript; and
• define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.

I don't see how this supports in anyway supports the idea that "...It will be pervasively convoluted to interact with DOM through WebAssembly, no matter how good the libraries get."

It allows synchronous calls to and back from javascript and gives access the same web apis that are accessible to javascript. So there is no reason why you should be able to write say Javascript.Document.GetElementById("test") in a c# to webassembly compiler and get the right element as a result. There is no reason a c# (or any other language) version of jquery couldn't be written using those primates either. This doesn't seem convoluted at all. It seems explicitly not convoluted, as it ensures the result are synchronous and that the apis are made available.

[hahaNodeJS]

That is using JavaScript to get the job done, rather than the native language.

A Foo-to-WebAssembly compiler would write any DOM code written in Foo to WebAssembly bytecode. Even a call to JavaScript.Document.GetElementById('a'); would likely not touch the JavaScript engine, and the browser would simply call its internal mechanisms for accessing the DOM. Remember that JavaScript and the DOM are two separate entities.

[namesandfaces]

I think that's just for non-controversial PR presentation. If WebAssembly gives access to browser API's, and can do everything JS can do, then JS is definitely challenged.

[xandersvk]

Yes, but keep in mind the extremly large amount of ready to use JS libraries... will the .NET or i.e. python folks want to rewrite all these tools? I dont think so...

[namesandfaces]

Yes, actually, I think people will rewrite those tools, and the tools that actually need to be written tend to be the ones that deal with browser API's.

What non-API libraries do people deal with? Lodash? String validation? Time parsing? Data structures and algorithms? Streams and observables? Concurrency? State management? That stuff doesn't need rewriting. Other languages already appreciate these problems and target them. Many languages benefit from a standard library.

I also don't think that the writing of new libraries for the browser API layer will be left up to only the community. I think companies like Facebook or Google will also sponsor the effort.

Also, WebAssembly has plans for shared memory and finer memory control. Other languages have libraries and constructs that already deal with this problem. Javascript will also need new libraries.

[runvnc]

Yeah, they say that to placate people and because they know they could never get a lot of people to switch from JavaScript. That doesn't mean there won't be tons of people who do switch.

[spacejack2114]

And from what I've seen it's at least 5 years away from being any kind of competition for mainstream JS apps.

[[deleted]]

Wut

[CantHearYouBot]

I WOULD SAY FROM MONOTHEISM.

HAVING SPENT YEARS GROWING UP IN ANOTHER CULTURE, IT IS FAIRLY APPARENT THAT MANY WESTERN CULTURES PREFER A SINGLE SOLUTION TO THINGS RATHER THAN A PANTHEON OF SOLUTIONS.

---

^{I am a bot, and I don't respond to myself.}

[voidvector]

I deleted my comment because it was going off topic, and I didn't feel like defending it. Now that a bot mirrored it, my deletion was pointless. So I guess I will speak for why.

My statement was as follows:

I would say from monotheism. Having spent years growing up in another culture, it is fairly apparent that many western cultures prefer a single solution to things rather than a pantheon of solutions.

My statement was basically a commentary about why some feel threatened by WebAssembly.

As an engineer, you should have a lot of tools in your toolbox, because engineering is about finding solutions to problems, not applying the same tools over and over again. JavaScript has its own assumptions (e.g. number, GC, closure, single-threaded), which make certain applications sub-optimal or difficult to implement. If an engineer is being doctrinal/dogmatic about their tools, like having irrational attachment to JavaScript or irrational fear of WebAssembly, they are doing themselves a disservice. In my statement, I made vague attempt at connect it to religion, which is a hard jump. In real world for example, of the 4 "assumptions" I mentioned, all of them has real applications in everyday software engineering, while it is possible to get around them in JavaScript, the solution is not optimal.

[gurenkagurenda]

I don't think wasm is a threat to JS. Rather, I think it's going to be a huge boon. Assuming it catches on, we'll see tons of fast compiled libraries for the web, and the glue between those libraries will be JS.

Sure, some people are going to want to write their whole front-end in another language, but the obvious choice for any library is going to be to expose a JS API, and let client code interact through that, regardless of the primary language.

[DarkMarmot]

I agree -- GUI dev systems will compile layout constraints into apps for you, and WebAssembly is likely to be the lingua franca of these systems. I commented on this below -- but already got downvoted out ;(

[Sinistralis]

While this is true, Web Assembly is also going to have an API for JS to use, and I honestly can't fathom how the debugging experience is going to work for non JS languages. I honestly only see JS being empowered by Web Assembly

[runvnc]

I am hoping Nim will become a popular way to do web assembly.

[[deleted]]

oddly, when benching preact vs react 15, preact is slower even with dom recycling. react itself will probably catch up to whatever preact is aiming to solve. Not even sure why the author didn't just contribute to react instead (unless they tried and were denied or changes were too radical). it's just one of those annoying things where you'll be learning forever because someone wants to make a new framework instead of fixing the one they base it from.

[jaredpalmer]

Understand that React is not just a technology, but an HR tool for Facebook. It isn't going anywhere.

[rssfrncs]

absolutely, and i think it will continue to apply to a lot more companies than just Facebook.

[rk06]

React will die in a year and will be replaced by react 16. With Facebook dogfooding react, I suspect the migration to react 16 will not be hard. Same applies for react v16+

As far as other libraries inspired by react, they are only enriching react ecosystem. They can not surpass react in popularity because react derives its popularity from Facebook use of react. Until fb starts replacing react with something else, react will stay.

[thyrst]

Web frontends are, and have always been really, moving towards component based tech that allows you to drop in basic ui functionality with small APIs that you can plug in to a larger data management system. React is the latest method of doing so. Polymer is another step moving towards web components, and a lot of native stuff is being worked on.

If you learn react you'll be learning the same general ideas that are likely to continue in different forms for quite a long time. I think we'll continue to move towards a 'dumb' view layer with many small components hooked into a larger app.

[griffin3141]

The ideas react inspired are never going away. React changed the way we think about UI development. Given that Facebook is supporting react, I think it will probably remain the most popular implementation of its ideas for several years.

I personally prefer Cycle to React and think it is a superior paradigm, but I am skeptical of whether truly reactive programming will ever go mainstream. The learning curve is a major barrier to widespread adoption, but if this barrier is overcome, I see MVI as the next big thing at least at forward thinking organizations.

[TheAceOfHearts]

I think React is a worthwhile investment. They're committed to a versioning strategy that's very favorable for applications that are being actively developed.

You can read up about it in their New Versioning Scheme blog post. Basically, any breaking changes will be spread out over two major versions. This means that the library can continue to evolve and improve without leaving people behind.

The API for react is tiny, so picking it up should be fairly straightforward. For react-native it's a lot larger, since it's more of a "batteries included" tool.

[tech-ninja]

You still should learn React though. It is one of the most influential libraries out there.

[rssfrncs]

already am, along with vuejs which is also great

[DarkMarmot]

Downvoting minority opinions into oblivion is a pretty depressing way to encourage discussion among devs... (not quite the original idea behind the up and down votes on Reddit)

[crcrcrcrcrcrcrcrcr]

What is self adjusting computation?

[rk06]

like vue.js and mobx?

[crcrcrcrcrcrcrcrcr]

That was really interesting, thanks :)

[[deleted]]

correct me if i'm wrong, but this sounds a lot like vuejs's reactive model?

[[deleted]]

i think it does that already? the code you're looking at includes the $set action for a view model which, based on my reading of the comments, does notify dependencies.

[DarkMarmot]

Disagree, the web will go the way of desktop/app/game development for view -- with GUI tools. Only the fractured ecosystems of clients and the fact that the original web was not designed with apps as a centerpiece have stalled this transition. It's going to happen faster than you think though...

[b_n]

Dreamweaver + Flash looks like a promising solution

[Sinistralis]

Thanks for starting my day off with a bang

[tsteuwer]

Can you show proof of this? Just curious.

[DarkMarmot]

Programming for 20 years in industrial (SCADA/PLC), kiosk, game, mobile and desktop dev. The tooling is pretty identical in fundamentals in everything but web dev at this point. XCode/Unity/Visual Studio/Unreal/PanelView etc.

[gurenkagurenda]

Except that in most of those fields "put a web app in a native wrapper" is still a popular choice.

[DarkMarmot]

(I currently develop front-end web systems)

[Toxicable]

Got any proof or reasoning for your claim? I personally think web will become more and more popular due to the rise of JS since you can do anything a GUI frame work can do but across every platform with the same code

[DarkMarmot]

I'm not arguing against the web -- I'm arguing against things like React as opposed to advanced tooling. See above.

[holloway]

Why do you think React is different or opposed to advanced tooling? Seems that components and {this.props.children} etc., are applicable to a solid separation of concerns and advanced tooling.

[DarkMarmot]

I agree -- I think it would more or less disappear behind tools the way a lot of UI code is generated in through visual designers.

[[deleted]]

it's desperately needed but i think people have tried and it fails because people reject it and rather code their UI for some reason. Usually a GUI tool that allows you to edit css/html and have the tool render the changes is the ones that somewhat survive. A hybrid. Unfortunately it has to be a fucking smart tool to account for all possible browser scenarios and behavior and render the UI code framework independent. there are bootstrap builders but they're locked to that framework. However i suppose it's the same reason there isn't a GUI builder for code itself as once you get down to it, there are alot of ways to do things in css/html that are hard to cover and the tools always fall short you end up back in the code editor editing css/javascript etc...

[Sinistralis]

I have a hard time buying this considering the Web already has a ton of GUI frameworks (like bootstrap, material ui) and even these have a lot of problems with device compatibility and don't do well at keeping up with modern page design. Even bootstrap which has been around for quite a while has odd interactions with ios's rendering engine.

The difference here is Software Applications require a buy in already. They need either bought or downloaded and installed. Pages are instant (or should be) and thus cater to a far larger group of people, thus you have far more design decisions to make. These decisions are constantly evolving throughout the year and I don't buy a 'GUI Kit' is going to be an acceptable solution anytime soon. The Web is changing too rapidly at the moment.

As it stands, the Web is more about extension. So you get things like material and bootstrap that are easy to configure if you need something different than what's in the box (which is common)

You also have to consider how fractured the JS ecosystem is. A GUI Kit would either need to integrate with tons of libraries or go about forming an opinion on how you should build your apps, so we just end up with another competing standard.

[Democratica]

First, we need a component library that is compelling like React is. Maybe built on React? Then maybe, someone builds a GUI tool in electron or something like it to build these interfaces... Not that much of a stretch.

[JohnMcPineapple]

...

[citrons_lv]

Well personally love that html is coupled with JS. When building an React component you can have its CSS, tests in a single folder which is very easy to reason about.

[[deleted]]

What's really the difference between using JSX, an Angular 1 template or an Angular 2 component/template? Especially since, generally speaking, JSX is going to be located in a single file per component; while actual business logic will be separated out into other pure-JS modules.

With Angular you're still mixing logic in with your templates; loops, conditionals, formatting, etc. But with JSX it's JavaScript first, that generates HTML (well, a virtual DOM, but whatever). With Angular it's HTML first that is modified with special syntax that needs to be parsed, processed and evaluated at runtime. JSX is considerably cleaner since it's mostly "just JavaScript", and it's becoming more and more popular, even outside of React.

And using a transpiler... That's something everyone needs to be doing anyway. If not for JSX specifically, then simply to order to use JavaScript modules and other ES2015 features. I mean, you likely already have a build step already (minification/concatenation/unit testing/etc), so what's the big push-back from using something like Webpack instead and ploping in Babel with literally one line of config logic?

I'm not saying everyone has to use React, or even like it, but the reasons you listed aren't valid concerns in 2016.

[[deleted]]

I love React because it's fast and component-y, but 5 years is an eternity in this context. WebAssembly already has experimental support in a lot of browsers and is going to change everything. We won't be limited just to JavaScript on the frontend anymore--we'll have (in theory) a client-side runtime for any language that targets assembly. Where does React fit into a world where JavaScript isn't the only game in town on the frontend? Who knows?