10 ms·

I'm curious: Where do these anti-React (anti-spa?) people come from, technologically? Rails? Php? Some .Net stack? Do you think the web Peaked with Perl-based C

I'm curious: Where do these anti-React (anti-spa?) people come from, technologically? Rails? Php? Some .Net stack? Do you think the web Peaked with Perl-based CGI-scripts? I've been in this game for many years, and to me, any technology that speeds up development cycle time is an improvement. There's a reason React is so popular.

pweissbrod 10y ago
In the 2000s we used ASP.NET webform user controls and java struts in a VERY similar approach to what react calls a "component" which is great because concepts such as composition and event percolation come naturally and make a great amount of sense (to me). There were many developers who were raised to strive for segregating logic from display (keep your js away from your HTML) and that MVC was a universal solution to front-end development. From what I've seen angular does these things very well and feels more natural to teams where this mindset is well-established.
kuschku 10y ago
> any technology that speeds up development cycle time is an improvement. The problem is that for many, react does not do that – because you need npm, webpack, babel, systemjs, and so on and so on. We come from a world where you have a simple .gradle config file, and you press one command, and it installs and everything just works. No need to configure thousands of transpilers, no need to handle constantly breaking dependencies, because people keep their API stable for years, some even decades (see Bouncycastle, e.g.), etc. Coming from this style of development where tech actually works well, and is stable, to the JS world of React where everything constantly breaks, is very complicated and over enterprise-ified, etc is quite annoying. Obviously, on the other hand, the React world provides other massive advantages, such as quick iteration, innovation, etc – but the work to get something working with constant quality for years is entirely different. Because you’ll have to fork all your dependencies, because those won’t be stable. So if you want your product to be included in Debian Stable, you don’t want to use React. Because you’ll end up forking and maintaining every single of your dependencies-.
- treehau5 10y ago
  > The problem is that for many, react does not do that – because you need npm, webpack, babel, systemjs, and so on and so on. This couldn't be further from the truth. And besides, create-react-app solves that. > No need to configure thousands of transpilers, no need to handle constantly breaking dependencies, because people keep their API stable for years, some even decades I have been using react since early 2014, back when it was still very early pre-release. I have had to change exactly one thing w.r.t to the react API. When we decided to add in webpack, again, I had to change exactly one thing there as well -- I switched to a .babelrc file and they included the react transpiler by default.
  - kuschku 10y ago
    > And besides, create-react-app solves that. Until something breaks, and you have to go through all the configs and try to fix it. I’ve seen https://kukuruku.co/post/hello-real-world-in-php-in-2017/ https://kukuruku.co/post/hello-real-world-in-php-in-2017/ far too often.
    - treehau5 10y ago
      I think your comment is touching on two different points, in my view. > Until something breaks, and you have to go through all the configs and try to fix it. This is solved by understanding the language and the tools you are using. I see so many people screw up a react app because they don't know javascript. They take the same smorgasbord approach to languages and tools they have used in the past (like jQuery) and apply it to react. React is really a frontend framework for javascript developers, not a frontend framework for creative types (like Misko originally slated angular to be) If people would just take the time to learn the actual language they are using, it would make these other tools easier to grok. This is software development. It is suppose to be hard. Take the time to learn your tools. > I’ve seen https://kukuruku.co/post/hello-real-world-in-php-in-2017/ https://kukuruku.co/post/hello-real-world-in-php-in-2017/ far too often. I always wonder why people elect to use a heavy set of opinionated tools to solve simple problems. I understand the point the blog post is trying to make, but again, it's like taking a highly set of specialized tools and complaining when it is difficult to do the simple things, when all you needed was a hammer. React is a UI library first and foremost. You can take it, inject it into your page, and use it. You shouldn't add the bells and whistles until your complexity grows to the point where it makes sense to use it. I tell people to ask themselves this question all the time, "Are you sure you need flux?" Stop and ask that question. Can this be solved by just maintaining state on a top level component and passing down props? Do you need codesplitting and chunking and the advanced features of webpack? Or do you still operate in a traditional way where designers hand of their templates to coders to create the html and css and you are just tasked with writing the javascript? Then don't use webpack loaders. Use your coder's classnames on your components. This is people making things harder than they have to be. But again, all of this is really not that difficult if you take the time to fundamentally understand javascript.
