5 ms·

It's not just Angular. To me it feels like everything in the JS world releases way faster than it's reasonable to keep up with these days.

tptacek 9y ago
People say this a lot. But the React you write in 2017 is pretty close to the React you'd have written the year the framework was released.
- themihai 9y ago
  Give it one more year....
  - rpastuszak 9y ago
    Why?
- Retozi 9y ago
  I agree. I exlusively write React Frontends since 2014, and very minor things have changed. It feels a lot more stable than before, where every project had homegrown framework stuff on top of backbone.js or jquery, or then using ember.js. There was just an awful lot of difficult discussion on how to design event-bus abstractions, global state management and general architecture To me it feels like the frontend ecosystem has stabilized a lot, since the react paradigm is very robust and versatile. For most difficult problems, the solution is somewhat clear. Sometimes more, sometimes less elegant, but at least the timeconsuming disussions have become less frequent within a team
- kevan 9y ago
  Most of my pain with the React ecosystem happened when people kept rebuilding react-router every 6 months. I managed one upgrade, but after that we gave up and stuck with the old version because it worked well for our purposes.
  - tptacek 9y ago
    Certainly, the React ecosystem is full of stuff that changes gratuitously --- but my feeling is the rate of change on that stuff is usually inversely proportional to its utility. For instance: I'm not entirely sure why anyone uses an add-on router library.
    - throwanem 9y ago
      ...instead of hand-rolling as per e.g. https://medium.freecodecamp.org/you-might-not-need-react-router-38673620f3d https://medium.freecodecamp.org/you-might-not-need-react-rou... ? Asking because I'm just getting into React, and not really clear on best practice yet. You seem to know a thing and have an opinion; will you share them?
      - tptacek 9y ago
        Yes. There's a continuum of routing needs in React apps. If you're not strictly an SPA, you don't need it at all; the browser already does it for you. For a lot of straightforward SPAs, the most basic "display this component based on current tab" works. Past that, a "real router" is just a small piece of code that looks at window.location to decide which component to render, and a Link that knows how to use the history API. I don't understand why people bloody their foreheads on react-router. The thing it is doing is simple enough to re-do by hand in any application. You see the same thing with flux implementations: flux libraries change rapidly, because there's not that much to the underlying concept and it's easy to mess with them. But most apps probably don't need flux at all.
      - PKop 9y ago
        Checkout Next.js (React based framework) if you want to worry the least about routing, and just default to a route per page model. Next also makes it easy to do server rendering and/or pre-rendering of routes.
        tptacek 9y ago
        You can do this, but routes-per-page with parameters and working back/forward buttons with no serious deps is literally something like 15 lines of code. I think more people should just hack their own router together before introducing a dep for it.
- ferdbold 9y ago
  I don't agree. react-router has changed enough in the last 2 years to throw me off quite a bit when I started a new project
  - vosper 9y ago
    React and react-router are not the same thing at all. They're developed by different teams at different organisations. It's not fair to compare the two.
    - stickfigure 9y ago
      But we're comparing against Angular, which has a router and the rest of the kitchen sink. If your React app is anything more than a toy, it will almost certainly require most of that sink and you'll suffer the version churn of a thousand ambiguously maintained components. --React developer
      - tptacek 9y ago
        This is just not true, and is I think a pretty harmful cargo-cult idea. People think "industrial strength React" means react-router and redux, even though neither of those deps are required for serious production applications. As I said upthread, there's a spectrum of routing needs for applications. There are ways to use React (for real) where the server handles routing, because you're not running the whole app as a single page (but still want easy, clean dynamic behavior from React). There are serious applications that are single-page, but don't use a formal router because their application doesn't decompose into "routes". And there are applications --- not enough of them, if you ask me --- that just write their own routers, because 98% of what you need for a router can be accomplished in ~20 lines of code. It's a similar story with Flux and Redux. Dan Abramov has been trying to convince people for years to start with just props and state and resist the urge to introduce a Redux dep before it's actually needed. He's not saying that to ease the learning curve. He's saying it because a lot of those apps will never need or benefit from Redux. For a lot of applications, Redux isn't worth the trouble. Moreover, just like with routers, the Flux pattern started with an idea about how to structure code, and morphed into a library dep. But Flux isn't about libraries! It's about code structure. It is not only possible but probably easier to structure your data in a Flux pattern without introducing Redux. The original Flux "library" was just EventEmitter. It is in fact not fair to compare the API turnover for Angular to vanilla React plus two optional ecosystem components that aren't actually part of React. But more importantly, it's time to stop giving developers the impression they aren't building a "real application" if they don't have an extremely complicated router library and a whole bunch of thunks and reducers.
- sametmax 9y ago
  But the build stack you use to compile your code did change. And the store ecosystem.
Raphmedia 9y ago
Angular, React, etc. are nothing but a bunch of pre-written lines of code that does data binding. Quality lines of codes with a lot of candies, but in the end it's only a bunch of JS lines. There are no obligations whatsoever to keep your project cutting edge and even less of reason to migrate to a more popular framework. It's not as if browser support for Angular 1 would stop.
- ferdbold 9y ago
  True, but it's nice to be able to use the newer features of your framework as they come out. Positive QoL changes in an API are always welcome
  - Raphmedia 9y ago
    It is, but you have to balance it out. Updating an entire app to a new major version (without backward compatibility) simply to use let's say a new API wrapper or syntactic sugar is a waste of time. If the app works fine, there's no need to migrate.
