4 ms·

React has been around for 7 years. ES2015 has been around for 5 years. React has become the de facto lingua franca for front end development. Could you imagine

React has been around for 7 years. ES2015 has been around for 5 years. React has become the de facto lingua franca for front end development. Could you imagine some CTO or technical lead saying, "We're not going to use React because it's too new and unproven." React has proven itself. Facebooks has 100K+ components. There are no unknowns there. Using jQuery or vanilla JS instead would be way more problematic and have more overhead than using something more experimental like Elm or ReasonML. You should almost never use classes in JS, but when you do, they're much easier to work with and understand than defining properties on the prototype. The "new" keyword has been around since almost JS's inceptions (it's available in IE 3, which came out in 1996). Some of your technologies require no learning to start using (PostCSS). Some can require a whole new mental model/programming paradigm, but can be incredibly useful if used sparingly and in the right places (RxJS). And some things you just need to do to not have a garbage application (testing). Look, just make assessments as to what your needs are, what are common practices, what your current team is capable of being productive with, and what you're going to be able to hire from.

bsaul 6y ago
i'm still under the impression that SPA are still not very good for SEO ( unless you also add server side rendering ability, which is probably a bit more involving and "not boring"). is this still a valid concern as of today ?
- ozim 6y ago
  I have a different question. Why do you want to SEO an application? I understand you want to SEO your landing page or blog but SPA should be dynamic content which you don't even want to be crawled by google.
  - bsaul 6y ago
    Yes you're right, my question wasn't for apps, but as a response to using react as a universal web frontend tech.
    - guggle 6y ago
      > a universal web frontend tech There... that's the problem.
arsenico 6y ago
Not "new" doesn't mean boring. Boring means not using a technology (a framework, or a language) when not needed. Don't use Javascript on the frontend, when not needed, stick with one CSS pre-processor, one database, one cloud provider, one orchestration tool, one CI tool. Be frugal with your stack, and it will payoff.
- dmwilcox 6y ago
  Agree with the sentiment but, one CSS preprocessor (!!) Lol I must be getting old, CSS3 is amazing why do you even need one? That's a totally optional component that now needs to be updated, used in your build pipeline and Lord help you if you install it with npm and it isn't updated for a couple of years. I'd add boring really means boring, yes that kind of boring (zzz) ;)
  - dahauns 6y ago
    I think Sass fits the "boring" moniker quite well when it comes to CSS preprocessors. :) That said, with recent and planned advances in CSS3 (and free of the IE shackles :) ), CSS preprocessors surely are slowly going the way of JQuery.
JamesBarney 6y ago
Despite React being around for 7 years, it still seems slower to develop, slower in performance, and buggier than an equivalent SSR app. Despite having a couple years more experience in React than SSRs, I can knock out a 10 page web app with an SSR framework from scratch in a day (security, frontend, backend, data schema, deployment) but it takes me a couple more to knock out the same app in React. (Crud/Search/Reporting app) *Not counting certain types of highly interactive apps (like a Word Processor) which React excels at.
- dgb23 6y ago
  It depends on the project. I’m way, way more productive with a React frontend environment (webpack, babel, tailwind, next) when working with handcrafted designs. Even when the interactivity is trivial. And I know from experience that interactivity inevitably becomes more involved very often. One key feature is that JSX works on both the frontend and the backend.
- arcturus17 6y ago
  I’m in the same boat, SPA feels slower to develop than SSR to me, despite being fairly more experienced in SPA. However, I find it hard to justify choosing SSR for new projects anymore because: - React makes certain basic things (eg, fetching data, auth) more complex than in SSR, but the overall experience is weirdly addictive and exhilarating at times, especially component reusability on a well set up project. - My clients love it. I am 100% in the camp of “users don’t give a shit how the sausage is made”, but I constantly get praise on how “smooth” the UX feels. I know there are SSR technologies (eg Turbolinks) that can emulate this, but at this point I’m having a hard time justifying learning them properly and risking missing out on that maybe superficial, but addictive, customer praise. - It is indeed what I know best, so what the hell... I believe a competent web developer should know both SPA and SSR and apply what best fits the requirements at hand, but I can also appreciate why devs form biases one way or the other and how this has become a hotly contested topic, and I think we may still be in the same spot in three to five years.
  - nthj 6y ago
    Turbolinks takes a day to learn, tops, and then you just build more SSR and it continues to work. And the abstraction rarely leaks.
ryanbrunner 6y ago
React itself has been around for 7 years, but the ecosystem around React is still developing. There isn't a straightforward answer that's universally accepted and without warts in terms of how to do server communication, how to manage state, how to smoothly implement routing in a way that avoids most of the navigation hiccups that SPAs run into, how to manage CSS, etc. There's certainly answers which seem promising for all of those areas, but it seems to me that in every React project I work in, "use React" is the easy part - it's the 50 other decisions that need to be made as a consequence of that first easy decision that waste a lot of time and energy.
- wpietri 6y ago
  This resonates for me. I'm mainly a back-end developer, but for a while I've been wanting to improve my front-end skills so I can do basic things myself. React has been the obvious choice for a while. But every time I say, "Ok, let's see what I need to learn to get started," which happens maybe once a year, I end up getting different answers. I would like React to get more boring. Because I'll never focus mainly on the front-end, I can't devote a lot of cycles keeping up with the latest trends. If I have to make 50 (or even 5) informed decisions every time I want to throw a little interface on something, I'll never get anything done.
  - xtracto 6y ago
    I think SPA are overvalued. They are slow to load, clunky and the paradigm of loading "modules" is messy. I prefer web components and plain html /js .
  - ng12 6y ago
    If you're just wanting to get your feet wet create-react-app is the right choice. Go strictly by their docs: they do a good job of leading you to third-party solutions when required. In a way React suffers from it's own popularity. For example Next/Gatsby can be confusing for new developers but they only exist because React is popular enough to have popular meta-frameworks focused on solving specific use cases.