BukhariH 10y ago
I'll be completely honest. I was anti-react when it initially (this is pre-create-react-app generator) came out and I'll tell you why. I tried to learn it and struggled understanding the new concepts react was bringing in all while people were saying "It's easy! Everything's a components. HTML,CSS,JS all in one place!" whilst I was struggling to get a simple hello world example to run. Just recently at my University we were forced to learn React as a part of our course and damn after I finally understood it I fell in love! It's a huge improvement over the normal web-app design work flow. So, I would urge anyone whose anti-react to honestly give it a good go and force yourself a little to get over the initial learning curve and trust me you'll love it!
- kraftman 10y ago
  Any tips for getting over the first hump?
  - jdironman 10y ago
    Be forced to learn it evidently.
  - Hnus 10y ago
    I could write a long list of things you should probably do but if I could recommend just one thing it would be to watch this video https://www.youtube.com/watch?v=xsKYAa1ZXpQ https://www.youtube.com/watch?v=xsKYAa1ZXpQ it really helped me to understand how react works.
  - supergreg 10y ago
    Think of it as a way to create your own complex HTML controls like the combobox/select. And just like those, try to give all information it needs to work via attributes or sub-elements.
- ergo14 10y ago
  If you like component approach, take a look at Polymer, I'm right now working with react, and while it is OK, I've found that web standards based approache to components is better. And web components can be used in react or other solutions nicely. Being "anti-react" doesn't mean anti-component approach. You can do same with angular 1.5+, vue, aurelia or others.
ergo14 10y ago
> Where do these anti-React (anti-spa?) people come from Are you implying that react-way is the only way of doing SPA-s? > Do you think the web Peaked with Perl-based CGI-scripts I think your comment is just rude. There are plenty of other options in the JS world - react is just one of them.
- YCode 10y ago
  > Are you implying that react-way is the only way of doing SPA-s? Pretty sure he's generalizing; i.e. "anti-banana? (anti-fruit?)"
  - ergo14 10y ago
    I'd expect someone who is "in this game for many years" to know better.
    - jakobloekke 10y ago
      It was meant as a polemic question, since the comments here seemed to be critical in a way that wasn't specific to next.js but more to the general space of spa's or even javascript. I see this a lot on HN, so I wanted to know if there were some constructive thoughts behind it. I sure didn't mean to be rude or anything! :)
rimliu 10y ago
The main reason that React is popular is because it is popular. I do not know where others come from, but I can tell where I come from: Web Standards Movement. There was such a thing some 15 years ago. People who cared about semantics, standards, accessibility. React is not bad. SPAs are not bad. That's bad is not having the understanding what should be SPA and what should not. Loading a couple of hundreds KB of scripts to show 1KB (ir you are lucky) of content is not OK. Alas, if you think that static (horror) or server-side generated (shock, horror) pages still have a place you will be brushed aside as someone who thinks that web peaked with Perl-based CGI scripts. Alas, a lot of what happens in web space now looks like inventing new solutions to the invented problems.
scotty79 10y ago
I know one anti-spa guy and his argument is that's basically reimplementing poorly things that were well implemented in rails without any obvious bemefit.
thewarrior 10y ago
One data point : Their Hackernews clone based on their own SPA framework is much slower than the plain old HTML site.
- jjallen 10y ago
  I was wondering about this too, but doesn't it have to get the data from the original site? The total network download is also many times the original at 233KB versus 11KB for Hacker News.
  - Yaggo 10y ago
    Also, we don't know what kind of server resources they use vs. HN. The initial weight of SPA is typically much more than "plain html" site, but that's the price you pay for client-side functionality. Also, there exist more lightweight alternatives for React, e.g. Preact.
- deleted 10y ago
  [deleted]
- scottmf 10y ago
  It's a bad example and not representative as far as performance is concerned.
