5 ms·

The big MVC frameworks are in a great position to take advantage of the move back to hypermedia as a major network model for web development. We are seeing a s

The big MVC frameworks are in a great position to take advantage of the move back to hypermedia as a major network model for web development. We are seeing a swing back to this model with modern hypermedia-oriented libraries like unpoly, hotwire and my own htmx, where javascript is used to augment the hypermedia model rather than replace it with a client-server RPC-style network model as with most SPAs. These older frameworks have been honed to a razors edge for producing hypermedia (HTML) server side and delivering it to clients efficiently. As people begin to realize just how much you can achieve with this approach (and the simplicity it brings back to web development) I expect interest in these frameworks to soar. Bullish on 2005 tech books!

nathias 5y ago
htmx loks really cool, a performance comparison vs the fastest SSR SPAs would be helpful
robertlagrant 4y ago
Did you make htmx? I love that thing.
- recursivedoubts 4y ago
  yep, glad you are finding it useful :)
  - 0des 4y ago
    I see you just about everywhere on the internet. It's nuts. Prove that you aren't a pile of ants wearing a trenchcoat.
    - robertlagrant 4y ago
      Beats half a million ants and half collapsing star.
no_wizard 4y ago
counter point: Microsoft is leading the charge with Blazor, bringing full single stacks to the front-end for the first time for non JavaScript developers. For applications its hard to see why this model wouldn't be more preferential. Most .NET applications are monolithic in nature (though you can enforce really good module separation with relatively minimal effort IME). You can look at Rust too, for its developing some Blazor-like frameworks. I could imagine for example, the next GMail being written like this, or other deeply interactive applications. I think people want to work in a singular language / framework more than anything else. One of the reasons I think JavaScript still prevails today, is it was the first language community to largely achieve this in an accessible manner. Others are now coming forward. I think pre-rendering is still the best approach to truly static content though, using web components to progressively enhance features of a page for light interactivity, this is one area they really shine. I could be very wrong though!
- robertlagrant 4y ago
  > Blazor-like Isn't that just "GWT-like"?
  - no_wizard 4y ago
    Blazor relies on dynamically generated JS Bridges and WASM, where as GWT just generated JavaScript from Java Bindings. Seems similar on the surface, however the difference being that Blazor is trying to leverage direct compilation of C# constructs directly to WASM whenever possible, and supplementing that with some JavaScript interop, as opposed to trans-piling things directly to JS itself, as with GWT.
    - robertlagrant 4y ago
      That makes sense. But it doesn't seem a very significant difference on the face of it. More modern implementation of same idea?
      - no_wizard 4y ago
ravenstine 4y ago
To be frank, I don't really see this swing back. Maybe it's hip right now on HN to scoff at SPAs and fetishize server-rendered webpages. Having used NoScript with temporary allowances, it's glaringly obvious how much of the web doesn't show anything without JS enabled. If there's a trend to not make everything render on the client, I'm not noticing it. Even if there is, we may ultimately end back in the same place we were in say 2011 (or ~2014 depending on how you look at it). We could very well end up back in dumping grounds of abstraction spaghetti bad object-orientation. The weakness of backend MVC frameworks is that it's way too easy to munge business logic with the view. Yeah, Model-View-Controller suggests a separation of those concerns, but now it's up to the human to follow that convention and... yeah... SPAs can be just as bad in a lot of ways, but at least they are more suited to dealing with view logic and not so much of the data transaction stuff behind the scenes. Personally, I often find frontend JavaScript projects easier to figure out, and I think that my be due to MVC being a flawed concept. It might be okay for hammering out a prototype, but in the long term so many things need to happen in order to keep it intact; Rails introduced concepts like "concerns" exactly for this purpose, because an MVC structure in a pure OO language like Ruby is very rigid. Server frameworks should do themselves a favor and divorce themselves from ideas like MVC and find ways to create structure in ways that aren't merely meant to scratch the itch of design-pattern enthusiasts. I find it dubious that a concept of a "model" is even necessary as a thing to always think about; it's a weird implementation detail that's treated as if it's a design pattern. And when you're left with just the View-Controller part, it's dubious why they even need a formalized concept in the first place.
- collyw 4y ago
  I have found that all the SPA apps I have inherited (current one particularly) have way too much logic in the frontend. People complain about Django's template language being limited, but that encourages you to keep that stuff for display only.
  - andrewstuart2 4y ago
    "Way too much logic in the frontend" is entirely objective, and honestly doesn't hold much water, unless you're talking security where the logic is not mirrored in the backend. Any time performance and responsiveness matter, across the engineering board, client-side logic wins. The times that integrity matters, you still apply the logic client side and also on the server side. See the amazing Source Multiplayer Networking article for more info on where I'm coming from with respect to ultra high performance but validated architecture. https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_...
