3 ms·
This seems reductive to me. There's "HTML" and then there's the kind of website where the final DOM isn't known until the user has already been attempting to r
by bob1029 3y ago
This seems reductive to me.
There's "HTML" and then there's the kind of website where the final DOM isn't known until the user has already been attempting to read it for 10 seconds. There is a substantial difference in the % of browser capabilities that need to be exercised between the extremes of use.
Complexity of implementation is what ultimately separates the good from the bad. Any tool can be operated skillfully or poorly. An apprentice with a circular saw and a fully charged battery can do a hell of a lot of damage. A master may elect to use no tool at all and simply bang on the side of the thing (I.e. push back on the business).
The latest websites I have built are some of my most compatible ever. I don't use web sockets anymore. I don't depend on JavaScript to have piecemeal conversation with the server. You can actually use ~80% of the product with JavaScript entirely disabled. How are the engineering choices demonstrated here not exactly the solution for walled garden lock-in?
- feitingen 3y agoLots of websites already present a machine friendly site to google-bot and some other spiders. I don't see why they can't offer the same to other bots and only serve the Javascript-heavy pages to humans.
- MrDresden 3y agoThe point is that a lot can be done without the need for Javascript. Also in pages served to humans.
- flagrant_taco 3y agoThe idea of maintaining two entirely different versions of the same side gives me flashbacks to the days when they sir had a separate "m." codebase for mobile. There's a reason we found better solutions there, building and maintaining the same site twice is almost never worth it.
- oneeyedpigeon 3y agoThis is why you wouldn't build "two entirely different versions of the same site", you'd build one version and toggle the <script> tag on and off.
- flagrant_taco 3y agoThat may not work for a lot of sites that depend on client rendering and don't server-render the full page content Its really easy for this to break and go unnoticed for a while as well. You could run tests against the static version, but I wouldn't be surprised at all to see them "temporarily" disabled because a new feature needs to go live and something is the breaking in the static tests
- oneeyedpigeon 3y agoSure; I guess it depends if we're talking about a web site or a web app.
- bob1029 3y ago> That may not work for a lot of sites that depend on client rendering Products that depend on client-side rendering don't deserve to have regression-free experiences. You are literally doing layout with javascript and wondering why things get funny on edge case clients. The web is fucked until it becomes truly popular to build vanilla, SSR applications again. I feel like we are almost at the end of the tunnel of client-side hell, but perhaps some aggressive final pushes could help ship the narrative. The server is fast. Stop doing your layout on the client. Use media queries to address the wide range of viewport dimensions. You can have a responsive website, installable as a PWA on home screen of any mobile device and also as a 4k detailed desktop layout with 0 lines of JS required. All you have to do is stop outsourcing your independence to framework vendors and pick up the MDN bible.
- sublinear 3y agoThis sounds regressive and the battle has been over for almost a decade now. Server-side rendering is silly and client-side rendering should not be used for the entire page. Even for complex web apps, the majority of the HTML is static. The best web experiences are static HTML with client-side rendering only used for the dynamic sections of the page. It's not even a choice to do it any other way anymore if you care about a11y and SEO.
- _jal 3y agoI don't see why they can't offer the same to humans, at least as an option. There are a few sites I impersonate Googlebot to, they're much more usable that way.