mattmanser 10y ago
Those are two separate questions really. React is another in a long line of Backbone, Angular, Durandal, etc. that ultimately just make stuff a lot more complicated for fairly trivial benefits. It dictates fairly complicated ways of doing simple things with long complicated tool chains that regularly break for obscure reasons that you can debug but ultimately it feels like you're simply wasting your life dealing with it. It's easy for juniors to make ridiculously complicated messes in them. They remind me of the good old days of RAD dev tools. "Oh so easy" they claimed. And if you're any good, you can enhance traditional web forms and add the same sort of functionality without all the overhead, or complexity. Perhaps I simply have the benefit of over a decade of front-end dev. As for SPAs, they still live firmly in the uncanny valley. They're poor versions of desktop apps, even desktop apps from the 1990s. Anyone claiming otherwise is simply delusional. Because of javascript and the DOM, they also tend to complexity, so that anything past a glorified to-do app becomes an absolute nightmare to code in. I use Trello, Asana, Toggl, SendWithUs, etc., etc. They're all, well, a bit shit. All of them have really annoying niggles, fields you click and then might auto-save but might not. Poor desktop interfaces because "mobile first". Tabbing that doesn't work properly. Data that gets out of sync. Or they're sllllooooowwwwwwwwwww. As for the reason React became so popular? This happened before with terrible frameworks. I may be a cynic, but it feels front end devs have got into some sort of mega-echo chamber where a new framework comes along and everyone jumps on to it because they don't want to seem out-of-date. The front-end world feels like it's in a strange kind of culture at the moment, a type of Emperor's New Clothes, where if you're not using The Latest Framework, you're obviously not worth employing. Not because it makes you get a product to market quicker. It's a new form of bike shedding.
- lobster_johnson 10y ago
  As someone who works a lot with React — and have previously worked with things like Rails and Backbone — I adamantly disagree that the benefits are trivial or that it's more complicated. The functional component architecture makes it considerably easier to create less buggy UIs with less messy codebases. You sound like you don't really know or understand React. Which is fine, but it doesn't put you in a good position to criticize it intelligently. React isn't popular because of any kind of echo chamber phenomenon. It's popular because of its design; it managed hit a particular very sweet spot combining the various principles of composition, modularity, functional purity and internally consistent state management. I do agree that web apps aren't as good as desktop apps. But that's not the fault of SPAs.
untog 10y ago
If you put development cycle time over user experience you're doing it wrong. Personally, I dislike that React is 100+KB file size, when Preact or Inferno can do 95% of what I want at with 3KB. (Yes, I know gzipping exists but it's still huge by comparison, and JS parse time is a real issue on underpowered mobile devices)
- jakobloekke 10y ago
  In my experience, user experience suffers when performance considerations play too big a part early in projects. Like when forcing a server rendering tech on frontend developers and designers.
Yaggo 10y ago
In my experience, many anti-spa people have seen too many poorly implemented single page apps (web fundamentals broken such as links and uris) and/or have out-of-date information that spa cannot properly support such things. Cannot blame them, althought the situation is better nowadays, it's still not uncommon to find a spa site where the said things are broken.
- chiefalchemist 10y ago
  I think you make a good point, even if indirectly. That is, the technology keeps changing but the products and experiences seem to remain subpar, frustrating, wonky, etc. Perhaps these technologies are progress from a pure technology POV, but if real end users were to judge what would they say? Are we drinking too much of our own Kool Aid? Still? Again?
  - nperez 10y ago
    I think the experiences are getting better. My first SPA projects were with Angular 1.x and for the whole duration that I was using it, I found that I could point out an Angular 1.x based site off of gut feeling / familiarity with certain pain points (hi Seamless). I feel like there was a huge reduction in bug-prone madness when React + the Flux pattern started gaining steam. We are still collectively working toward an end (reliable software in the browser) but it's impossible for me not to feel the difference in the past few years, as a dev and a user. SPAs are sort of a hack. The web was designed for documents that link to each other. Maybe they'll never be perfect until we reach some sort of impossible isomorphic framework utopia, but there is real progress being made
    - chiefalchemist 10y ago
      You might think that. As might I :) What I'm suggesting is you ask your mother, father, grandparents,other developers, the person working the counter at the cafe, etc. Listen closely. I'm not so sure there's massive support to believe UXs are improving noticably.
