[simonw]

"It has been two and a half years since the previous major release of React, which is a long time even by our standards!"

As a mostly Python and only occasional JavaScript developer, it always felt like the biggest challenge in the JavaScript community was how fast everything moved - new libraries, frameworks and ideas would tumble past at the rate of one every few weeks, and it felt impossible to keep up.

I've been feeling that a lot less recently, and maybe the fact that React has been steady for 2.5 years is part of the reason.

[rhizome31]

> As a mostly Python and only occasional JavaScript developer, it always felt like the biggest challenge in the JavaScript community was how fast everything moved

Those of us who were doing Python web dev in the years 2000s might remember that Python went through a similar period where it seemed that every week a new backend framework came out: Zope, CherryPy, web2py, Pylons, Django, repoze.bfg, TurboGears... to name a few. Nowadays it seems that everybody has settled for either Django or Flask. It might not have been as crazy as what happened with JavaScript in the years 2010s but still I tend to see a similar pattern. People try a lot of different things, going in slightly different directions and eventually interesting approaches get identified and communities build up around a couple of solutions.

Meanwhile the Ruby community was able to build consensus around Ruby on Rails, with just Sinatra on the side for small projects.

I'm wondering if this ability to try many different things might have been the cause for Python building numpy and eventually winning the scientific computing area as well.

[simonw]

I do remember that period very well! https://simonwillison.net/2005/Jul/17/django/

[raziel2p]

I do think there's a second wave of frameworks coming, because Django/Flask are showing their age a bit. Sanic is/was really popular and I think FastAPI is really promising.

[rumanator]

It seems that the main difference you're pointing out is Python's transition from synchronous-only/wsgi to asynchronous/asgi frameworks.

[raziel2p]

Sanic is indeed just an ASGI version of Flask, though who knows how it will develop in the future - but FastAPI is a whole other beast. Also, Django is adding support for ASGI so no, that's not the main difference I wanted to point out.

[dawnerd]

I second you on that. The number of times I've had to rewrite code because a framework decided to break everything with little warning.. I don't even want to think about it actually. I get wanting to make code better but gesh people, do some planning and figure out a direction to move a project.

Also it seems JS devs don't understand semver either. Massive breaking changes in patch or minor versions are just evil.

[namelosw]

React is actually pretty decent in terms of upgrading. Also, the idea of semver is more widespread in the JS community and there are things like Angular commits and tools like commitizen.

It has a tick-tock pattern so that you can upgrade and having time to fix the warnings.

The API changes are carefully crafted.

Sometimes there are even migration tools to help you upgrade.

[cel1ne]

There is just some kind of internal resistance increasing the major-version for a breaking change, especially when that change is just tiny.

I have published a library myself and experienced it, going from 2.x to 3.x to 4.x.

After you just do it for the sake of semver though, the resistance vanished for me.

And the second thing: Never use 0.x.x versions, I think those should have been omitted from semver completely, as they circumvent the entire concept.

[rubber_duck]

Big name libraries and frameworks like React and Angular manage things relatively well and in a similar way to other frameworks in other languages (you could argue about AngularJS -> Angular but if you worked with both frameworks you know that AngularJS was a dead end approach designed for a completely different stack and it just didn't make sense to maintain backwards compatibility or maintaining that dumpster of a code base past it's EOL).

A problem in React ecosystem is that it's a rendering library not really a webapp framework so you need to use community provided libraries to fill in the gaps. Those libraries are often maintained by an individual so it's unreasonable to expect corporate SDK approach to development, but unfortunately it leads to a lot of abandonware and rewrites, especially since JS is not very maintainable and it's often easier to rewrite something than to pick up someone else's code.

[skinnymuch]

Which core web app framework feature’s biggest 3rd party React library has been abandoned in the last few years? Or extensively rewritten to the point of seriously effecting end using programmers?

I am relatively new to React. Perhaps all of this happened 3 or more years ago.

