4 ms·

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

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.
  - 4y ago
idsout 4y ago
That sounds really expensive for the server.

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

idsout 4y ago

That sounds really expensive for the server.