9 ms·

SPAs (single page applications) aren't boring yet. we really don't know how to do this well, as a community, and the cambrian explosion of JavaScript tech is al

SPAs (single page applications) aren't boring yet. we really don't know how to do this well, as a community, and the cambrian explosion of JavaScript tech is almost all around trying to make this extremely un-boring application style more boring. The SPA is a gateway drug to spending lots and lots of innovation tokens, more, really, than almost any dev team can afford. For example, I would consider each of Webpack, PostCSS, TypeScript, React, Redux, RxJS, to be rather exciting, and that's only a few of the exciting parts of a mature SPA project. And of course this doesn't touch REST, GraphQL, CI/CD, testing, metrics, telemetry and all the other excitement. So, yeah, I would say that if you take the article seriously for a webapp, you'd limit yourself to a really boring Java (8) server-side architecture using Jetty, JSP, Spring, a service layer, over Postgres. Maybe an nginx proxy if you want to get a little spicy and have good SSL and static serving performance, and an option for simple load balancing later. Oh and the only provisioning you get to do is individual VPSs or even better, bare metal on prem servers! Git and Jenkins is probably boring enough to use, though. But yeah, no Docker, K8s, OpenShift, no AWS other than EC2 and maybe S3. Probably no CloudFlare. Google Analytics, sure, but only if you don't care about your users privacy. Sentry is too exciting. And then on the HTML side I'd argue that your templates should produce plain old HTML5, CSS3 and ES6. No transpilation, no source maps. No official support for IE 11. And even for those languages you can cut out the most exciting features. Do you really need the "class" or "new" keywords in ES6? For JS modules, use the boring, built in browser module system (you knew it had one, right?![1]) 1 - https://caniuse.com/#feat=es6-module-dynamic-import https://caniuse.com/#feat=es6-module-dynamic-import

baron816 6y ago
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) ;)
scott_w 6y ago
If you’re primarily, say, a Python/Django developer, then I can see how adding React is spending innovation tokens i.e. only do it if you have to (even in 2020). However, if you have React devs in your team, then this is NOT spending an innovation point at all. The same would hold true for even MongoDB here.
quickthrower2 6y ago
A SPA is really just a desktop app where you are forced to use JS and need to BYO front end tool kit. For that we have Typescript (mature) and React (mature). I'd say it's a boring as a WPF app in Windows or an iOS Objective C app. I think we know how to do this well in the general case for most business CRUD needs. That said I am always of the opinion of don't SPA if you don't need to. (also don't spar if you don't need to!).
- readarticle 6y ago
  While it’d be nice to build out an app with only Typescript and React, they’re just the basics. Is routing in react as mature and boring as a UINavigationController whose API has barely changed since 2009, for example? Is animation? Accessibility? Styling? Are the material-ui and ant-ui kits as boring and mature as the platform’s UIKit? And I’m not even going to bother going into development environments, or the effects of all these different approaches & API changes on documentation and support!

baron816 6y ago

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) ;)

scott_w 6y ago

If you’re primarily, say, a Python/Django developer, then I can see how adding React is spending innovation tokens i.e. only do it if you have to (even in 2020). However, if you have React devs in your team, then this is NOT spending an innovation point at all. The same would hold true for even MongoDB here.

quickthrower2 6y ago

A SPA is really just a desktop app where you are forced to use JS and need to BYO front end tool kit. For that we have Typescript (mature) and React (mature). I'd say it's a boring as a WPF app in Windows or an iOS Objective C app. I think we know how to do this well in the general case for most business CRUD needs. That said I am always of the opinion of don't SPA if you don't need to. (also don't spar if you don't need to!).

readarticle 6y ago
While it’d be nice to build out an app with only Typescript and React, they’re just the basics. Is routing in react as mature and boring as a UINavigationController whose API has barely changed since 2009, for example? Is animation? Accessibility? Styling? Are the material-ui and ant-ui kits as boring and mature as the platform’s UIKit? And I’m not even going to bother going into development environments, or the effects of all these different approaches & API changes on documentation and support!