agmcleod 10y ago
Speeding up development cycle is not the only goal. Its not a good thing when it causes the user experience of the application to be worse. I think SPAs have come a long way in this regard, but it was definitely quite rocky for a while.
arunoda 10y ago
I'm one of the core-contributors of Next.js. We are not anit-React or anti-spa. And we are pretty closely work with JS stuff. But Next.js is inspired by the simplicity of PHP. ### Anti SPA The whole idea of Next.js is to build a SPA easily. But it's also server rendered by default.
Arcsech 10y ago
I'm not anti-SPA (and in fact, I think of the tools out there react is a pretty good one if you're going to do SPA), but I do think it's the wrong tool for a lot of jobs. If your site is mainly content-based, like a blog or a forum, why make it an SPA? I feel like React/Angular/Vue/etc apps are becoming "the way the web is done" when so many things would be simpler and more efficient as plain old web sites with server-rendered HTML. It's like everyone decided that because convertibles are cool, they should be used for everything, and are now spending a ton of effort hitching trailers to their convertibles when it would have been much simpler and more effective to just drive a boring minivan in the first place.
- NoGravitas 10y ago
  I very strongly agree with this. There are certainly web apps that can only reasonably be done mainly-client-side. I'd give Office 365 as a baseline example. But what drives me crazy is sites like Medium [0][1]. It's a shared blog site. To read a one sentence essay on Medium requires downloading over a megabyte of data. And their comment system is still inscrutably terrible. Content-focused sites should absolutely not be done as SPAs. Server rendered HTML and client-side enhancement will deliver a better experience to the customer and IMO a better developer experience as well. [0]: http://idlewords.com/talks/website_obesity.htm http://idlewords.com/talks/website_obesity.htm [1]: https://medium.com/@mceglowski/chickenshit-minimalism-846fc1412524#.7dgoctho7 https://medium.com/@mceglowski/chickenshit-minimalism-846fc1...
  - chrisrhoden 10y ago
    The page you link to on Medium renders after less than 100KB have been downloaded with an unprimed cache. Javascript is not required to read it. Javascript is used to provide extra functionality outside of the download / render cycle, to speed the experience of the page up, and to make future navigation faster. I understand where you are coming from, but you picked a bad example.
    - TeMPOraL 10y ago
      > Javascript is used to (...) speed the experience of the page up That is one thing I'm totally not buying. How does JavaScript speed anything up over simple staticly rendered text, (which is what Medium should be)?
silviogutierrez 10y ago
My biggest issue is that SPAs have a lot of overhead for your typical CRUD. The canonical example: a CRUD page with a dropdown of choices based on entitlement. Server rendered: in your template somewhere, {for choice in limited_choices} and so on. SPA: you need to coordinate a REST endpoint that has options for entitlement of just this dropdown, etc. You now need a route for REST, a route for the SPA page, and view code for both. Don't get me wrong, with unlimited time, build everything as REST services with a client that consumes it. But sometimes server-side rendering is just simpler.
- nojvek 10y ago
  SPA shines if you are building lots of CRUD. Rest end points are simpler and simply mush data out of the db. No templating crap. It's a lot faster to load template once and re-render on client with different data.
bandrami 10y ago
Do you think the web Peaked with Perl-based CGI-scripts? In some very important ways, yes. Specifically, it was still within the contraints of what HTTP and HTML were designed for: the transfer and rendering of marked up documents. Obviously all technology is x steps forward, y steps back, and you aim for some workable linear combination of x and y, but there have definitely been several regressions since the days of Perl-based CGI scripts, and I personally haven't found them worth the advances.
holtalanm 10y ago
I very much like SPA's. It is mostly React that I have a problem with. I don't trust their License Agreement when it states they can revoke your License for any reason. Basically, if I get on the wrong side of Facebook, they can pull my License for React without a warning. Unless they have amended their license since the last time I read it. In which case, I would like to see the updated version. Until then, I will continue to use InfernoJS.
underwater 10y ago
The React ecosystem's take on performance is really immature. Generally the server's job stops at isomorphic rendering which is a brute force and imperfect way of improving performance. Next.js and React Server are making steps towards solving this by bringing concepts like incremental loading and data hydration by default. I've talked about some of the approaches Facebook used to improve startup performance in the past: https://www.youtube.com/watch?v=b875VAC6r-w https://www.youtube.com/watch?v=b875VAC6r-w