baristaGeek 9y ago
Which is why we'll all be compiling from Elm to JS in the near future. Or at least I hope so...

tptacek 9y ago

People say this a lot. But the React you write in 2017 is pretty close to the React you'd have written the year the framework was released.

themihai 9y ago
Give it one more year....
- rpastuszak 9y ago
  Why?
Retozi 9y ago
I agree. I exlusively write React Frontends since 2014, and very minor things have changed. It feels a lot more stable than before, where every project had homegrown framework stuff on top of backbone.js or jquery, or then using ember.js. There was just an awful lot of difficult discussion on how to design event-bus abstractions, global state management and general architecture To me it feels like the frontend ecosystem has stabilized a lot, since the react paradigm is very robust and versatile. For most difficult problems, the solution is somewhat clear. Sometimes more, sometimes less elegant, but at least the timeconsuming disussions have become less frequent within a team
kevan 9y ago
Most of my pain with the React ecosystem happened when people kept rebuilding react-router every 6 months. I managed one upgrade, but after that we gave up and stuck with the old version because it worked well for our purposes.
- tptacek 9y ago
  Certainly, the React ecosystem is full of stuff that changes gratuitously --- but my feeling is the rate of change on that stuff is usually inversely proportional to its utility. For instance: I'm not entirely sure why anyone uses an add-on router library.
  - throwanem 9y ago
    ...instead of hand-rolling as per e.g. https://medium.freecodecamp.org/you-might-not-need-react-router-38673620f3d https://medium.freecodecamp.org/you-might-not-need-react-rou... ? Asking because I'm just getting into React, and not really clear on best practice yet. You seem to know a thing and have an opinion; will you share them?
    - tptacek 9y ago
      Yes. There's a continuum of routing needs in React apps. If you're not strictly an SPA, you don't need it at all; the browser already does it for you. For a lot of straightforward SPAs, the most basic "display this component based on current tab" works. Past that, a "real router" is just a small piece of code that looks at window.location to decide which component to render, and a Link that knows how to use the history API. I don't understand why people bloody their foreheads on react-router. The thing it is doing is simple enough to re-do by hand in any application. You see the same thing with flux implementations: flux libraries change rapidly, because there's not that much to the underlying concept and it's easy to mess with them. But most apps probably don't need flux at all.
    - PKop 9y ago
      Checkout Next.js (React based framework) if you want to worry the least about routing, and just default to a route per page model. Next also makes it easy to do server rendering and/or pre-rendering of routes.
      - tptacek 9y ago
        You can do this, but routes-per-page with parameters and working back/forward buttons with no serious deps is literally something like 15 lines of code. I think more people should just hack their own router together before introducing a dep for it.
ferdbold 9y ago
I don't agree. react-router has changed enough in the last 2 years to throw me off quite a bit when I started a new project
- vosper 9y ago
  React and react-router are not the same thing at all. They're developed by different teams at different organisations. It's not fair to compare the two.
  - stickfigure 9y ago
    But we're comparing against Angular, which has a router and the rest of the kitchen sink. If your React app is anything more than a toy, it will almost certainly require most of that sink and you'll suffer the version churn of a thousand ambiguously maintained components. --React developer
    - tptacek 9y ago
      This is just not true, and is I think a pretty harmful cargo-cult idea. People think "industrial strength React" means react-router and redux, even though neither of those deps are required for serious production applications. As I said upthread, there's a spectrum of routing needs for applications. There are ways to use React (for real) where the server handles routing, because you're not running the whole app as a single page (but still want easy, clean dynamic behavior from React). There are serious applications that are single-page, but don't use a formal router because their application doesn't decompose into "routes". And there are applications --- not enough of them, if you ask me --- that just write their own routers, because 98% of what you need for a router can be accomplished in ~20 lines of code. It's a similar story with Flux and Redux. Dan Abramov has been trying to convince people for years to start with just props and state and resist the urge to introduce a Redux dep before it's actually needed. He's not saying that to ease the learning curve. He's saying it because a lot of those apps will never need or benefit from Redux. For a lot of applications, Redux isn't worth the trouble. Moreover, just like with routers, the Flux pattern started with an idea about how to structure code, and morphed into a library dep. But Flux isn't about libraries! It's about code structure. It is not only possible but probably easier to structure your data in a Flux pattern without introducing Redux. The original Flux "library" was just EventEmitter. It is in fact not fair to compare the API turnover for Angular to vanilla React plus two optional ecosystem components that aren't actually part of React. But more importantly, it's time to stop giving developers the impression they aren't building a "real application" if they don't have an extremely complicated router library and a whole bunch of thunks and reducers.
sametmax 9y ago
But the build stack you use to compile your code did change. And the store ecosystem.

Raphmedia 9y ago

Angular, React, etc. are nothing but a bunch of pre-written lines of code that does data binding. Quality lines of codes with a lot of candies, but in the end it's only a bunch of JS lines. There are no obligations whatsoever to keep your project cutting edge and even less of reason to migrate to a more popular framework. It's not as if browser support for Angular 1 would stop.

ferdbold 9y ago
True, but it's nice to be able to use the newer features of your framework as they come out. Positive QoL changes in an API are always welcome
- Raphmedia 9y ago
  It is, but you have to balance it out. Updating an entire app to a new major version (without backward compatibility) simply to use let's say a new API wrapper or syntactic sugar is a waste of time. If the app works fine, there's no need to migrate.

baristaGeek 9y ago

Which is why we'll all be compiling from Elm to JS in the near future. Or at least I hope so...