14 ms·

The rise of React

220 points by prostoalex 6y ago

ht85 6y ago
Props to the people who have been managing the project. I have done a lot of React in the last 6 years and have never been frustrated with their decisions, which is very rare. I think beyond the technical aspects, the way React evolved over time was really on point. The roadmap has always been very well designed and the literature around new features and deprecated ones top notch. The way React is used has changed completely, but at no point did I feel upgrading was too costly and ended up stuck with an old version.
- AbenezerMamo 6y ago
  Is “props” a pun? If it is...I appreciate it * snap
  - ht85 6y ago
    Nah, I just wanted to state my appreciation.
    - Townley 6y ago
      Good to know; my uncertainty was mounting
      - mav3rick 6y ago
        Did it mount ?
        XCSme 6y ago
        We now only useEffect for this kind of events.
  - smnplk 6y ago
    This comment rendered me speechless.
    - julianeon 6y ago
      If you use hooks it's less verbose, you can just return speechless.
- ng12 6y ago
  > I have done a lot of React in the last 6 years and have never been frustrated with their decisions, which is very rare. Same, but this is also why I feel burnt by create-react-app. There's so many important features the team has simply decided it won't support. One of the biggest issues with the React ecosystem is that there's nothing in between training wheels (CRA) and a motorcycle (rolling your own config). Maybe there's an opportunity for a new project there.
  - lucassen 6y ago
    to be honest, Id say the next level abstractions(gatsby and next) fill that role. I can’t think of a SPA alternative though
  - hn_throwaway_99 6y ago
    I totally agree. If you need access to one config variable CRA doesn't support out of the box, your only option is to eject. I really wish there were the option of just providing an "overlay" file that only had your changes from the CRA defaults, rather than being forced to eject the whole config.
    - ht85 6y ago
      See sibling comments for solutions to do exactly that.
    - nawgszy 6y ago
      I think there's a couple repos that provide exactly that - a webpackOverrides.js file or something similar. I also think that next.js might have some of what the gp is interested in
    - ThePadawan 6y ago
      I can only second what ht85 said in a sibling comment. I have the same complaint, but this is definitely possible using e.g. react-app-rewired. Adding custom webpack loader rules is as simple as replacing the calls to react-scripts with calls to react-app-rewired and adding a .js file with your customizations.
- franciscop 6y ago
  I tried to start with React 5-6 years ago but got burned with WebPack complex config and scarce docs. Went back to it with Create React App 3-4 years ago and I'm in love, I don't ever want to go back to building complex apps with jQuery.
- zitterbewegung 6y ago
  I feel the same way about React. Out of all of the current choices I feel like React is not only mature but very useful. The only thing that really ever irked me is the weird LICENCE clause about patents but that was addressed.
- nickbauman 6y ago
  I prefer to use it as a rendering library only. That part is good. But much of the ecosystem is a mess. CRA, a fundamental piece, is a trainwreck. If you eject you can see how much focus on local simplicity has been implemented at the expense of global stability...
Swizec 6y ago
I think React’s biggest win is that it appeals to the programmers, not just the web developers. For the first time everything you need to make a website or webapp — html, css, etc – is just data. You have direct control, direct access, you can do what you want. There’s a beauty and simplicity in that. React is to web frontend what Lisp is to systems programming.
- toshk 6y ago
  The downside to that is that I've seen a lot of old school frontenders who 5-7 years ago were able to just dus html/css and sass haven't been able to keep up, it just got too complex. In that regard the old situation had better seperation of concerns.
  - Swizec 6y ago
    In my experience that separation of concerns was fake. 15+ years of webdev and I ain’t ever seen a redesign that doesn’t fundamentally change the layout and business logic. Never seen a spec update to logic that doesn’t also change how things look. The coupling is super tight and always has been.
    - toshk 6y ago
      I meant more in the sense that different people could do different jobs. Non-developers/designers were able to do a lot of the frontend stuff. With the "new" complexity of frontend development that's mostly gone. I've seen it a few times with my own eyes that in teams the 1-5 frontenders specialised in html/css had a really hard time switching to react, at the same time more seasoned developers felt like fish in the water. Considering the scarcity of developers that's actual a big deal, more work for developers while at the same time less work for traditional frontenders.
      - Swizec 6y ago
        In my experience those different people couldn’t do different jobs. Designers could write css, but I hd to set up magic id/class incantations for them. They could write html, but changes kept breaking business logic. Css zen gardens was a fantastic idea that I’ve never seen realized in a real project with business needs. Maybe I’ve just been unlucky.
