6 ms·

Prediction: the big move in the next few years is going to be "back to hypermedia" People are realizing that you can accomplish quite a bit more with hypermedi

Prediction: the big move in the next few years is going to be "back to hypermedia" People are realizing that you can accomplish quite a bit more with hypermedia than you could in the past, and that the complexity of javascript stacks isn't worth it in many cases. Older, mature hypermedia-based technologies like rails, django, and even PHP, will experience a resurgence and a lot of older lessons and techniques in web development (caching, SQL tuning, etc.) will be rediscovered. I have a dog in this fight, w/ htmx, but I think we are increasingly seeing evidence for this move.

stevefan1999 5y ago
It already happened with SSR
allendoerfer 5y ago
We might see a combination of both. The biggest CMS of one of the biggest languages is moving away from the approach you call hypermedia by implementing a JS-based editor and REST apis. Effectively they are building a headless version on top of their legacy platform, which can be used like a JavaScript stack. This can be used as an argument for the hypermedia approach: "Let's just use this thing for now, we can always implement our SPA inside it later, if we need to."
- recursivedoubts 5y ago
  I think that's a trailing indicator, a reaction by Wordpress to the current "right way" to build web software.
- gwright 5y ago
  > The biggest CMS of one of the biggest languages Which CMS is this?
  - ankit70 5y ago
    WordPress
- ethanpil 5y ago
  I don't think this transition has been very well received by the WordPress community...
coldtea 5y ago
>Older, mature hypermedia-based technologies like rails, django, and even PHP Not sure what you refer to as hypermedia. In the first part of your comment I assumed something like a new version of Flash. Here you seem to simply imply http/hypertext. But then again, those technologies where never lost (to need to be rediscovered). They're as popular as ever, people just add more stuff on top, at the client JS layer.
- regularfry 5y ago
  Anywhere you see graphql, you see someone who's rejected hypermedia.
  - coldtea 5y ago
    Not sure I follow. GraphQL is a way to ask for data from the backend. What does it have to do with the client layer?
    - regularfry 5y ago
      It's generally used as a replacement for REST, which, if done properly, uses hypermedia.
CuriouslyC 5y ago
If we see a return to "hypermedia" it won't be wholesale, but rather in the form of a static site generator that does the 80% work and is easy to extend the rest of the way. Something somewhere between Svelte and Gatsby. The react component model and JSX style bracketed DSLs both have a lot of traction, the main issue is the amount of groundwork and glue needed to do simple things with them.
- recursivedoubts 5y ago
  i don't agree at all i think it will rather be in non-javascript technologies with strong existing hypermedia infrastructure again, like rails, django, etc the front-end component model is anti-RESTful and is really a mechanism for handling the complexity of the current client-server approach, it becomes significantly less important as hypermedia is re-embraced
  - CuriouslyC 5y ago
    I think RESTful APIs will die before component based interfaces do. Component based UI has been a thing for like 30 years outside the web dev space, and GraphQL/post-based RPC APIs solve a lot of problems and can be derived cleanly from a database schema or functional modules. Hypermedia also doesn't play well with offline-capable applications, which limits its use cases.
    - recursivedoubts 5y ago
      the component problem, in as much as it is one that can't be dealt with via just standard template includes, can be solved server side and offline-capable isn't a huge percentage of web apps we just disagree, the future will tell us who's right
      - BuckRogers 5y ago
        I think you’re both wrong and the future belongs to platforms that compile to web assembly.
qudat 5y ago
The react team are developing "server components" that will bring the js ecosystem even closer to your prediction.
tosihakkeri 5y ago
I think requirements have generally shifted quite bit from what plain html can do, if that's what you mean with "hypermedia". Though true, there's probably a growing understanding that one doesn't need React on every website. So maybe it'll rather be more refined understanding of when to use certain technologies.
- recursivedoubts 5y ago
  https://htmx.org/examples/ https://htmx.org/examples/
  - tosihakkeri 5y ago
    Certainly interesting but I fail to understand what's the big benefit? Also I would be afraid to have some corner cases that would need to be covered with JS, and that could get really ugly.
    - recursivedoubts 5y ago
      the big benefits are the simplicity of the model and returning to the hypermedia network architecture (with its attendant benefits) don't worry! If you need to kick out to some front end scripting we have a solution for that as well: https://hyperscript.org https://hyperscript.org So no ugly javascript! ;)