pweissbrod 10y ago

In the 2000s we used ASP.NET webform user controls and java struts in a VERY similar approach to what react calls a "component" which is great because concepts such as composition and event percolation come naturally and make a great amount of sense (to me). There were many developers who were raised to strive for segregating logic from display (keep your js away from your HTML) and that MVC was a universal solution to front-end development. From what I've seen angular does these things very well and feels more natural to teams where this mindset is well-established.

kuschku 10y ago

> any technology that speeds up development cycle time is an improvement. The problem is that for many, react does not do that – because you need npm, webpack, babel, systemjs, and so on and so on. We come from a world where you have a simple .gradle config file, and you press one command, and it installs and everything just works. No need to configure thousands of transpilers, no need to handle constantly breaking dependencies, because people keep their API stable for years, some even decades (see Bouncycastle, e.g.), etc. Coming from this style of development where tech actually works well, and is stable, to the JS world of React where everything constantly breaks, is very complicated and over enterprise-ified, etc is quite annoying. Obviously, on the other hand, the React world provides other massive advantages, such as quick iteration, innovation, etc – but the work to get something working with constant quality for years is entirely different. Because you’ll have to fork all your dependencies, because those won’t be stable. So if you want your product to be included in Debian Stable, you don’t want to use React. Because you’ll end up forking and maintaining every single of your dependencies-.

treehau5 10y ago
> The problem is that for many, react does not do that – because you need npm, webpack, babel, systemjs, and so on and so on. This couldn't be further from the truth. And besides, create-react-app solves that. > No need to configure thousands of transpilers, no need to handle constantly breaking dependencies, because people keep their API stable for years, some even decades I have been using react since early 2014, back when it was still very early pre-release. I have had to change exactly one thing w.r.t to the react API. When we decided to add in webpack, again, I had to change exactly one thing there as well -- I switched to a .babelrc file and they included the react transpiler by default.
- kuschku 10y ago
  > And besides, create-react-app solves that. Until something breaks, and you have to go through all the configs and try to fix it. I’ve seen https://kukuruku.co/post/hello-real-world-in-php-in-2017/ https://kukuruku.co/post/hello-real-world-in-php-in-2017/ far too often.
  - treehau5 10y ago
    I think your comment is touching on two different points, in my view. > Until something breaks, and you have to go through all the configs and try to fix it. This is solved by understanding the language and the tools you are using. I see so many people screw up a react app because they don't know javascript. They take the same smorgasbord approach to languages and tools they have used in the past (like jQuery) and apply it to react. React is really a frontend framework for javascript developers, not a frontend framework for creative types (like Misko originally slated angular to be) If people would just take the time to learn the actual language they are using, it would make these other tools easier to grok. This is software development. It is suppose to be hard. Take the time to learn your tools. > I’ve seen https://kukuruku.co/post/hello-real-world-in-php-in-2017/ https://kukuruku.co/post/hello-real-world-in-php-in-2017/ far too often. I always wonder why people elect to use a heavy set of opinionated tools to solve simple problems. I understand the point the blog post is trying to make, but again, it's like taking a highly set of specialized tools and complaining when it is difficult to do the simple things, when all you needed was a hammer. React is a UI library first and foremost. You can take it, inject it into your page, and use it. You shouldn't add the bells and whistles until your complexity grows to the point where it makes sense to use it. I tell people to ask themselves this question all the time, "Are you sure you need flux?" Stop and ask that question. Can this be solved by just maintaining state on a top level component and passing down props? Do you need codesplitting and chunking and the advanced features of webpack? Or do you still operate in a traditional way where designers hand of their templates to coders to create the html and css and you are just tasked with writing the javascript? Then don't use webpack loaders. Use your coder's classnames on your components. This is people making things harder than they have to be. But again, all of this is really not that difficult if you take the time to fundamentally understand javascript.

BukhariH 10y ago

