No. Because HTML is not the future of the Web.
HTML5 can do audio and video by itself calling native video decoders in the hosts such as FFMPEG and yet people kpt choosing crawling JS players. It's idiotic.
The future (and the past) of the web is server side rendering
241–250 of 371 posts
Re: The future (and the past) of the web is server side rendering
#242If you don't do server side rendering, you don't (almost) automatically get a set of nice REST endpoints that return JSON/XML/ETC? I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties.…
This is a non-problem in all SSR projects I've ever dealt with.
Re: The future (and the past) of the web is server side rendering
#243Earlier quoted context omitted.
No? Each client may be receiving the same document, but based on their device, view port, preferences, etc… the rendered result may be different. Either way, the measurement of Joules/page is likely to be such an astronomically small number compared to the constant cost of simply having a server at all IMO.
The number of devices is very small. I’m sure you get a number of different window sizes, but within a range, you can very slightly scale.
Are you suggesting we give up on rendering layouts that respond to different window sizes, display resolutions, and zoom levels? I think what you’re suggesting is that clients requesting websites should receive essentially an image of the website with limited interactivity, but that’s not going to make anyone that’s ever used a website satisfies in C.E. 2023.
Re: The future (and the past) of the web is server side rendering
#244Earlier quoted context omitted.
That can be sorted by a single jQuery or JS function. 2-3 functions in that cart page handles everything without any complication whatsoever.
I don't understand how jQuery and direct DOM manipulation is in any way better than something like Svelte for a modern Web app, especially something like a store.
Because what most websites, ecommerce stores need per any given view/page are a few unique, isolated jQuery functions to manipulate what is strictly necessary. Be it listing a category listing of products, be it adding to cart by clicking a button, be it updating quantities in cart, address or payment.
The 'modern' frontend frameworks take way too much after frameworks like React that were born from social networks in the inception of the social network age a decade ago. Facebook needed to have people poke each other, like posts and comment under them, while at the same time incrementing like, poke counters, as well as listing and updating a crap ton of friends, page and group listings on the sidebars, notifications and inboxes at the top and in the bottom bars and a whole lot of other stuff.
So while, say, for example React solved a major problem with there not being a major templating system or logic in the front end up until then, it also brought it with the baggage of the mentality which assumes that we need that kind of dom manipulation at any given time. True, one can indeed use something like React and keep it minimal like in the shopping cart example above. But it rarely happens so and instead even the business logic starts seeping into the front end.
The time when social networks exploded and such extensive DOM manipulation became 'cool' as a result, was a time in which the frontend was stuck in between Flash and the emerging jQuery/JS mess that some preferred instead of Flash to make websites 'modern/cool'. It was 'professional' for sites and apps to interact with users back in the early internet. Flash was used for it, then it became uncool as the web moved to jQuery, JS etc. Social networks exploded right in the middle of this transition, amplifying this trend. You wanted a 'modern' website that had moving parts. Not a plain HTML + simple CSS + JS website even if it loaded fast. Every widget and form had to be active, interactive and do stuff. Facebook was !all! the rage in that period, and everyone literally imitated them in everything they do, including tech stack and practices. Then Twitter also amplified the trend. Everything added up on it, and we ended up with the frontend mess where we tend to shove everything and then complain about complexity...
Re: The future (and the past) of the web is server side rendering
#245Earlier quoted context omitted.
Getting shivers, sounds like reincarnation of Flash websites.
Still haven't replaced half the functionality of flash websites. So many flash games are gone forever.
> Still haven't replaced half the functionality of flash websites.
Nor the intuitive tools to create their behavior
Re: The future (and the past) of the web is server side rendering
#246I may be misunderstanding this, but isomorphic SSR sounds an awful lot like the Java Server Faces concept of a server side DOM that is streamed to the client. JSF was largely dropped by java developers because it ended up scaling poorly, which makes sense since it violates one of the main constraints that Roy Fielding proposed for the webs REST-ful architecture: statelessness. An alternative approach is to retain the…
What exactly do you mean with violating statelessness? Most web apps have state on the server, i.e. cookie sessions. The UI state doesn't have to be state on the server though, that can still be in memory in JS and/or part of the URL.
Re: The future (and the past) of the web is server side rendering
#247Earlier quoted context omitted.
Completely agree. For me the biggest advantage is eliminating the need to learn, debug, and maintain components on an additional frontend framework (Angular/React/Vue). I just built a rough toy project [0] that was my first time with FastAPI and HTMX and it was fun and fast. [0] https://www.truebuy.com/ (like rotten tomatoes for product reviews but just for TVs right now)
I love the concept, but for my case, I'd need more granular filters. In particular, I only buy TVs that have analog audio outputs so I can hook them up to any speakers. That's a minority of TVs these days, but there are still a few around. Finding the good ones would be useful to me.
I assume that converters have negative side effects?
Re: The future (and the past) of the web is server side rendering
#248Earlier quoted context omitted.
So now you've got two templates? How do you keep modifications in sync?
Personally I would use htmx and roundtrips for all sorts of modification including data (such as reorganizing two rows in a table). But you'd also do that in an SPA, right? How do you prevent desyncs there? Also for e.g. sorting you'd need a server roundtrip anyway in the (likely) case where you use something like pagination or lazy loading. For sending data, you would just have a reply that instructs HTMX to display…
I mean modifications to the template itself. Design changes, copy changes, etc
Re: The future (and the past) of the web is server side rendering
#249Earlier quoted context omitted.
Yes indeed! The core aspect, however, is that your server is returning fragments of html that htmx places in the DOM extremely quickly. They have pretty good examples on their site illustrating some "modern" UI patterns. As an example, you may have an HTML table on your page that you want to insert a new row for some reason on let's say a button click. You place some attributes that htmx understands on your button th…
How well does their example work over satellite internet with 1.2sec latency? How about my cell connection when T-mobile throttles me to 64Kbps for going over my data allowance? How about my sister's cell connection, as she is on an MVNO and deprioritized sometimes to 128Kbps, sometimes to 6Mbps, and sometimes it varies within a minute between those two? FFS, people, learn to write proper software that does everythin…
All of the environments you describe there sound to me like they would benefit from web apps that become responsive after an initial page load of less than 100KB, followed by ~10KB round trips to the server to fetch additional data.
As opposed to the >2MB initial page loads that have become so common with heavy React SPAs in exchange for the theoretical benefits of avoiding more page loads for further interactions.
Re: The future (and the past) of the web is server side rendering
#250I feel behind here, my company doesn't do any SSR and theres basically no way we could port it over. Definitely missing out on some key concepts.
I could build some SSR apps on my own but like, the real hard stuff about development comes >1 year in when you start running into those deep complexity issues. Can't really simulate that in a tiny pet project.