deleted 6y ago
[deleted]
satya71 6y ago
The only reason I choose React today is the immense ecosystem around it. With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more.
- whycombagator 6y ago
  > With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more. Curious, does that apply to Angular/Ember?
  - Nextgrid 6y ago
    Agreed. As someone unfamiliar with the JS ecosystem I find React to be difficult because it appears just as a UI library. I have to then choose between dozens of competing options for everything (local state management, API calls, forms, URL routing, etc) where as frameworks such as Ember (not sure about Angular) seem to provide those features out of the box using a consistent API as well as some structure. I guess React is powerful in the sense that it will allow you to do this that wouldn't fit well with the structure and way of doing things of Ember/Angular, but that seems to be a relatively rare problem. In the majority of cases the structure and "batteries included" approach of Ember (and maybe Angular) would be beneficial. I see a similar problem with server-side Javascript. You can use Express for the HTTP side of things, but then you need to bolt on an ORM (from a dozen competing options), configure it, etc. There is no "batteries included" framework equivalent to Django, Rails or Laravel.
    - ng12 6y ago
      I hear this a lot and it's really missing the forest for the trees. Picking a routing library (if you need one) requires 10 minutes of googling. Picking Ember/Angular will haunt you for the lifetime of your project.
      - Nextgrid 6y ago
        Picking a routing library out of 10 competitors might mean that it becomes unmaintained (in favor of some other competitor) or will have bugs integrating with your other libraries. With a batteries-included framework, as long as the framework itself is maintained I can be fairly certain that parts of it just won't stop working as long as I follow the release notes when upgrading (there might be minor changes here and there, but nowhere near the amount of work of switching to a totally different library because the first one stops being maintained).
loosetypes 6y ago
I’ll see your Ling’s Cars[0], and raise you Camacho Auto[1] (requires flash). [0] https://m.lingscars.com/ https://m.lingscars.com/ [1] http://web.archive.org/web/20171205085043/https://www.camachoauto.com/ http://web.archive.org/web/20171205085043/https://www.camach...
cateye 6y ago
Wild conspiracy theory: Facebook, Dropbox, Netflix, Reddit made React popular so that web developers can't develop a competing service because of the complexity that it introduces.
- bluedevil2k 6y ago
  Or maybe there's genuinely good people working at Facebook who want to help others and help them succeed at their job.
pmlnr 6y ago
> What differentiates websites from one another today isn’t their underlying architecture but their content, design, and editorial. This is bad, this will kill the quirky, fun internet. Monoculture is not good.
- hombre_fatal 6y ago
  I don't get it unless you interpreted that statement inversely. It's the content, not the underlying architecture of a website, that makes in quirky and fun.
  - hoorayimhelping 6y ago
    React and the tools used to build React applications (mainly webpack) strongly incentivize engineers to create single page applications, but don't provide good routing and back-button support out of the box. To make a React SPA behave like a traditional web page, you need to add a third party routing library, and that has traditionally been a dumpster fire in React. That's a quick example of the way the React monoculture is bad for users of the web from a structural, not content point of view. I say this as someone who has been using React professionally for 5+ years, and who was initially incredibly excited about React's potential. I'm less convinced it's actually good, after seeing how it's used in day to day work with regular engineers working on regular software that isn't Facebook scale.
    - ulisesrmzroche 6y ago
      But then as soon you click the back button you lose all the state and have to do a lot of craziness to keep it in sync with the server. That’s the problem you’re trying to solve, trying to keep the server-client data reliably in sync. And no one wants to wait around for all that state to load, that’s why those websites were so slow. Plus, then there’s the challenge of scale and traffic It’s just not about the back button. It’s not about fashion, there are real problems that an SPA fixes. Sure it’s more complex, but the problem is more complex It looks like you and a lot of people in HN work on super small websites that don’t require React or any SPA but yall don’t have to shit all over it and people who choose an SPA to build their web apps. In fact, more often than not, it’s the right choice
marvindanig 6y ago
Agreed! The intent of React is to drive new developers away from the building blocks of the web. And it has definitely succeeded at that. The way its ecosystem has grown all over the place, I find very passionate developers that swear by it. But you never know, every technology at some point of time becomes a luddite’s take and then it’d become hard to even consider React. Someday may be near as well, given that it’s already more than 10 years old now… but then that would also be a good day for open web standards and simplicity. ;-)
- mcav 6y ago
  > The intent of React is to drive new developers away from the building blocks of the web. That’s not React’s intent.
  - marvindanig 6y ago
    not overtly, yes, but it is, you just don’t know it yet.
    - deleted 6y ago
      [deleted]
skrebbel 6y ago
Totally off topic, and very much a nitpick, but Ling's Cars isn't a used car dealership, it's a car leasing firm. I care because I'm a fan :-)
- tempodox 6y ago
  That site is entertainingly funny and the background paisley is just lovely. If anyone feels the need for a virus-free laugh, I recommend a visit: https://www.lingscars.com https://www.lingscars.com