I'll be completely honest. I was anti-react when it initially (this is pre-create-react-app generator) came out and I'll tell you why. I tried to learn it and struggled understanding the new concepts react was bringing in all while people were saying "It's easy! Everything's a components. HTML,CSS,JS all in one place!" whilst I was struggling to get a simple hello world example to run. Just recently at my University we were forced to learn React as a part of our course and damn after I finally understood it I fell in love! It's a huge improvement over the normal web-app design work flow. So, I would urge anyone whose anti-react to honestly give it a good go and force yourself a little to get over the initial learning curve and trust me you'll love it!

kraftman 10y ago
Any tips for getting over the first hump?
- jdironman 10y ago
  Be forced to learn it evidently.
- Hnus 10y ago
  I could write a long list of things you should probably do but if I could recommend just one thing it would be to watch this video https://www.youtube.com/watch?v=xsKYAa1ZXpQ https://www.youtube.com/watch?v=xsKYAa1ZXpQ it really helped me to understand how react works.
- supergreg 10y ago
  Think of it as a way to create your own complex HTML controls like the combobox/select. And just like those, try to give all information it needs to work via attributes or sub-elements.
ergo14 10y ago
If you like component approach, take a look at Polymer, I'm right now working with react, and while it is OK, I've found that web standards based approache to components is better. And web components can be used in react or other solutions nicely. Being "anti-react" doesn't mean anti-component approach. You can do same with angular 1.5+, vue, aurelia or others.

ergo14 10y ago

> Where do these anti-React (anti-spa?) people come from Are you implying that react-way is the only way of doing SPA-s? > Do you think the web Peaked with Perl-based CGI-scripts I think your comment is just rude. There are plenty of other options in the JS world - react is just one of them.

YCode 10y ago
> Are you implying that react-way is the only way of doing SPA-s? Pretty sure he's generalizing; i.e. "anti-banana? (anti-fruit?)"
- ergo14 10y ago
  I'd expect someone who is "in this game for many years" to know better.
  - jakobloekke 10y ago
    It was meant as a polemic question, since the comments here seemed to be critical in a way that wasn't specific to next.js but more to the general space of spa's or even javascript. I see this a lot on HN, so I wanted to know if there were some constructive thoughts behind it. I sure didn't mean to be rude or anything! :)

rimliu 10y ago

The main reason that React is popular is because it is popular. I do not know where others come from, but I can tell where I come from: Web Standards Movement. There was such a thing some 15 years ago. People who cared about semantics, standards, accessibility. React is not bad. SPAs are not bad. That's bad is not having the understanding what should be SPA and what should not. Loading a couple of hundreds KB of scripts to show 1KB (ir you are lucky) of content is not OK. Alas, if you think that static (horror) or server-side generated (shock, horror) pages still have a place you will be brushed aside as someone who thinks that web peaked with Perl-based CGI scripts. Alas, a lot of what happens in web space now looks like inventing new solutions to the invented problems.

scotty79 10y ago

I know one anti-spa guy and his argument is that's basically reimplementing poorly things that were well implemented in rails without any obvious bemefit.

thewarrior 10y ago

One data point : Their Hackernews clone based on their own SPA framework is much slower than the plain old HTML site.

jjallen 10y ago
I was wondering about this too, but doesn't it have to get the data from the original site? The total network download is also many times the original at 233KB versus 11KB for Hacker News.
- Yaggo 10y ago
  Also, we don't know what kind of server resources they use vs. HN. The initial weight of SPA is typically much more than "plain html" site, but that's the price you pay for client-side functionality. Also, there exist more lightweight alternatives for React, e.g. Preact.
deleted 10y ago
[deleted]
scottmf 10y ago
It's a bad example and not representative as far as performance is concerned.

mattmanser 10y ago