jmt_ 4y ago
For those that have integrated something like htmx/server side rendered HTML over an API into existing JSON-oriented APIs - what's the cleanest way you've found to have both formats exist together? Not that every existing API call would need to include an HTML output, but for many projects I could see there being many endpoints that would also make sense to output HTML and wouldn't deserve an entirely different API. My first thought was to add a format/output parameter to specify the format. In that case of HTML output, you could possibly use the JSON that would normally be rendered and insert it into a jinj2 template for example.
- riwsky 4y ago
  https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

nathias 5y ago

htmx loks really cool, a performance comparison vs the fastest SSR SPAs would be helpful

robertlagrant 4y ago

Did you make htmx? I love that thing.

recursivedoubts 4y ago
yep, glad you are finding it useful :)
- 0des 4y ago
  I see you just about everywhere on the internet. It's nuts. Prove that you aren't a pile of ants wearing a trenchcoat.
  - robertlagrant 4y ago
    Beats half a million ants and half collapsing star.

no_wizard 4y ago

counter point: Microsoft is leading the charge with Blazor, bringing full single stacks to the front-end for the first time for non JavaScript developers. For applications its hard to see why this model wouldn't be more preferential. Most .NET applications are monolithic in nature (though you can enforce really good module separation with relatively minimal effort IME). You can look at Rust too, for its developing some Blazor-like frameworks. I could imagine for example, the next GMail being written like this, or other deeply interactive applications. I think people want to work in a singular language / framework more than anything else. One of the reasons I think JavaScript still prevails today, is it was the first language community to largely achieve this in an accessible manner. Others are now coming forward. I think pre-rendering is still the best approach to truly static content though, using web components to progressively enhance features of a page for light interactivity, this is one area they really shine. I could be very wrong though!

robertlagrant 4y ago
> Blazor-like Isn't that just "GWT-like"?
- no_wizard 4y ago
  Blazor relies on dynamically generated JS Bridges and WASM, where as GWT just generated JavaScript from Java Bindings. Seems similar on the surface, however the difference being that Blazor is trying to leverage direct compilation of C# constructs directly to WASM whenever possible, and supplementing that with some JavaScript interop, as opposed to trans-piling things directly to JS itself, as with GWT.
  - robertlagrant 4y ago
    That makes sense. But it doesn't seem a very significant difference on the face of it. More modern implementation of same idea?
    - no_wizard 4y ago

ravenstine 4y ago

To be frank, I don't really see this swing back. Maybe it's hip right now on HN to scoff at SPAs and fetishize server-rendered webpages. Having used NoScript with temporary allowances, it's glaringly obvious how much of the web doesn't show anything without JS enabled. If there's a trend to not make everything render on the client, I'm not noticing it. Even if there is, we may ultimately end back in the same place we were in say 2011 (or ~2014 depending on how you look at it). We could very well end up back in dumping grounds of abstraction spaghetti bad object-orientation. The weakness of backend MVC frameworks is that it's way too easy to munge business logic with the view. Yeah, Model-View-Controller suggests a separation of those concerns, but now it's up to the human to follow that convention and... yeah... SPAs can be just as bad in a lot of ways, but at least they are more suited to dealing with view logic and not so much of the data transaction stuff behind the scenes. Personally, I often find frontend JavaScript projects easier to figure out, and I think that my be due to MVC being a flawed concept. It might be okay for hammering out a prototype, but in the long term so many things need to happen in order to keep it intact; Rails introduced concepts like "concerns" exactly for this purpose, because an MVC structure in a pure OO language like Ruby is very rigid. Server frameworks should do themselves a favor and divorce themselves from ideas like MVC and find ways to create structure in ways that aren't merely meant to scratch the itch of design-pattern enthusiasts. I find it dubious that a concept of a "model" is even necessary as a thing to always think about; it's a weird implementation detail that's treated as if it's a design pattern. And when you're left with just the View-Controller part, it's dubious why they even need a formalized concept in the first place.

collyw 4y ago
I have found that all the SPA apps I have inherited (current one particularly) have way too much logic in the frontend. People complain about Django's template language being limited, but that encourages you to keep that stuff for display only.
- andrewstuart2 4y ago
  "Way too much logic in the frontend" is entirely objective, and honestly doesn't hold much water, unless you're talking security where the logic is not mirrored in the backend. Any time performance and responsiveness matter, across the engineering board, client-side logic wins. The times that integrity matters, you still apply the logic client side and also on the server side. See the amazing Source Multiplayer Networking article for more info on where I'm coming from with respect to ultra high performance but validated architecture. https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_...

jmt_ 4y ago

For those that have integrated something like htmx/server side rendered HTML over an API into existing JSON-oriented APIs - what's the cleanest way you've found to have both formats exist together? Not that every existing API call would need to include an HTML output, but for many projects I could see there being many endpoints that would also make sense to output HTML and wouldn't deserve an entirely different API. My first thought was to add a format/output parameter to specify the format. In that case of HTML output, you could possibly use the JSON that would normally be rendered and insert it into a jinj2 template for example.

riwsky 4y ago
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...