bsaul 6y ago

i'm still under the impression that SPA are still not very good for SEO ( unless you also add server side rendering ability, which is probably a bit more involving and "not boring"). is this still a valid concern as of today ?

ozim 6y ago
I have a different question. Why do you want to SEO an application? I understand you want to SEO your landing page or blog but SPA should be dynamic content which you don't even want to be crawled by google.
- bsaul 6y ago
  Yes you're right, my question wasn't for apps, but as a response to using react as a universal web frontend tech.
  - guggle 6y ago
    > a universal web frontend tech There... that's the problem.

arsenico 6y ago

Not "new" doesn't mean boring. Boring means not using a technology (a framework, or a language) when not needed. Don't use Javascript on the frontend, when not needed, stick with one CSS pre-processor, one database, one cloud provider, one orchestration tool, one CI tool. Be frugal with your stack, and it will payoff.

dmwilcox 6y ago
Agree with the sentiment but, one CSS preprocessor (!!) Lol I must be getting old, CSS3 is amazing why do you even need one? That's a totally optional component that now needs to be updated, used in your build pipeline and Lord help you if you install it with npm and it isn't updated for a couple of years. I'd add boring really means boring, yes that kind of boring (zzz) ;)
- dahauns 6y ago
  I think Sass fits the "boring" moniker quite well when it comes to CSS preprocessors. :) That said, with recent and planned advances in CSS3 (and free of the IE shackles :) ), CSS preprocessors surely are slowly going the way of JQuery.

JamesBarney 6y ago

Despite React being around for 7 years, it still seems slower to develop, slower in performance, and buggier than an equivalent SSR app. Despite having a couple years more experience in React than SSRs, I can knock out a 10 page web app with an SSR framework from scratch in a day (security, frontend, backend, data schema, deployment) but it takes me a couple more to knock out the same app in React. (Crud/Search/Reporting app) *Not counting certain types of highly interactive apps (like a Word Processor) which React excels at.

dgb23 6y ago
It depends on the project. I’m way, way more productive with a React frontend environment (webpack, babel, tailwind, next) when working with handcrafted designs. Even when the interactivity is trivial. And I know from experience that interactivity inevitably becomes more involved very often. One key feature is that JSX works on both the frontend and the backend.
arcturus17 6y ago
I’m in the same boat, SPA feels slower to develop than SSR to me, despite being fairly more experienced in SPA. However, I find it hard to justify choosing SSR for new projects anymore because: - React makes certain basic things (eg, fetching data, auth) more complex than in SSR, but the overall experience is weirdly addictive and exhilarating at times, especially component reusability on a well set up project. - My clients love it. I am 100% in the camp of “users don’t give a shit how the sausage is made”, but I constantly get praise on how “smooth” the UX feels. I know there are SSR technologies (eg Turbolinks) that can emulate this, but at this point I’m having a hard time justifying learning them properly and risking missing out on that maybe superficial, but addictive, customer praise. - It is indeed what I know best, so what the hell... I believe a competent web developer should know both SPA and SSR and apply what best fits the requirements at hand, but I can also appreciate why devs form biases one way or the other and how this has become a hotly contested topic, and I think we may still be in the same spot in three to five years.
- nthj 6y ago
  Turbolinks takes a day to learn, tops, and then you just build more SSR and it continues to work. And the abstraction rarely leaks.

ryanbrunner 6y ago

React itself has been around for 7 years, but the ecosystem around React is still developing. There isn't a straightforward answer that's universally accepted and without warts in terms of how to do server communication, how to manage state, how to smoothly implement routing in a way that avoids most of the navigation hiccups that SPAs run into, how to manage CSS, etc. There's certainly answers which seem promising for all of those areas, but it seems to me that in every React project I work in, "use React" is the easy part - it's the 50 other decisions that need to be made as a consequence of that first easy decision that waste a lot of time and energy.

wpietri 6y ago
This resonates for me. I'm mainly a back-end developer, but for a while I've been wanting to improve my front-end skills so I can do basic things myself. React has been the obvious choice for a while. But every time I say, "Ok, let's see what I need to learn to get started," which happens maybe once a year, I end up getting different answers. I would like React to get more boring. Because I'll never focus mainly on the front-end, I can't devote a lot of cycles keeping up with the latest trends. If I have to make 50 (or even 5) informed decisions every time I want to throw a little interface on something, I'll never get anything done.
- xtracto 6y ago
  I think SPA are overvalued. They are slow to load, clunky and the paradigm of loading "modules" is messy. I prefer web components and plain html /js .
- ng12 6y ago
  If you're just wanting to get your feet wet create-react-app is the right choice. Go strictly by their docs: they do a good job of leading you to third-party solutions when required. In a way React suffers from it's own popularity. For example Next/Gatsby can be confusing for new developers but they only exist because React is popular enough to have popular meta-frameworks focused on solving specific use cases.