> Gulp, CoffeeScript, BackboneJS, and SASS, all of which have been superseded by newer tools. Avoid the Javascript fatigue by not relying so much on Javascript!
What ? These are all javascript things, right ?
You probably don't need a single-page app
51–60 of 522 posts
Re: You probably don't need a single-page app
#52Normally you'll always need to add something interactive, therefore js. To do that with server side rendering you'll couple the client side to the server side. For example the server has to send a tag with a class name that the client also is aware of that. Therefore you have 1 component, where half is on server side and half of on client side, which in my opinion is not maintainable.
> Normally you'll always need to add something interactive Especially in news, articles, longreads, right? /s Most of the internet content would be perfectly fine without interaction, or with ordinary, oldschool POST forms
News web site can return part of the page (e.g. news article) to decrease TTFB, and then load less important content (e.g. news recommendation) after.
As author said, it is tradeoff.
Re: You probably don't need a single-page app
#53One problem we're having with the hybrid approach (Laravel + Mithril) is not being able to reuse common UI components between php & js rendered parts. Laravel has blade templates, and mithril is coded similarly to react.
The other problem is deciding which to use when starting a new feature or section. A page may start out fairly static but end up needing a rewrite when the specs change and start requiring more dynamic UI elements.
Re: You probably don't need a single-page app
#54I tried the other day, yet again, to give it a go. You know, firing up VS Code and make an app with express, node, react bla bla bla. Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. The hundreds of possible directions you can go in, in terms of frameworks, packages and what not is ludacris. I stopped working when my node modules directory topped…
You could use Blazor to export to webassembly, but it includes the entire .NET runtime, so the payload is huge.
It's a bit silly to say you quit when you topped 60mb in your node modules directly, something you never have to look at and doesn't represent what gets built in to the final app. There's tons of dependencies when dealing with the .NET toolchain.
There are hundreds of directions you could go in, and I consider that a good thing. There are choices, but there are recommended paths for beginners as well.
It sounds to me like you're hating on a toolchain that you don't have any experience in.
Re: You probably don't need a single-page app
#55Earlier quoted context omitted.
This is unrelated to the article. Many webpages, like HN, use JS but are not SPAs.
I think old.reddit.com's interface is more user-friendly than HN's. Why should I leave the page to write a comment? Avoiding JS just for the sake of avoiding is just blind fanaticism under the pretense of being faster and more lightweight. (The new reddit redesign is a resource hogging abomination riddled with needless SPA bullshit, but the old reddit design was pretty clean and minimal and yet an SPA.)
The old Reddit design isn't really an SPA. It's just server rendered with a bit of Ajax for interactivity
Re: You probably don't need a single-page app
#56I'm more interested in the future of "you probably don't need a native app" . It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there. I do worry, though, that it's not really in Apple's or Google's best interest to move that along.
This is the only reason we have an SPA to begin with-- small team writes a single frontend and deploy to web, iOS and Android via Cordova, Windows via Electron, and (previous) Chrome OS via the now deprecated Chrome App APIs. If we didn't need to support the full experience on all these devices, SPA would be way overkill.
Re: You probably don't need a single-page app
#57One problem we're having with the hybrid approach (Laravel + Mithril) is not being able to reuse common UI components between php & js rendered parts. Laravel has blade templates, and mithril is coded similarly to react. The other problem is deciding which to use when starting a new feature or section. A page may start out fairly static but end up needing a rewrite when the specs change and start requiring more dynam…
I would rather change a page if and when it is needed by a new feature than over engineer up front.
Re: You probably don't need a single-page app
#58The concept of a SPA is a total hack of web patterns. I predict in a few years we'll refer back to SPA's the way we do now to AJAX or DHTML.
We're getting closer to the best of both worlds, where we SSR pages and then "hydrate" them with JS components. The tooling around this isn't great yet, but it's definitely all there.
Re: You probably don't need a single-page app
#59I couldn't disagree with this article more. Developing SPAs is easier than server-render applications. The problem is React, Redux, and other such libs make this more complicated than necessary. React is all about surgically making the smallest possible change in the DOM to refresh the page. But is that really needed? Most of the time it is not. Why not re-render the whole page? This is what happens in the case of se…
You don't need React, Redux, and other such libs, true.
But you're missing the point of them. It's to prevent the problems that cropped up after years of jQuery development.
Too many side-effects and poor state management lead to very hard to find bugs.
When you follow the redux (or whatever state lib) flow you prevent a lot of these issues.
Re: You probably don't need a single-page app
#60I simply prefer them because I think their architecture is simpler than some frontend/backend mixed HTML stuff.
JAM-stack etc. just create static html/css/js and deliver it over a CDN of your choice, then hook into the services as you need them...