Those are two separate questions really. React is another in a long line of Backbone, Angular, Durandal, etc. that ultimately just make stuff a lot more complicated for fairly trivial benefits. It dictates fairly complicated ways of doing simple things with long complicated tool chains that regularly break for obscure reasons that you can debug but ultimately it feels like you're simply wasting your life dealing with it. It's easy for juniors to make ridiculously complicated messes in them. They remind me of the good old days of RAD dev tools. "Oh so easy" they claimed. And if you're any good, you can enhance traditional web forms and add the same sort of functionality without all the overhead, or complexity. Perhaps I simply have the benefit of over a decade of front-end dev. As for SPAs, they still live firmly in the uncanny valley. They're poor versions of desktop apps, even desktop apps from the 1990s. Anyone claiming otherwise is simply delusional. Because of javascript and the DOM, they also tend to complexity, so that anything past a glorified to-do app becomes an absolute nightmare to code in. I use Trello, Asana, Toggl, SendWithUs, etc., etc. They're all, well, a bit shit. All of them have really annoying niggles, fields you click and then might auto-save but might not. Poor desktop interfaces because "mobile first". Tabbing that doesn't work properly. Data that gets out of sync. Or they're sllllooooowwwwwwwwwww. As for the reason React became so popular? This happened before with terrible frameworks. I may be a cynic, but it feels front end devs have got into some sort of mega-echo chamber where a new framework comes along and everyone jumps on to it because they don't want to seem out-of-date. The front-end world feels like it's in a strange kind of culture at the moment, a type of Emperor's New Clothes, where if you're not using The Latest Framework, you're obviously not worth employing. Not because it makes you get a product to market quicker. It's a new form of bike shedding.

lobster_johnson 10y ago
As someone who works a lot with React — and have previously worked with things like Rails and Backbone — I adamantly disagree that the benefits are trivial or that it's more complicated. The functional component architecture makes it considerably easier to create less buggy UIs with less messy codebases. You sound like you don't really know or understand React. Which is fine, but it doesn't put you in a good position to criticize it intelligently. React isn't popular because of any kind of echo chamber phenomenon. It's popular because of its design; it managed hit a particular very sweet spot combining the various principles of composition, modularity, functional purity and internally consistent state management. I do agree that web apps aren't as good as desktop apps. But that's not the fault of SPAs.

untog 10y ago

If you put development cycle time over user experience you're doing it wrong. Personally, I dislike that React is 100+KB file size, when Preact or Inferno can do 95% of what I want at with 3KB. (Yes, I know gzipping exists but it's still huge by comparison, and JS parse time is a real issue on underpowered mobile devices)

jakobloekke 10y ago
In my experience, user experience suffers when performance considerations play too big a part early in projects. Like when forcing a server rendering tech on frontend developers and designers.

Yaggo 10y ago

In my experience, many anti-spa people have seen too many poorly implemented single page apps (web fundamentals broken such as links and uris) and/or have out-of-date information that spa cannot properly support such things. Cannot blame them, althought the situation is better nowadays, it's still not uncommon to find a spa site where the said things are broken.

chiefalchemist 10y ago
I think you make a good point, even if indirectly. That is, the technology keeps changing but the products and experiences seem to remain subpar, frustrating, wonky, etc. Perhaps these technologies are progress from a pure technology POV, but if real end users were to judge what would they say? Are we drinking too much of our own Kool Aid? Still? Again?
- nperez 10y ago
  I think the experiences are getting better. My first SPA projects were with Angular 1.x and for the whole duration that I was using it, I found that I could point out an Angular 1.x based site off of gut feeling / familiarity with certain pain points (hi Seamless). I feel like there was a huge reduction in bug-prone madness when React + the Flux pattern started gaining steam. We are still collectively working toward an end (reliable software in the browser) but it's impossible for me not to feel the difference in the past few years, as a dev and a user. SPAs are sort of a hack. The web was designed for documents that link to each other. Maybe they'll never be perfect until we reach some sort of impossible isomorphic framework utopia, but there is real progress being made
  - chiefalchemist 10y ago
    You might think that. As might I :) What I'm suggesting is you ask your mother, father, grandparents,other developers, the person working the counter at the cafe, etc. Listen closely. I'm not so sure there's massive support to believe UXs are improving noticably.

agmcleod 10y ago

Speeding up development cycle is not the only goal. Its not a good thing when it causes the user experience of the application to be worse. I think SPAs have come a long way in this regard, but it was definitely quite rocky for a while.

arunoda 10y ago