smm11 5y ago
Exactly. This "stuff" is maturing, and a lot of people realize we've been headed the wrong direction for a long time. At some point, stuff needs to be maintained. You can still start and drive that 1967 car, after all.
zerocount 5y ago
Hypermedia is just the addition of graphics, sound, etc... to your web page. I don't understand the context you're using it in here.

stevefan1999 5y ago

It already happened with SSR

allendoerfer 5y ago

We might see a combination of both. The biggest CMS of one of the biggest languages is moving away from the approach you call hypermedia by implementing a JS-based editor and REST apis. Effectively they are building a headless version on top of their legacy platform, which can be used like a JavaScript stack. This can be used as an argument for the hypermedia approach: "Let's just use this thing for now, we can always implement our SPA inside it later, if we need to."

recursivedoubts 5y ago
I think that's a trailing indicator, a reaction by Wordpress to the current "right way" to build web software.
gwright 5y ago
> The biggest CMS of one of the biggest languages Which CMS is this?
- ankit70 5y ago
  WordPress
ethanpil 5y ago
I don't think this transition has been very well received by the WordPress community...

coldtea 5y ago

>Older, mature hypermedia-based technologies like rails, django, and even PHP Not sure what you refer to as hypermedia. In the first part of your comment I assumed something like a new version of Flash. Here you seem to simply imply http/hypertext. But then again, those technologies where never lost (to need to be rediscovered). They're as popular as ever, people just add more stuff on top, at the client JS layer.

regularfry 5y ago
Anywhere you see graphql, you see someone who's rejected hypermedia.
- coldtea 5y ago
  Not sure I follow. GraphQL is a way to ask for data from the backend. What does it have to do with the client layer?
  - regularfry 5y ago
    It's generally used as a replacement for REST, which, if done properly, uses hypermedia.

CuriouslyC 5y ago

If we see a return to "hypermedia" it won't be wholesale, but rather in the form of a static site generator that does the 80% work and is easy to extend the rest of the way. Something somewhere between Svelte and Gatsby. The react component model and JSX style bracketed DSLs both have a lot of traction, the main issue is the amount of groundwork and glue needed to do simple things with them.

recursivedoubts 5y ago
i don't agree at all i think it will rather be in non-javascript technologies with strong existing hypermedia infrastructure again, like rails, django, etc the front-end component model is anti-RESTful and is really a mechanism for handling the complexity of the current client-server approach, it becomes significantly less important as hypermedia is re-embraced
- CuriouslyC 5y ago
  I think RESTful APIs will die before component based interfaces do. Component based UI has been a thing for like 30 years outside the web dev space, and GraphQL/post-based RPC APIs solve a lot of problems and can be derived cleanly from a database schema or functional modules. Hypermedia also doesn't play well with offline-capable applications, which limits its use cases.
  - recursivedoubts 5y ago
    the component problem, in as much as it is one that can't be dealt with via just standard template includes, can be solved server side and offline-capable isn't a huge percentage of web apps we just disagree, the future will tell us who's right
    - BuckRogers 5y ago
      I think you’re both wrong and the future belongs to platforms that compile to web assembly.

qudat 5y ago

The react team are developing "server components" that will bring the js ecosystem even closer to your prediction.

tosihakkeri 5y ago

I think requirements have generally shifted quite bit from what plain html can do, if that's what you mean with "hypermedia". Though true, there's probably a growing understanding that one doesn't need React on every website. So maybe it'll rather be more refined understanding of when to use certain technologies.

recursivedoubts 5y ago
https://htmx.org/examples/ https://htmx.org/examples/
- tosihakkeri 5y ago
  Certainly interesting but I fail to understand what's the big benefit? Also I would be afraid to have some corner cases that would need to be covered with JS, and that could get really ugly.
  - recursivedoubts 5y ago
    the big benefits are the simplicity of the model and returning to the hypermedia network architecture (with its attendant benefits) don't worry! If you need to kick out to some front end scripting we have a solution for that as well: https://hyperscript.org https://hyperscript.org So no ugly javascript! ;)

smm11 5y ago

Exactly. This "stuff" is maturing, and a lot of people realize we've been headed the wrong direction for a long time. At some point, stuff needs to be maintained. You can still start and drive that 1967 car, after all.

zerocount 5y ago

Hypermedia is just the addition of graphics, sound, etc... to your web page. I don't understand the context you're using it in here.