bsaul 6y ago
sidenote : i find it funny nobody in the comments mentions vue.js. i find mentions of ember and angular, but i had the impression vue was the one that got all the love recently. Has something bad happened to this framework ?
- clivestaples 6y ago
  Not that I can tell. I recently stumbled upon Quasar/Vue and was very impressed. The ecosystem seems to be flourishing.
- manigandham 6y ago
  No, might just be the timing of this submission. Vue is doing great and is about to release version 3 which will be another big leap forward.
  - hajile 6y ago
    Vue 3 looks very much like they're just taking one more step closer to just being react, but made by a different company.
    - manigandham 6y ago
      How so? The functional paradigm of data -> view model -> events -> mutation is the same in every framework and state management library but there are lots of differences in other features. Vue has a lot that sets it apart.
Ozzie_osman 6y ago
As someone who has been in the industry for a dozen years, and been an engineer or managed engineers at companies of different sizes, I love React. Some benefits: 1- It has bridged a previously large gap between FE code and BE code, and hence, made it a lot easier for engineers who aren't FE-specialists to build frontend code. I've found that backend engineers are a lot more willing and able to write React code, since it just feels more like the type of software they're used to writing. 2- It has brought concepts like functional/declarative programming much more center-stage. Prior to React, most developers might get a taste of declarative programming if they used SQL, but not in their day-to-day. They might give something like Scala a try, and either join the cult or turn around and run away screaming. React made these concepts a lot more accessible.
- Ozzie_osman 6y ago
  I'd also add that if you don't like React, but haven't tried it in a few years, you should give it another shot. It's still not perfect, but recent additions like hooks have been able to cut out a lot of the pain points it used to have. Even just using React with Typescript makes it easier and more robust (vs the old PropType syntax.. And yes I know you can use both but for 90% of use cases you don't need to).
- cutler 6y ago
  Peter Hunt, one of the original creators of React, was heavily influenced by David Nolen from the Clojurescript community. So we have Clojure to thank for the return of declarative programming.
jaredcwhite 6y ago
This article was great…up until the very end when it failed to mention any alternatives to React that already exist. "Alpert, who helped chart React’s rise, doesn’t see an alternative emerging anytime soon." This is completely ridiculous. Vue, Svelte, LitElement / Web Components, to name but a few. Maddening to see this level of journalistic malpractice.
- couchcombinator 6y ago
  There are alternatives to React indeed, but those you mentioned are conceptually very different.
  - gutino 6y ago
    Vue has also JSX as optional for the template system. you can see react as a subset of Vue.
- bluedevil2k 6y ago
  "journalistic malpractice" - he's merely passing on the sentiment of the main subject of the piece.
- simplify 6y ago
  Is it really that maddening? This response feels much too political. There are things worth getting mad about, and then there are JavaScript frameworks.
  - hombre_fatal 6y ago
    Also, why does everything have to be so radicalized? "Journalistic malpractice"? It's hard to have earnest discourse in 2020 for this reason. People often push everything to the extreme immediately.
    - esperent 6y ago
      Pushing debate to extremes is as old as humanity. I don't see any evidence to suggest that it's gotten worse recently (certain countries recent political increase in extremism notwithstanding).
talkinghead 6y ago
increment looks super great just picked up a couple of copies of the mag thanks for sharing
Marazan 6y ago
I was a Flex developer. No JS framework felt anywhere close to the ease and power of Flex until I saw React. React is Flex done right. React is Flex but armed with the knowledge that two way data binding is the fucking devil.
- MaxBarraclough 6y ago
  > two way data binding is the fucking devil You mean in terms of performance, or something else?
  - The_Amp_Walrus 6y ago
    In terms of reasoning about your code, I expect.
  - Marazan 6y ago
    Reasoning about code. Creation of inscrutable bugs. Forcing to create convoluted hierarchy of data structures to work round the problems this convenient 'feature' created. The kicker for me is it is perfectly possible to use Flex in a one-way data binding manner. Just wish I'd worked that out 13 years ago!
    - MaxBarraclough 6y ago
      Ah, the 'spooky action at a distance' aspect. Doesn't much of that apply to data-binding in general though?
      - Marazan 6y ago
        I have found that the difference between one-way and two-way to be quite profound when it comes to the complexity of bugs produced. Race conditions become an almost permanent fixture with two-way and the 'chains of causality' are exponentially more complex in a two-way situation. One-way simplifies things in quite a profound way. I remeber when watching Dan Abromov's excellent Redux tutorial physically laughing and muttering "of course" as every single two-way bug I had ever worked on flashed before my eyes.
_hardwaregeek 6y ago
Meh, React is great for more reasons than modularity. One way data flow combined with automatic updating and rendering is really really nice. I just wrote a simple UI for a terminal and having to manually call a function to paint to the screen felt rather...quaint. We've had modular templates for years. It's only recently that we've had the ability to think of UI elements as functions that automatically get called when their arguments update. This article also doesn't delve into why Facebook supports React so much. Or why Twitter, Reddit and the rest are switching to React. The answer being that React lets developers make really smooth, really addictive websites. I wouldn't be surprised if there was some studies showing that any flash of unstyled content, i.e. a server render round trip, lowers conversions by x%. Therefore having a client side app is imperative if you care about having your users on your site. Multiply it by Facebook's revenue and paying the few million to fund a team of developers is a really good deal.
- ricardobeat 6y ago
  > One way data flow combined with automatic updating and rendering React did not bring that. Flux, released a few months later, brought the unidirectional data-flow to it; we were already building similar architectures using event buses, though with looser abstractions. The 'automatic rendering' is a bit deceptive. Unless you manually optimize it, React will simply re-render everything all the time which is the same as calling `App.render()` after every data change. > React lets developers make really smooth, really addictive websites As someone who has been doing it for a decade, I don't see an inch of a difference. Browsers got more capable, our tools got more sophisticated, but there is nothing really you couldn't do a decade ago. If anything, React leads to bloated and inefficient SPAs. > any flash of unstyled content, i.e. a server render round trip, lowers conversions by x%. Therefore having a client side app is imperative There is no 'round trip' for server render, it is the exact opposite - a client-side app will have no content to show in initial render until it boots in the client. Hence you need SSR + hydration to make it faster.
  - _hardwaregeek 6y ago
    Did Flux really bring one way data flow? Because that's a pretty essential part of React. Even if React adopted it later, it's a core part of React's appeal. Do you legitimately see no difference in websites from 2012 and 2020? I'm honestly baffled if that's true. Payments are a massive difference that I've noticed. Every decent ecommerce site these days uses quite a lot of slick tricks to make the purchase flow really easy. Whether it's autocomplete based on Google Maps address data or being able to do everything without any obvious page refreshes, payments are significantly slicker. React definitely facilitates this. > There is no 'round trip' for server render Uhh there is a round trip. You click on a link, the new page does a request, loads new HTML, new CSS and paints the new page. Sure, an SPA takes longer to load up front, but you can now ensure that everything past that point is seamless. On a site like Facebook where the initial load won't kill conversions (because people are already addicted), you can take a 500ms hit so that stuff like infinite scroll and seamless notifications keep people on the site.
pier25 6y ago
React made a lot of sense to escape Angular, Ember, Backbone and jQuery in 2013-2014, but then it took 4-5 years to become wildly popular [1]. I've never understood its popularity despite the fact that during those years there were already better options out there by any metric you can think of (except popularity and hype). - Inferno and Preact: similar API but so much faster and smaller. - Mithril: vdom based with components, faster than React and includes http client + router in 10kB gzipped. - Vue: faster and smaller and has official batteries (unlike react-router which is a third party) Etc. [1] https://npm-stat.com/charts.html?package=react&from=2013-05-30&to=2020-05-30 https://npm-stat.com/charts.html?package=react&from=2013-05-...
- cutler 6y ago
  One-way data binding is what made React successful. Angular took a long time playing catch-up and with Vue it was optional.
- srg0 6y ago
  Probably because none of those advantages of other solutions matter for small-to-medium scale business. It's about getting things done _fast_, not getting the fastest thing. And for that purpose, a popular tool is usually better (more people, more information, bigger ecosystem). As for the technical merits of the alternatives, they fail to manifest in most situations: "Faster" - any framework is fast enough for most of the common tasks; and even if a popular framework is not the fastest, it is not necessarily a bottleneck in the real life applications. "Smaller" - it is just "faster" download. Irrelevant in many usage scenarios. It might be important in some applications, but shaving milliseconds vs man-months is a tough sale. "Official batteries" - bundling of the dependencies is completely irrelevant from the business perspective. It's something that the developers are paid to figure out.
  - pier25 6y ago
    > but shaving milliseconds vs man-months is a tough sale It's not really one or the other. Both Preact and Inferno can be used with React libraries with a compat layer. > bundling of the dependencies is completely irrelevant from the business perspective. It's not irrelevant. Vue is used by major corps in China. > It's something that the developers are paid to figure out. Didn't you just argue that the advantage of React is that developers get "things done _fast_"? How come this is not an advantage in the case of Vue?
cutler 6y ago
Battery drain is a metric often left out of the equation when assessing front-end frameworks. Download size is usually given priority but why? Your poor phone now has to run all that code you so zealously zipped.
- XCSme 6y ago
  That's interesting, are you also suggesting that serving non-gzipped content might lead to less battery usage than serving gzipped content? There will be less data downloaded, but mull CPU time to unzip the files. Isn't network a lot more costly (battery-wise) than CPU?
  - cutler 6y ago
    Sorry, I was refering to the CPU requirements of just running SPA code regardless of unzipping.

220 points by prostoalex 6y ago

ht85 6y ago

Props to the people who have been managing the project. I have done a lot of React in the last 6 years and have never been frustrated with their decisions, which is very rare. I think beyond the technical aspects, the way React evolved over time was really on point. The roadmap has always been very well designed and the literature around new features and deprecated ones top notch. The way React is used has changed completely, but at no point did I feel upgrading was too costly and ended up stuck with an old version.

AbenezerMamo 6y ago
Is “props” a pun? If it is...I appreciate it * snap
- ht85 6y ago
  Nah, I just wanted to state my appreciation.
  - Townley 6y ago
    Good to know; my uncertainty was mounting
    - mav3rick 6y ago
      Did it mount ?
      - XCSme 6y ago
        We now only useEffect for this kind of events.
- smnplk 6y ago
  This comment rendered me speechless.
  - julianeon 6y ago
    If you use hooks it's less verbose, you can just return speechless.
ng12 6y ago
> I have done a lot of React in the last 6 years and have never been frustrated with their decisions, which is very rare. Same, but this is also why I feel burnt by create-react-app. There's so many important features the team has simply decided it won't support. One of the biggest issues with the React ecosystem is that there's nothing in between training wheels (CRA) and a motorcycle (rolling your own config). Maybe there's an opportunity for a new project there.
- lucassen 6y ago
  to be honest, Id say the next level abstractions(gatsby and next) fill that role. I can’t think of a SPA alternative though
- hn_throwaway_99 6y ago
  I totally agree. If you need access to one config variable CRA doesn't support out of the box, your only option is to eject. I really wish there were the option of just providing an "overlay" file that only had your changes from the CRA defaults, rather than being forced to eject the whole config.
  - ht85 6y ago
    See sibling comments for solutions to do exactly that.
  - nawgszy 6y ago
    I think there's a couple repos that provide exactly that - a webpackOverrides.js file or something similar. I also think that next.js might have some of what the gp is interested in
  - ThePadawan 6y ago
    I can only second what ht85 said in a sibling comment. I have the same complaint, but this is definitely possible using e.g. react-app-rewired. Adding custom webpack loader rules is as simple as replacing the calls to react-scripts with calls to react-app-rewired and adding a .js file with your customizations.
franciscop 6y ago
I tried to start with React 5-6 years ago but got burned with WebPack complex config and scarce docs. Went back to it with Create React App 3-4 years ago and I'm in love, I don't ever want to go back to building complex apps with jQuery.
zitterbewegung 6y ago
I feel the same way about React. Out of all of the current choices I feel like React is not only mature but very useful. The only thing that really ever irked me is the weird LICENCE clause about patents but that was addressed.
nickbauman 6y ago
I prefer to use it as a rendering library only. That part is good. But much of the ecosystem is a mess. CRA, a fundamental piece, is a trainwreck. If you eject you can see how much focus on local simplicity has been implemented at the expense of global stability...

Swizec 6y ago

I think React’s biggest win is that it appeals to the programmers, not just the web developers. For the first time everything you need to make a website or webapp — html, css, etc – is just data. You have direct control, direct access, you can do what you want. There’s a beauty and simplicity in that. React is to web frontend what Lisp is to systems programming.

toshk 6y ago
The downside to that is that I've seen a lot of old school frontenders who 5-7 years ago were able to just dus html/css and sass haven't been able to keep up, it just got too complex. In that regard the old situation had better seperation of concerns.
- Swizec 6y ago
  In my experience that separation of concerns was fake. 15+ years of webdev and I ain’t ever seen a redesign that doesn’t fundamentally change the layout and business logic. Never seen a spec update to logic that doesn’t also change how things look. The coupling is super tight and always has been.
  - toshk 6y ago
    I meant more in the sense that different people could do different jobs. Non-developers/designers were able to do a lot of the frontend stuff. With the "new" complexity of frontend development that's mostly gone. I've seen it a few times with my own eyes that in teams the 1-5 frontenders specialised in html/css had a really hard time switching to react, at the same time more seasoned developers felt like fish in the water. Considering the scarcity of developers that's actual a big deal, more work for developers while at the same time less work for traditional frontenders.
    - Swizec 6y ago
      In my experience those different people couldn’t do different jobs. Designers could write css, but I hd to set up magic id/class incantations for them. They could write html, but changes kept breaking business logic. Css zen gardens was a fantastic idea that I’ve never seen realized in a real project with business needs. Maybe I’ve just been unlucky.

deleted 6y ago

[deleted]

satya71 6y ago

The only reason I choose React today is the immense ecosystem around it. With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more.

whycombagator 6y ago
> With every other framework, even though the core framework is capable enough, it feels like I have to reinvent wheels, axles, and more. Curious, does that apply to Angular/Ember?
- Nextgrid 6y ago
  Agreed. As someone unfamiliar with the JS ecosystem I find React to be difficult because it appears just as a UI library. I have to then choose between dozens of competing options for everything (local state management, API calls, forms, URL routing, etc) where as frameworks such as Ember (not sure about Angular) seem to provide those features out of the box using a consistent API as well as some structure. I guess React is powerful in the sense that it will allow you to do this that wouldn't fit well with the structure and way of doing things of Ember/Angular, but that seems to be a relatively rare problem. In the majority of cases the structure and "batteries included" approach of Ember (and maybe Angular) would be beneficial. I see a similar problem with server-side Javascript. You can use Express for the HTTP side of things, but then you need to bolt on an ORM (from a dozen competing options), configure it, etc. There is no "batteries included" framework equivalent to Django, Rails or Laravel.
  - ng12 6y ago
    I hear this a lot and it's really missing the forest for the trees. Picking a routing library (if you need one) requires 10 minutes of googling. Picking Ember/Angular will haunt you for the lifetime of your project.
    - Nextgrid 6y ago
      Picking a routing library out of 10 competitors might mean that it becomes unmaintained (in favor of some other competitor) or will have bugs integrating with your other libraries. With a batteries-included framework, as long as the framework itself is maintained I can be fairly certain that parts of it just won't stop working as long as I follow the release notes when upgrading (there might be minor changes here and there, but nowhere near the amount of work of switching to a totally different library because the first one stops being maintained).

loosetypes 6y ago

I’ll see your Ling’s Cars[0], and raise you Camacho Auto[1] (requires flash). [0] https://m.lingscars.com/ https://m.lingscars.com/ [1] http://web.archive.org/web/20171205085043/https://www.camachoauto.com/ http://web.archive.org/web/20171205085043/https://www.camach...

cateye 6y ago

Wild conspiracy theory: Facebook, Dropbox, Netflix, Reddit made React popular so that web developers can't develop a competing service because of the complexity that it introduces.

bluedevil2k 6y ago
Or maybe there's genuinely good people working at Facebook who want to help others and help them succeed at their job.

pmlnr 6y ago

> What differentiates websites from one another today isn’t their underlying architecture but their content, design, and editorial. This is bad, this will kill the quirky, fun internet. Monoculture is not good.

hombre_fatal 6y ago
I don't get it unless you interpreted that statement inversely. It's the content, not the underlying architecture of a website, that makes in quirky and fun.
- hoorayimhelping 6y ago
  React and the tools used to build React applications (mainly webpack) strongly incentivize engineers to create single page applications, but don't provide good routing and back-button support out of the box. To make a React SPA behave like a traditional web page, you need to add a third party routing library, and that has traditionally been a dumpster fire in React. That's a quick example of the way the React monoculture is bad for users of the web from a structural, not content point of view. I say this as someone who has been using React professionally for 5+ years, and who was initially incredibly excited about React's potential. I'm less convinced it's actually good, after seeing how it's used in day to day work with regular engineers working on regular software that isn't Facebook scale.
  - ulisesrmzroche 6y ago
    But then as soon you click the back button you lose all the state and have to do a lot of craziness to keep it in sync with the server. That’s the problem you’re trying to solve, trying to keep the server-client data reliably in sync. And no one wants to wait around for all that state to load, that’s why those websites were so slow. Plus, then there’s the challenge of scale and traffic It’s just not about the back button. It’s not about fashion, there are real problems that an SPA fixes. Sure it’s more complex, but the problem is more complex It looks like you and a lot of people in HN work on super small websites that don’t require React or any SPA but yall don’t have to shit all over it and people who choose an SPA to build their web apps. In fact, more often than not, it’s the right choice

marvindanig 6y ago

Agreed! The intent of React is to drive new developers away from the building blocks of the web. And it has definitely succeeded at that. The way its ecosystem has grown all over the place, I find very passionate developers that swear by it. But you never know, every technology at some point of time becomes a luddite’s take and then it’d become hard to even consider React. Someday may be near as well, given that it’s already more than 10 years old now… but then that would also be a good day for open web standards and simplicity. ;-)