I'm one of the core-contributors of Next.js. We are not anit-React or anti-spa. And we are pretty closely work with JS stuff. But Next.js is inspired by the simplicity of PHP. ### Anti SPA The whole idea of Next.js is to build a SPA easily. But it's also server rendered by default.

Arcsech 10y ago

I'm not anti-SPA (and in fact, I think of the tools out there react is a pretty good one if you're going to do SPA), but I do think it's the wrong tool for a lot of jobs. If your site is mainly content-based, like a blog or a forum, why make it an SPA? I feel like React/Angular/Vue/etc apps are becoming "the way the web is done" when so many things would be simpler and more efficient as plain old web sites with server-rendered HTML. It's like everyone decided that because convertibles are cool, they should be used for everything, and are now spending a ton of effort hitching trailers to their convertibles when it would have been much simpler and more effective to just drive a boring minivan in the first place.

NoGravitas 10y ago
I very strongly agree with this. There are certainly web apps that can only reasonably be done mainly-client-side. I'd give Office 365 as a baseline example. But what drives me crazy is sites like Medium [0][1]. It's a shared blog site. To read a one sentence essay on Medium requires downloading over a megabyte of data. And their comment system is still inscrutably terrible. Content-focused sites should absolutely not be done as SPAs. Server rendered HTML and client-side enhancement will deliver a better experience to the customer and IMO a better developer experience as well. [0]: http://idlewords.com/talks/website_obesity.htm http://idlewords.com/talks/website_obesity.htm [1]: https://medium.com/@mceglowski/chickenshit-minimalism-846fc1412524#.7dgoctho7 https://medium.com/@mceglowski/chickenshit-minimalism-846fc1...
- chrisrhoden 10y ago
  The page you link to on Medium renders after less than 100KB have been downloaded with an unprimed cache. Javascript is not required to read it. Javascript is used to provide extra functionality outside of the download / render cycle, to speed the experience of the page up, and to make future navigation faster. I understand where you are coming from, but you picked a bad example.
  - TeMPOraL 10y ago
    > Javascript is used to (...) speed the experience of the page up That is one thing I'm totally not buying. How does JavaScript speed anything up over simple staticly rendered text, (which is what Medium should be)?

silviogutierrez 10y ago

My biggest issue is that SPAs have a lot of overhead for your typical CRUD. The canonical example: a CRUD page with a dropdown of choices based on entitlement. Server rendered: in your template somewhere, {for choice in limited_choices} and so on. SPA: you need to coordinate a REST endpoint that has options for entitlement of just this dropdown, etc. You now need a route for REST, a route for the SPA page, and view code for both. Don't get me wrong, with unlimited time, build everything as REST services with a client that consumes it. But sometimes server-side rendering is just simpler.

nojvek 10y ago
SPA shines if you are building lots of CRUD. Rest end points are simpler and simply mush data out of the db. No templating crap. It's a lot faster to load template once and re-render on client with different data.

bandrami 10y ago

Do you think the web Peaked with Perl-based CGI-scripts? In some very important ways, yes. Specifically, it was still within the contraints of what HTTP and HTML were designed for: the transfer and rendering of marked up documents. Obviously all technology is x steps forward, y steps back, and you aim for some workable linear combination of x and y, but there have definitely been several regressions since the days of Perl-based CGI scripts, and I personally haven't found them worth the advances.

holtalanm 10y ago

I very much like SPA's. It is mostly React that I have a problem with. I don't trust their License Agreement when it states they can revoke your License for any reason. Basically, if I get on the wrong side of Facebook, they can pull my License for React without a warning. Unless they have amended their license since the last time I read it. In which case, I would like to see the updated version. Until then, I will continue to use InfernoJS.

underwater 10y ago

The React ecosystem's take on performance is really immature. Generally the server's job stops at isomorphic rendering which is a brute force and imperfect way of improving performance. Next.js and React Server are making steps towards solving this by bringing concepts like incremental loading and data hydration by default. I've talked about some of the approaches Facebook used to improve startup performance in the past: https://www.youtube.com/watch?v=b875VAC6r-w https://www.youtube.com/watch?v=b875VAC6r-w