3 ms·

You should take a look at the frameworks mentioned in the article. They each address some or all of your concerns. The distinction here isn’t going back to “old

You should take a look at the frameworks mentioned in the article. They each address some or all of your concerns. The distinction here isn’t going back to “old school” MPA development, but a trend in component frameworks towards shipping more truly static HTML and less unnecessary JS. For the landing page/blog type experience, Astro is a great fit. Qwik is probably a better fit for your use cases as it’s intended for more interactive apps. But both can span that interactivity spectrum. I can’t speak to where Elder fits on that spectrum, not having used it and having little experience with Svelte. I’m disappointed not to see Marko mentioned, as it’s been in this category for years and used at scale at eBay. It fits very well in the middle of the interactivity spectrum. Anyway, it’s worth checking all of them out just to even see what’s happening in the ecosystem. I’m personally very interested in Qwik‘s familiar React-like DX with what they call “resumability”: their alternative to hydration; components compile to fine grained chunks and resume from state serialized to HTML, rather than re-running the original component on load.

BigJono 4y ago
No, they shouldn't look at some of the frameworks. They're all more complex than just making a bog standard SPA, which seems to be working fine for them. People need to stop bringing in that complexity when they don't need server rendering. This is basic software engineering shit, and it boggles me that the industry can't get it right. Same kind of code goes in the same place and runs in the same context unless you specifically need to do otherwise. No reason not to route and render on either the client or the server unless you absolutely need both. Trying to get fancy is how you end up with a truckload of bugs you wouldn't have otherwise had. I've been on like 5 projects that have spent months dicking around with Next or Nuxt or Gatsby or whatever rubbish, lighting client money on fire, for a portal behind a login that doesn't need to be indexed and would work totally fine as an SPA.
- eyelidlessness 4y ago
  > No, they shouldn't look at some of the frameworks. They're all more complex than just making a bog standard SPA, which seems to be working fine for them. Should was probably too strongly phrased, shouldn’t definitely is. The suggestion wasn’t “hey go learn a new framework, your current solution isn’t up to date” or whatever. It was really, very sincerely, “the frameworks discussed in article agree with you, you oughta keep an open mind”. Encouraging both a general, and clear area of interest, spirit of curiosity. I don’t get the sense that you have or want that curiosity on the topic, by all means stick with what’s working and carry on. If your comment was paired with downvote, I do want to thank you for the comment. It’s refreshing to get a perspective on why someone didn’t like something I said, when I wouldn’t have that insight otherwise.

BigJono 4y ago

No, they shouldn't look at some of the frameworks. They're all more complex than just making a bog standard SPA, which seems to be working fine for them. People need to stop bringing in that complexity when they don't need server rendering. This is basic software engineering shit, and it boggles me that the industry can't get it right. Same kind of code goes in the same place and runs in the same context unless you specifically need to do otherwise. No reason not to route and render on either the client or the server unless you absolutely need both. Trying to get fancy is how you end up with a truckload of bugs you wouldn't have otherwise had. I've been on like 5 projects that have spent months dicking around with Next or Nuxt or Gatsby or whatever rubbish, lighting client money on fire, for a portal behind a login that doesn't need to be indexed and would work totally fine as an SPA.

eyelidlessness 4y ago
> No, they shouldn't look at some of the frameworks. They're all more complex than just making a bog standard SPA, which seems to be working fine for them. Should was probably too strongly phrased, shouldn’t definitely is. The suggestion wasn’t “hey go learn a new framework, your current solution isn’t up to date” or whatever. It was really, very sincerely, “the frameworks discussed in article agree with you, you oughta keep an open mind”. Encouraging both a general, and clear area of interest, spirit of curiosity. I don’t get the sense that you have or want that curiosity on the topic, by all means stick with what’s working and carry on. If your comment was paired with downvote, I do want to thank you for the comment. It’s refreshing to get a perspective on why someone didn’t like something I said, when I wouldn’t have that insight otherwise.