mcav 6y ago
> The intent of React is to drive new developers away from the building blocks of the web. That’s not React’s intent.
- marvindanig 6y ago
  not overtly, yes, but it is, you just don’t know it yet.
  - deleted 6y ago
    [deleted]

skrebbel 6y ago

Totally off topic, and very much a nitpick, but Ling's Cars isn't a used car dealership, it's a car leasing firm. I care because I'm a fan :-)

tempodox 6y ago
That site is entertainingly funny and the background paisley is just lovely. If anyone feels the need for a virus-free laugh, I recommend a visit: https://www.lingscars.com https://www.lingscars.com

bsaul 6y ago

sidenote : i find it funny nobody in the comments mentions vue.js. i find mentions of ember and angular, but i had the impression vue was the one that got all the love recently. Has something bad happened to this framework ?

clivestaples 6y ago
Not that I can tell. I recently stumbled upon Quasar/Vue and was very impressed. The ecosystem seems to be flourishing.
manigandham 6y ago
No, might just be the timing of this submission. Vue is doing great and is about to release version 3 which will be another big leap forward.
- hajile 6y ago
  Vue 3 looks very much like they're just taking one more step closer to just being react, but made by a different company.
  - manigandham 6y ago
    How so? The functional paradigm of data -> view model -> events -> mutation is the same in every framework and state management library but there are lots of differences in other features. Vue has a lot that sets it apart.

