3 ms·

> People were doing "SSR" with PHP on the server-side 30 years ago, and still do today (can you imagine just how much progress that platform has made, and how m

by e12e 4y ago

> People were doing "SSR" with PHP on the server-side 30 years ago, and still do today (can you imagine just how much progress that platform has made, and how much collective knowledge has been developed around it?). It's just not hip anymore, because it wasn't invented within the past 36 months. Well, kind of. The thing is that the natural progression from server side rendering/content-generation with only html and css, via Asynchronous JavaScript and XML (AJAX) to the current js-first paradigm - was a transition from hypertext document system to "movable code" (In the terms of Fielding's REST thesis)[1]. Keeping state/cache consistent works differently in the two paradigms (and they have different benefits/trade-offs). There's a real tention between "application" and "document system". And a lot of what seems insane about contemporary web dev, is when people take something that is clearly easily/well solved as a "document system" (eg: blog/homepage) - and implement it as an application (essentially writing half of a web browser in js - with custom routing/addressing and widgets). It's the reverse of the problem react et al tries to solve: writing an application using a document system (ie: a complex php app). [1] Ed: In particular "Mobile Agent" - the last section in https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_5 https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch...

indymike 4y ago
> There's a real tention between "application" and "document system". Not really. The web implements a "document as application" or "living document" model. Since the most rudimentary software is just printing static text (and static graphics) you get quite a bit of mileage with just HTML & CSS. The web scales nicely from this to fully interactive applications, and I think some of the tension you are perceiving comes from the fact it's easy to disable or override features built into to the browse, and often developers find a way to do something novel, and in doing so, break thinks like the clipboard.
- e12e 4y ago
  I think you misread my comment - obviously hypertext systems are "applications" for some definition of "application" - but there are distinct types, constraints and architectures. Mysql and php are not my first choice for creating a multi-player driving game - and even for an irc client they're not my first choice. However, for an asynchronous message board, news or mail client they might be fine.

by e12e 4y ago

indymike 4y ago

> There's a real tention between "application" and "document system". Not really. The web implements a "document as application" or "living document" model. Since the most rudimentary software is just printing static text (and static graphics) you get quite a bit of mileage with just HTML & CSS. The web scales nicely from this to fully interactive applications, and I think some of the tension you are perceiving comes from the fact it's easy to disable or override features built into to the browse, and often developers find a way to do something novel, and in doing so, break thinks like the clipboard.

e12e 4y ago
I think you misread my comment - obviously hypertext systems are "applications" for some definition of "application" - but there are distinct types, constraints and architectures. Mysql and php are not my first choice for creating a multi-player driving game - and even for an irc client they're not my first choice. However, for an asynchronous message board, news or mail client they might be fine.