4 ms·

> They can now work isomorphically, on the desktop, and on > mobile. So can plain HTML. Without any needless scripting. > We're moving past the days of th

> They can now work isomorphically, on the desktop, and on > mobile. So can plain HTML. Without any needless scripting. > We're moving past the days of the static web. We are not. Maybe you are, we can wait till you come back. > Especially, now that it's trivial to pull data from many > different sources on the client-side. HTML is even more trivial.

nqzero 11y ago
HTML (or more specifically HTML+css, and how they interact with and render in the browser) are anything but trivial. javascript (the language, not the JIT) is relatively simple in contrast client side rendering + json apis on the server are the holy grail of openness (esp with an MIT licensed client)
- falcolas 11y ago
  Building a webpage node by node from within Javascript does not lessen the complexity of HTML and CSS, it simply adds to it. You're doing the exact same things - creating DOM nodes with attributes - but with yet another level (or 5) of indirection.
  - EvanPlaice 11y ago
    The point is, generate views ONLY on the client. Excess layers of indirection come when you try do view generation on both the server and the client. Many server frameworks currently follow this approach. Generate the view scaffold using templates on the server-side. Then request partials asynchronously on the client and generate additional views client-side using a completely different framework. Shifting all of the view generation to the client frees up the back-end devs to focus all of their time/effort on the important part. Building and scaling the data infrastructure. Not to mention, shifting the view layer client-side reduces resource requirements on the back-end. The previous generation of front-end SPA frameworks frankly sucked in terms of performance, leading to a bad user experience. There were 2 primary reasons why. All data persistence/binding happened directly on the DOM, and all execution was handled on the main execution thread. The latest generation greatly improves the experience by using new techniques such as data persistence/diffing via the virtual DOM, and handling all non-rendering logic on a background worker thread.
- EvanPlaice 11y ago
  Exactly. Have fun trying to do feature detection for compatibility purposes on the server-side based on user agent strings. Because... those never lie. /s
EvanPlaice 11y ago
Yes, you can use HTML/CSS rendered views on mobile but they pale in comparison to native UIs. The latest app frameworks decouple client-side application logic from the view rendering layer. Meaning you can use the same application logic on your web app as you use on mobile EXCEPT the view on mobile will be rendered natively. Not through a hacky, slow, inconsistent embedded web view. Native native. If the approach is successful as the framework devs expect, mobile app development (and the app ecosystem as a whole) will go the way of the dinosaur. Pulling data from many sources on the server requires proxying requests to third parties and providing inline caching of the responses for performance reasons. Despite the fact that the source you're proxying to likely already implements their own caching strategies. Have fun addressing bugs caused by cache invalidations when you're dealing with multiple caching layers. Not to mention the increased memory/computation footprint incurred from hosting the equivalent of a database view of an entire third party service on your backend. Or, you could just request the data directly on the client side. That's what I mean when I say 'reduced complexity.' Unless you consider setting up CORS whitelisting and some AJAX requests to be really difficult. Then, carry on.

nqzero 11y ago

HTML (or more specifically HTML+css, and how they interact with and render in the browser) are anything but trivial. javascript (the language, not the JIT) is relatively simple in contrast client side rendering + json apis on the server are the holy grail of openness (esp with an MIT licensed client)

falcolas 11y ago
Building a webpage node by node from within Javascript does not lessen the complexity of HTML and CSS, it simply adds to it. You're doing the exact same things - creating DOM nodes with attributes - but with yet another level (or 5) of indirection.
- EvanPlaice 11y ago
  The point is, generate views ONLY on the client. Excess layers of indirection come when you try do view generation on both the server and the client. Many server frameworks currently follow this approach. Generate the view scaffold using templates on the server-side. Then request partials asynchronously on the client and generate additional views client-side using a completely different framework. Shifting all of the view generation to the client frees up the back-end devs to focus all of their time/effort on the important part. Building and scaling the data infrastructure. Not to mention, shifting the view layer client-side reduces resource requirements on the back-end. The previous generation of front-end SPA frameworks frankly sucked in terms of performance, leading to a bad user experience. There were 2 primary reasons why. All data persistence/binding happened directly on the DOM, and all execution was handled on the main execution thread. The latest generation greatly improves the experience by using new techniques such as data persistence/diffing via the virtual DOM, and handling all non-rendering logic on a background worker thread.
EvanPlaice 11y ago
Exactly. Have fun trying to do feature detection for compatibility purposes on the server-side based on user agent strings. Because... those never lie. /s

EvanPlaice 11y ago

Yes, you can use HTML/CSS rendered views on mobile but they pale in comparison to native UIs. The latest app frameworks decouple client-side application logic from the view rendering layer. Meaning you can use the same application logic on your web app as you use on mobile EXCEPT the view on mobile will be rendered natively. Not through a hacky, slow, inconsistent embedded web view. Native native. If the approach is successful as the framework devs expect, mobile app development (and the app ecosystem as a whole) will go the way of the dinosaur. Pulling data from many sources on the server requires proxying requests to third parties and providing inline caching of the responses for performance reasons. Despite the fact that the source you're proxying to likely already implements their own caching strategies. Have fun addressing bugs caused by cache invalidations when you're dealing with multiple caching layers. Not to mention the increased memory/computation footprint incurred from hosting the equivalent of a database view of an entire third party service on your backend. Or, you could just request the data directly on the client side. That's what I mean when I say 'reduced complexity.' Unless you consider setting up CORS whitelisting and some AJAX requests to be really difficult. Then, carry on.