Ozzie_osman 6y ago

As someone who has been in the industry for a dozen years, and been an engineer or managed engineers at companies of different sizes, I love React. Some benefits: 1- It has bridged a previously large gap between FE code and BE code, and hence, made it a lot easier for engineers who aren't FE-specialists to build frontend code. I've found that backend engineers are a lot more willing and able to write React code, since it just feels more like the type of software they're used to writing. 2- It has brought concepts like functional/declarative programming much more center-stage. Prior to React, most developers might get a taste of declarative programming if they used SQL, but not in their day-to-day. They might give something like Scala a try, and either join the cult or turn around and run away screaming. React made these concepts a lot more accessible.

Ozzie_osman 6y ago
I'd also add that if you don't like React, but haven't tried it in a few years, you should give it another shot. It's still not perfect, but recent additions like hooks have been able to cut out a lot of the pain points it used to have. Even just using React with Typescript makes it easier and more robust (vs the old PropType syntax.. And yes I know you can use both but for 90% of use cases you don't need to).
cutler 6y ago
Peter Hunt, one of the original creators of React, was heavily influenced by David Nolen from the Clojurescript community. So we have Clojure to thank for the return of declarative programming.

jaredcwhite 6y ago

This article was great…up until the very end when it failed to mention any alternatives to React that already exist. "Alpert, who helped chart React’s rise, doesn’t see an alternative emerging anytime soon." This is completely ridiculous. Vue, Svelte, LitElement / Web Components, to name but a few. Maddening to see this level of journalistic malpractice.

couchcombinator 6y ago
There are alternatives to React indeed, but those you mentioned are conceptually very different.
- gutino 6y ago
  Vue has also JSX as optional for the template system. you can see react as a subset of Vue.
bluedevil2k 6y ago
"journalistic malpractice" - he's merely passing on the sentiment of the main subject of the piece.
simplify 6y ago
Is it really that maddening? This response feels much too political. There are things worth getting mad about, and then there are JavaScript frameworks.
- hombre_fatal 6y ago
  Also, why does everything have to be so radicalized? "Journalistic malpractice"? It's hard to have earnest discourse in 2020 for this reason. People often push everything to the extreme immediately.
  - esperent 6y ago
    Pushing debate to extremes is as old as humanity. I don't see any evidence to suggest that it's gotten worse recently (certain countries recent political increase in extremism notwithstanding).

talkinghead 6y ago

increment looks super great just picked up a couple of copies of the mag thanks for sharing

Marazan 6y ago

I was a Flex developer. No JS framework felt anywhere close to the ease and power of Flex until I saw React. React is Flex done right. React is Flex but armed with the knowledge that two way data binding is the fucking devil.

MaxBarraclough 6y ago
> two way data binding is the fucking devil You mean in terms of performance, or something else?
- The_Amp_Walrus 6y ago
  In terms of reasoning about your code, I expect.
- Marazan 6y ago
  Reasoning about code. Creation of inscrutable bugs. Forcing to create convoluted hierarchy of data structures to work round the problems this convenient 'feature' created. The kicker for me is it is perfectly possible to use Flex in a one-way data binding manner. Just wish I'd worked that out 13 years ago!
  - MaxBarraclough 6y ago
    Ah, the 'spooky action at a distance' aspect. Doesn't much of that apply to data-binding in general though?
    - Marazan 6y ago
      I have found that the difference between one-way and two-way to be quite profound when it comes to the complexity of bugs produced. Race conditions become an almost permanent fixture with two-way and the 'chains of causality' are exponentially more complex in a two-way situation. One-way simplifies things in quite a profound way. I remeber when watching Dan Abromov's excellent Redux tutorial physically laughing and muttering "of course" as every single two-way bug I had ever worked on flashed before my eyes.

_hardwaregeek 6y ago

Meh, React is great for more reasons than modularity. One way data flow combined with automatic updating and rendering is really really nice. I just wrote a simple UI for a terminal and having to manually call a function to paint to the screen felt rather...quaint. We've had modular templates for years. It's only recently that we've had the ability to think of UI elements as functions that automatically get called when their arguments update. This article also doesn't delve into why Facebook supports React so much. Or why Twitter, Reddit and the rest are switching to React. The answer being that React lets developers make really smooth, really addictive websites. I wouldn't be surprised if there was some studies showing that any flash of unstyled content, i.e. a server render round trip, lowers conversions by x%. Therefore having a client side app is imperative if you care about having your users on your site. Multiply it by Facebook's revenue and paying the few million to fund a team of developers is a really good deal.

ricardobeat 6y ago
> One way data flow combined with automatic updating and rendering React did not bring that. Flux, released a few months later, brought the unidirectional data-flow to it; we were already building similar architectures using event buses, though with looser abstractions. The 'automatic rendering' is a bit deceptive. Unless you manually optimize it, React will simply re-render everything all the time which is the same as calling `App.render()` after every data change. > React lets developers make really smooth, really addictive websites As someone who has been doing it for a decade, I don't see an inch of a difference. Browsers got more capable, our tools got more sophisticated, but there is nothing really you couldn't do a decade ago. If anything, React leads to bloated and inefficient SPAs. > any flash of unstyled content, i.e. a server render round trip, lowers conversions by x%. Therefore having a client side app is imperative There is no 'round trip' for server render, it is the exact opposite - a client-side app will have no content to show in initial render until it boots in the client. Hence you need SSR + hydration to make it faster.
- _hardwaregeek 6y ago
  Did Flux really bring one way data flow? Because that's a pretty essential part of React. Even if React adopted it later, it's a core part of React's appeal. Do you legitimately see no difference in websites from 2012 and 2020? I'm honestly baffled if that's true. Payments are a massive difference that I've noticed. Every decent ecommerce site these days uses quite a lot of slick tricks to make the purchase flow really easy. Whether it's autocomplete based on Google Maps address data or being able to do everything without any obvious page refreshes, payments are significantly slicker. React definitely facilitates this. > There is no 'round trip' for server render Uhh there is a round trip. You click on a link, the new page does a request, loads new HTML, new CSS and paints the new page. Sure, an SPA takes longer to load up front, but you can now ensure that everything past that point is seamless. On a site like Facebook where the initial load won't kill conversions (because people are already addicted), you can take a 500ms hit so that stuff like infinite scroll and seamless notifications keep people on the site.

pier25 6y ago

React made a lot of sense to escape Angular, Ember, Backbone and jQuery in 2013-2014, but then it took 4-5 years to become wildly popular [1]. I've never understood its popularity despite the fact that during those years there were already better options out there by any metric you can think of (except popularity and hype). - Inferno and Preact: similar API but so much faster and smaller. - Mithril: vdom based with components, faster than React and includes http client + router in 10kB gzipped. - Vue: faster and smaller and has official batteries (unlike react-router which is a third party) Etc. [1] https://npm-stat.com/charts.html?package=react&from=2013-05-30&to=2020-05-30 https://npm-stat.com/charts.html?package=react&from=2013-05-...

cutler 6y ago
One-way data binding is what made React successful. Angular took a long time playing catch-up and with Vue it was optional.
srg0 6y ago
Probably because none of those advantages of other solutions matter for small-to-medium scale business. It's about getting things done _fast_, not getting the fastest thing. And for that purpose, a popular tool is usually better (more people, more information, bigger ecosystem). As for the technical merits of the alternatives, they fail to manifest in most situations: "Faster" - any framework is fast enough for most of the common tasks; and even if a popular framework is not the fastest, it is not necessarily a bottleneck in the real life applications. "Smaller" - it is just "faster" download. Irrelevant in many usage scenarios. It might be important in some applications, but shaving milliseconds vs man-months is a tough sale. "Official batteries" - bundling of the dependencies is completely irrelevant from the business perspective. It's something that the developers are paid to figure out.
- pier25 6y ago
  > but shaving milliseconds vs man-months is a tough sale It's not really one or the other. Both Preact and Inferno can be used with React libraries with a compat layer. > bundling of the dependencies is completely irrelevant from the business perspective. It's not irrelevant. Vue is used by major corps in China. > It's something that the developers are paid to figure out. Didn't you just argue that the advantage of React is that developers get "things done _fast_"? How come this is not an advantage in the case of Vue?

cutler 6y ago

Battery drain is a metric often left out of the equation when assessing front-end frameworks. Download size is usually given priority but why? Your poor phone now has to run all that code you so zealously zipped.

XCSme 6y ago
That's interesting, are you also suggesting that serving non-gzipped content might lead to less battery usage than serving gzipped content? There will be less data downloaded, but mull CPU time to unzip the files. Isn't network a lot more costly (battery-wise) than CPU?
- cutler 6y ago
  Sorry, I was refering to the CPU requirements of just running SPA code regardless of unzipping.