Hacker News Reader

Comment by jerjerjer | Hacker News Reader

Is “HTML over the wire” a new buzzword for SSR or is there a difference I'm missing?

It is rendered server side, but typically the server keeps track of only what needs to change and sends as small as possible an update to dynamically update the DOM. You end up with a user experience that feels close to an SPA, but a dev experience that feels close to traditional SSR.

Tech like LiveView (Phoenix) and LiveWire (Laravel) are great examples of this.

Also Blazer Server (C#) and the upcoming Blazor United slated for .NET 8

And htmx for a language-agnostic one

I've been working on one of those frameworks, although the dev experience feels more like a SPA in this one. https://github.com/mayu-live/framework

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 found a secret sauce that works very well in my organization, and I'd be curious to know what the equivalent would look like for SSR apps. But I can't overstate of much of a boon it's been to develop the client in isolation. Nearly all my bug reports go straight to the backend teams. It's bliss.

Yeah, I hear the HTML-only case more from people who were full-stack or backend. Giving up the tooling around SPAs would be hard. I'm not sure what the equivalent is - is there any frontend-specific advice for backend devs that amounts to "wouldn't it be cool if you gave up all your developer tooling?"

Like "lets use firebase"?

At what cost? You can validate 1000s of use cases but you can't validate one that doesn't include that 25m download and simulate what a real user experiences.

Are developer tools more important than the product they create?

We do browser based end-to-end testing which tests the frontend and backend at the same time using a single tool (Capybara in our case). We take snapshots at various points during the test runs which are then compared to previous runs for visual regression testing.

Nothing is isolated so it's probably slower. The tradeoff is that the tests are really simple for how much they cover, and they're entirely separate from the implementation details so refactoring/changing technologies becomes really easy. It's an old project and we've incrementally migrated from jQuery to Backbone to React to Stimulus with the same tests. Conceivably we could change the app to a SPA and keep the tests.

I have no way to really know if it's better than anything else (though I am interested in that question!), but I think it has worked out pretty well for us. One metric might be that our main app has been around for 10+ years, we're still delivering features daily, and nobody is complaining about a rewrite.

How do you test cases like, "the app should show an error screen when an error occurs in the database or server-side application layer"? In the SPA approach, I find these things quite easy to model with a service worker; just mock JSON API with the non-200 response code with body. I do see the merits of end-to-end testing but I've found it quite simple to mock the interface rather than ensure the database is primed with my situation in mind, or setup or teardown those records to ensure my 404 page renders correctly. And then I have to know how those parts of the system work, to create my test case. It does seem like an increase in cognitive load.

We have some tests like that. We're injecting a stub to generate the error condition and then testing the output. The test code runs in the same thread as the server so we can temporarily inject a stub into the server for some cases.

You're right we have to know something about the system to know where to inject the stub, and in fact it makes the test brittle in case that implementation detail changes (which has actually happened and failed these tests before), but it doesn't really matter where we inject the stub to cause the error response, so it's not as bad as it sounds. I think it might be pretty analogous to knowing where to mock the JSON API w/ a non-200 response code.

We very rarely stub anything and consider it a code smell, this is one case where we made an exception though because there is otherwise no way to generate an error message via the user interface.

it looks no different with ssr apps, and you don't have to give up any of what you mentioned at the beginning

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 language.

That sounds really expensive for the server.

Partly, but it especially means things like Phoenix LiveView[0] or htmx [1]. With these you can create SPA like experiences by sending partial html updates from the server and applying them by some light JS to the UI (which you don't have to write yourself).

[0] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html [1] https://htmx.org/

The first time I saw the concept codified in a library was in a jquery function that allowed you to replace a part of the DOM. Either the method signature or the documentation pointed you to using it in pairing with AJAX requests.

The first webapp framework I saw it in was Rails (turbolinks). I came to Rails late and didn't stay long so I was never clear how old or how broadly used that feature was. Mostly what I got from Rails was being more comfortable writing NodeJS code, which stole shamelessly from Rails.

i wouldn't call Element.replaceWith a codification of html-over-the-wire

Nor would I. I was talking about load(): http://api.jquery.com/load/

I think it's HTMX etc, so yes SSR. That was how I started building web apps in my first job as a dev, crazy how the loop of front-end technologies is only like 10 years.

Was it a loop? I thought it was stagnation due to the fact that everyoen was trying to copy mobile apps and bring them to the web. It was a bad decision because mobile apps are by definition constrained and not very versatile. In any case, people seem to be picking up where they left in 2011, not a loop.

I think it's referring to partial server-side renders. SSR is usually used to refer to statically rendering pages, while the "new" thing is to dynamically update pages with chunks of SSR-created HTML.

Others already answered but that's why I bothered making that little quip about HTTP. It's kind of a ridiculous name but also funny and appropriate since it's trying to state that it's a return to form. My brother who is just started working with web tech recently didn't even realize that it was possible to send HTML over HTTP, lol.

Maybe we need to invent some sort of server-side MVC framework? lol

Reply on news.ycombinator.com