4 ms·

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

eddsh1994 4y ago
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.
- seydor 4y ago
  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.
mjfisher 4y ago
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.
- freedomben 4y ago
  Tech like LiveView (Phoenix) and LiveWire (Laravel) are great examples of this.
  - SirGiggles 4y ago
    Also Blazer Server (C#) and the upcoming Blazor United slated for .NET 8
  - mejutoco 4y ago
    And htmx for a language-agnostic one
- quechimba 4y ago
  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 https://github.com/mayu-live/framework
- 88913527 4y ago
  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.
  - gemstones 4y ago
    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?"
    - victorbjorklund 4y ago
      Like "lets use firebase"?
  - ipaddr 4y ago
    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?
    - deleted 4y ago
      [deleted]
  - bvirb 4y ago
    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.
- idsout 4y ago
  That sounds really expensive for the server.
TN1ck 4y ago
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 https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html [1] https://htmx.org/ https://htmx.org/
- hinkley 4y ago
  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.
  - replygirl 4y ago
    i wouldn't call Element.replaceWith a codification of html-over-the-wire
    - hinkley 4y ago
      Nor would I. I was talking about load(): http://api.jquery.com/load/ http://api.jquery.com/load/
chc 4y ago
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.
deleted 4y ago
[deleted]
jmkni 4y ago
Maybe we need to invent some sort of server-side MVC framework? lol
sodapopcan 4y ago
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.

eddsh1994 4y ago

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.

seydor 4y ago
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.

mjfisher 4y ago

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.

freedomben 4y ago
Tech like LiveView (Phoenix) and LiveWire (Laravel) are great examples of this.
- SirGiggles 4y ago
  Also Blazer Server (C#) and the upcoming Blazor United slated for .NET 8
- mejutoco 4y ago
  And htmx for a language-agnostic one
quechimba 4y ago
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 https://github.com/mayu-live/framework
88913527 4y ago
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.
- gemstones 4y ago
  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?"
  - victorbjorklund 4y ago
    Like "lets use firebase"?
- ipaddr 4y ago
  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?
  - deleted 4y ago
    [deleted]
- bvirb 4y ago
  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.
idsout 4y ago
That sounds really expensive for the server.

TN1ck 4y ago

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 https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html [1] https://htmx.org/ https://htmx.org/

hinkley 4y ago
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.
- replygirl 4y ago
  i wouldn't call Element.replaceWith a codification of html-over-the-wire
  - hinkley 4y ago
    Nor would I. I was talking about load(): http://api.jquery.com/load/ http://api.jquery.com/load/

chc 4y ago

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.

deleted 4y ago

[deleted]

jmkni 4y ago

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

sodapopcan 4y ago

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.