Eschew developer fashion (and fashion contrarianism) and use the best tool for the job. It doesn't make sense to pick the tool before you even know what problem you're trying to solve.
Ask HN: What companies are embracing “HTML over the wire”?
111–120 of 192 posts
Re: Ask HN: What companies are embracing “HTML over the wire”?
#112Earlier quoted context omitted.
I find it much less smooth having a webpage consuming constant CPU.
That's a different issue. There's no reason CPU consumption should be high when you aren't interacting with an application.
Most of the time there is no need for "it" to be an application, when it can be a page with some buttons.
Re: Ask HN: What companies are embracing “HTML over the wire”?
#113Earlier quoted context omitted.
IF you want the page to be interactive without refreshes though, you gotta do something. Unless you are advocating a completely pre-ajax web. https://en.wikipedia.org/wiki/Ajax_(programming)
A bit of Ajax here and there is fine. Look at how HN handles it when you upvote/unvote a comment. Look at how old.reddit.com handles it when you click "load more comments" in a long thread.
> Look at how HN handles it when you upvote/unvote a comment.
How?
Re: Ask HN: What companies are embracing “HTML over the wire”?
#114[deleted]
Re: Ask HN: What companies are embracing “HTML over the wire”?
#115Earlier quoted context omitted.
IF you want the page to be interactive without refreshes though, you gotta do something. Unless you are advocating a completely pre-ajax web. https://en.wikipedia.org/wiki/Ajax_(programming)
Why are refreshes assumed to be bad?
Latency between page going blank and FCP, poor recovery mechanisms. Significant number of users is still on occasionally bad connections (e.g. on a train, walking into the part of the building with poor signal etc). If interaction in SPA does not work, they can try again, because they still have the UI. If page goes blank and does not load, not every user will recover from this.
Re: Ask HN: What companies are embracing “HTML over the wire”?
#116> Even if you use React in small areas where it pulls its weight but generally try and stick to simplicity of sending plain ol' HTML
The reason why so many apps use React/Vue/whatever for everything is because this hybrid setup is far from simple. It leaves you with two different ways of rendering views, which creates unnecessary context switching for developers, and the interface between the two is often ugly and complicated and prone to memory leaks if you're not careful. It also prevents you from taking advantage of the most powerful patterns in these frameworks, which rely on the assumption that it's running as a single page app.
The fact is, if your app has functions that require a JavaScript framework to work, the most straightforward answer is to build the whole app in that framework, rather than trying to cobble together multiple front end systems.
Re: Ask HN: What companies are embracing “HTML over the wire”?
#117Earlier quoted context omitted.
Why are refreshes assumed to be bad?
Refreshes can be very fast, and often essentially invisible in modern browsers, when you don't bloat the page unnecessarily, but I think AJAX still has a use for things like the voting button on HN or "add to cart" buttons in a web shop. It would be annoying to lose the scroll position (and perhaps other state) for each item you want to add/upvote. (Although modern sites that try to sweep latency under the rug by imm…
"Refreshes can be very fast, and often essentially invisible in modern browsers"
That's thanks to a fantastic browser feature that was introduced a few years ago that hardly anyone knows about: Paint Holding - https://developer.chrome.com/blog/paint-holding/
"... where the browser waits briefly before starting to paint, especially if the page is fast enough. This ensures that the page renders as a whole delivering a truly instant experience."
This is why you don't see flashes of a blank white page while a new page is loading on most sites these days.
Re: Ask HN: What companies are embracing “HTML over the wire”?
#118Earlier quoted context omitted.
Having only worked at SPA places, it's hard for me to imagine not having tools like Storybook, Chromatic, and Mocked Service Workers. Building the UI in isolation means with mocked API responses means I can, in parallel, validate 1000's of use cases with pixel-level precision. The backend teams can keep their focus on scalable, performant APIs. The frontend teams can focus on accessibility, consistency, etc. I've fou…
Indeed this is one of the challenges of hiring front end for SSR apps. There's now a whole generation of front end engineers who have never had to build a plain old SSR html page, and never had to use or read any language other than JS. Learning this style of development is starting from scratch for them. Yes SSR is a radically simpler stack, but not until you learn it. And you probably need to learn at least on more…
[deleted]
Re: Ask HN: What companies are embracing “HTML over the wire”?
#119How timely, I, too, am in the market for a new job and I've noticed that ridiculous new buzz of "HTML over the wire" or related to "over/on the wire". Thanks for writing this.
Re: Ask HN: What companies are embracing “HTML over the wire”?
#120People have gotten way too religious over SPAs, SSR, etc. Should you use X? Maybe it depends. I have been burned by using SSR when the complexity of the app increased and suddenly doing SSR was getting in the way and now I was uncomfortably mixing JS with server rendered pages and struggling to maintain state. I've also been on the other side, using React and creating more complexity than was needed. The point is: do…
Exactly. My rule of thumb is that SSR is good when you optimize conversion (hence focus on bounce rate, FCP, time to interactive), SPA is good when you optimize UX (hence focus on interactivity, response time, recoverability etc). On the customer journey SSR is usually everything before registration and login, SPA is for most of the things after (except some embeddable static content like help pages).