I know React Router 4 was released in mid 2017. Perhaps I was too new when I looked over the changes between 3 and 4. It didn’t seem as drastic as the general opinion that JS changes like crazy. I looked at the migration guide again. Still doesn’t look too bad. Maybe it would be in a large code base.

[emteycz]

I am developing with React and TypeScript every day for the past 5 years. Everything I did then works now, not a single line of code needed to be changed. There are new ways of doing things that I am extremely happy with (Hooks, advanced types), but the old way is not even deprecated yet.

[andrewingram]

I'm surprised that you don't see the changes between RR3 and 4 as drastic. It's a completely different API, and unsolved a problem which had (admittedly imperfect) solutions -- kicking off data fetching prior to navigation.

I try to resist hyperbole, but if it wasn't for the brand value of owning the name "React Router", it should (or would) have been released under a different package name.

[rubber_duck]

react-router, react-router-redux, immutable.js was dead at some point when the only dev maintaining it left Facebook (AFAIK, I don't know if it got resurrected since) and people were just moving to immer.js. These are just on top of my head stuff that I had to replace when starting new projects because I didn't want to start a new project on potentially unsuported libs, there were more but I can't remember the names exactly - been a while since I was boostraping a new project.

[onion2k]

I've had similar experiences with JS libraries, but not so much with React. The React team are much better at managing to keep things backwardly compatible than most.

[jakelazaroff]

I really like the React approach to upgrades: if your app works with version N with no warnings, it will work with version N+1. https://reactjs.org/docs/faq-versioning.html

[dawnerd]

Agreed, I'm fairly new to React this year and while it's been a rough learning curve for me it's nice how stable it is considering some of the example code is pretty old and it still mostly works just fine

[rilut]

From my experience, I think it's the total opposite. Airflow and even Python3 itself breaks on minor version.

[nicoburns]

React has actually been stable for much longer than that (say 5 years). There have technically been breaking changes, but in practice these required only minor code changes if any. They've introduced new coding styles (like hooks), but the olds ones still function just fine.

[newfangle]

I do feel like react has won

[wolco]

React won the spa crowd.

Lags behind in server side frameworks adoption over Vue.

React won the enterprise crowd pushing angularjs out.

React hasn't won over the JQuery crowd

If you do primary js it probably has. If you only do some js and other things it probably hasn't yet.

[throwaway189262]

So glad Angular is dying off. It looks nice on the surface but as soon as you try to do something outside the tutorial it gets nutty.

React is at a great level of abstraction between code and UI framework. It reminds me of the MVC frameworks of olde, which by all accounts were great, just limited because they relied on page refresh for everything

[pjmlp]

Given the amount of Angular requests we get, when not doing plain CMS driven projects, that is wishful thinking from React crowd.

[eitland]

I come from Angular (Angular.js, Angular 2, 4, 5, 6 and 7) and now work on React.

React works really well but if I chose it for a personal project today it would only be to avoid switching back and forth, not because I think it is better.

[pedrocx486]

>So glad Angular is dying off.

Uh, I'm gonna challenge you to give a source on that. Your comment sounds extremely biased towards React and dismissive towards Angular. None of those are dying out, I wouldn't we even say they compete directly.

[throwaway189262]

I've worked on Angular stuff for years because my employer won't let us switch. Angular uses too much abstraction.

Angular does crazy things to the templates, to the point that trying to build your own UI widgets is a recipe for pain.

Template meta-language is stupid. It's just similar enough to JS that you mess up the syntax all the time and never really stop. Since it's not just JS like JSX there's not good linting support either.

Related, stupid "pet features" and hydra syndrome. Like Pipes. Why does Angular use these weird pointless things when you can do the same thing with JS built-ins? Just so they didn't have to copy JSX? We may never know. And why are there 2 form implementations that both feel half baked? Why is it so bad to instantiate components for testing? Why does it mangle the code to support dependency injection when decorators and DI support don't even actually exist in JS even in ES2018? Why is Polyfills.js such a minefield? I could go on but really, why are so many things half assed and haphazard. It reminds me of Go...

Constant "expression changed after it was checked" errors because the data model change tracking is fundamentally broken

Repeated refactoring of HTML form interop and it still kinda sucks

Major breaking changes on nearly every upgrade that take days to do, even on our small apps.

Crappy documention. There's no usage examples for most of the library, just the Angular version of Javadoc.

Terrible bike shedding by Angular and Material teams. I'm following a bunch of issues and I've never seen one closed. I've been following some of the threads for years.

That was a nasty rant but I have plenty of things to hate about Angular. React on the other hand has a mostly clean core API and doesn't force all this baggage on you. IMO this has spawned a competitive ecosystem where the bad ideas get shaken out. Angular is stuck in the past and feels creaky compared to React development these days.

JSX is the future. It's exactly how MVC frameworks used to work, and it would be popular for templating even if the rest of React didn't exist. Change tracking with props is another. It's simple, it works. Angular change tracking errors are the segfaults of front end dev

[eitland]

>Constant "expression changed after it was checked" errors because the data model change tracking is fundamentally broken

Sounds like are doing something wrong. At least I can't remember that particular one from three years of Angular >=2

> Repeated refactoring of HTML form interop and it still kinda sucks Major breaking changes on nearly every upgrade that take days to do, even on our small apps.

I did most of upgrades for over a year I think. They were mostly trivial after reading up on the changes and I don't consider myself a 10x engineer. Pro tip: Learn to use this repo: https://github.com/cexbrayat/angular-cli-diff

> Crappy documention. There's no usage examples for most of the library, just the Angular version of Javadoc.

Not perfect (internal inconsistentencies where one paragraph says "don't do this" and a couple of pages down they do exactly that).

But far far from Javafoc.

> Terrible bike shedding by Angular and Material teams. I'm following a bunch of issues and I've never seen one closed. I've been following some of the threads for years.

I don't like Material either ;-)

For everyone else:

Like always: keep it simple. Stick with the standards. Use a good ide/editor. Use Angular CLI, stick to the style suggested by that even though you don't have to use it for every small thing.

[adjkant]

https://2019.stateofjs.com/front-end-frameworks/#front_end_f...

Versus 2016: http://2016.stateofjs.com/2016/frontend/

Angular is 100% fading, albeit slowly. Seems like a lot of slow moving enterprise companies are still going with it anecdotally. I'd bet on very few new projects opting for it currently, and probably near zero within 2-3 years.

As to why, IMO Vue ate Angular's lunch. Single file components did everything angular's MVC wanted without all the failures like $scope and other things. React and Vue can coexist, but I think Vue and Angular are direct competition. Also see those developer surveys and the massive growth of popularity of Vue along with angular's fading.

[pjmlp]

That is AngularJS.

[dmoreno]

Not scientifically accurate, but Google trends gives a hint. And absolutely not dying, but react keeps growing at angular's expense.

https://trends.google.com/trends/explore?date=today%205-y&q=...

[darepublic]

Next.js is a very decent React based SSR framework imo, and not sure vue is more popular

[baddox]

Gatsby is another very popular SSR framework that uses React.

[iaml]

There's no reason to pick gatsby over next nowadays, next can do everything gatsby can and in a sane, reusable manner.

[andrewingram]

I agree in the broad sense, but this isn't entirely true.

Feature-wise, Next does seem like a superset of Gatsby, especially since it can support server, static and hybrid rendering models. Architecturally, Gatsby does have some advantages. They're not ones that are particularly important to me, but I don't think it's fair to ignore them:

- The plugin model is more sophisticated, and there's a huge ecosystem of them which can solve most common use cases.

- The ability to use a unified data graph means page invalidation and rebuilds upon data changes can be done automatically at a very granular level -- because it's possible to keep track of which pages would be affected by every piece of data.

I'd add that I have issues with both, which leads me more to Next.js because it has a lower level of vendor lock-in compared to Gatsby. Anecdotally, migrating a small site from Gatsby to Next.js replaced 150 Gatsby-related imports with 10 Next.js ones.

[eivarv]

Gatsby's a static site generator, isn't it? That's different from SSR.

[floydnoel]

there’s an SSR plugin for Gatsby. also, Next has the option to do SSG.

[rk06]

parent is talking about servr side frameworks like laravel, django, asp.net core mvc etc. Not node.js SSR framework

For those, it is much more easier to add vue as a script tag. also easier to setup Vue, compared to react.

[azangru]

> Lags behind in server side frameworks adoption

What do you mean by this? Which server-side frameworks? Are you comparing Next and Nuxt?

[danfo]

(not GP) with React, declarative JavaScript code can result in HTML. JS -> HTML

Server side frameworks (the usual favourites) have existing ways for code to result in HTML. Ruby/PHP/Java -> HTML

Vue on the other hand can sit within HTML. So you can sprinkle in client-side logic in the views while still generally going with the grain of your server side framework.

https://gitlab.com/gitlab-org/gitlab/-/blob/6cece3f49eb87779...

See `if can?(current_user, :admin_issue, @project)` (Ruby) and `"v-if" => "issue.labels.length === 0"` (Vue)

[debaserab2]

Does the v-if execute on the server side?

[pjmlp]

Where?

Over here it is all about Angular and Vue, and this for a minority of projects.

The large majority is done on SSR, CMS based infrastructure with vanilaJS.

[andrewingram]

We definitely seem to be in an era of stability. My stack of choice (React, GraphQL, Relay, Django) has remained unchanged since late 2015. A few things have changed, i.e. I no longer have to hand-roll my own SSR solution, because things like Next.js exist. But what represents the bulk of my code is largely the same tech as it was 5 years ago.

[dane-pgp]

> the biggest challenge in the JavaScript community was how fast everything moved

If you don't like things moving too fast, then React does seem to be the ideal ecosystem:

https://github.com/facebook/create-react-app/issues/9033#iss...

TL;DR A vulnerability was discovered in a transitive dependency of "create-react-app" and announced back in March, but the one line patch to update the hard-coded reference to the vulnerable version is being held back for a future major version upgrade of the "create-react-app" package. 5 months on and the issue is marked as Closed but the new version hasn't been released.

[danabramov]

To be clear, the vulnerability has no actual effect on CRA apps. The description says it’s for a DDOS attack which is completely irrelevant because CRA doesn’t use WDS for production environments. (It doesn’t even have a production web server.)

While I agree that ideally a release should be cut to satisfy people affected by enterprise requirements, we are looking at a case of an overzealous audit checker, not an actual vulnerability that affects your apps.

(Edit: I've cut a release though; see my response in https://github.com/facebook/create-react-app/issues/9033#iss...)

[dane-pgp]

Thank you for your professionalism and humility. I too would like to apologise for not giving the full context and incorrectly suggesting that the vulnerability might actually affect apps created by CRA.

I think that the real concern was not the non-existent security implications (although it's a bad habit to ignore even an overzealous audit checker), but that the release process for CRA seemed to make it very hard to cut new patch releases. Your comment suggests that it wasn't so hard after all, for which I am relieved and grateful, but the policy of expecting people to wait for (and deal with the backwards incompatibility of) major version updates[0] doesn't feel like an industry best practice.

[0] https://github.com/facebook/create-react-app/issues/9033#iss...

[danabramov]

I think there are definitely things that could be improved in the release process there. The project is mostly run by volunteer contributors as there are limited things we can focus on, and currently we're very focused on React itself. If someone were to volunteer to streamline the release process and improve it, I'm sure the maintainers would have been appreciative.