Burn it all down. Just stop using JavaScript.
Good luck using even a barebones site like HN without JavaScript.
HN works fine without JS!
That being said, the third-party search service it uses does not.
JavaScript hydration is a workaround, not a solution
171–180 of 239 posts
Re: JavaScript hydration is a workaround, not a solution
#172...get a PageSpeed score of 100/100 I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented this week) is what drives a lot of the complexity in web app dev. People refuse to throw out what they've learned, so every time there's a new metric to chase in case you lose SERPS ranking for being slow! devs heap another layer of complexity on to the Webpack bo…
And what do you do for more complex, stateful apps? I don't think it's fair to dismiss this problem as "just use HTML and CSS and a sprinkling of vanilla JS". What happens when you need to build anything more complex than a basic form? A dashboard, or web map, or Figma, or Slack, or Gmail, or Gsheets... everything from state to AJAX (and other async) to persistence to URL routing, etc. becomes insanely complex. I fee…
The examples you give are a 100% fit for the SPA model. Nobody would build Google Docs or a game from server-side HTML.
That's not the discussion. The discussion is everything except that. The typical example being a CRUD app. A bunch of cards, filters on the left, search box on top, logged in user. It usually isn't much more than that. Which means its low state and lowly interactive.
Re: JavaScript hydration is a workaround, not a solution
#173Earlier quoted context omitted.
> For example, say you wanted a checkbox, but you wanted to use a custom color instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this e…
"Just compromise your design", surprisingly, isn't a one size fits all solution. Especially when you can implement things yourself. Yes, it's harder than you think, but sometimes it needs to be done.
No, your designer sucks.
Don't reinvent well known controls. Stop doing it. You can give it a border color and an accent color (check out the new accent-color CSS property) and for the rest you leave it alone.
Re: JavaScript hydration is a workaround, not a solution
#174Earlier quoted context omitted.
You can do this directly in the browser* without JS—in exactly the way shown by the example I just gave: by using a browser that is capable of editing and sharing docs (directly). * If someone really wanted to be a stickler, they could point out that that you've set up Google Docs to fail your own rubric, since it involves indirect editing. The browser itself has no direct role in the editing process. It only manages…
So your solution is to write a browser so you don't have to write JS? Supposing I just want to create an internal tool that allows me to collaborate in realtime with my colleagues on a document (multiple cursors, everyone editing at once) and I have to do it in an existing browser because I don't write C++ and only have a few weeks to deliver - how would I do this without JS? Also, it needs to work on Android, iOS, W…
> So your solution is to write a browser
First, you're moving the goal posts...
> so you don't have to write JS
... and attacking a strawman. (No, I'm not worried that I might "have" to write JS. I've written a lot of JS. And I put a lot of effort making sure there was high quality documentation about the language in the early days of developer.mozilla.org—so that other people could have a nice time when they write JS.)
Secondly, you are aware—I'm certain of it—that the company behind Google Docs actually does have a browser.
Re: JavaScript hydration is a workaround, not a solution
#175I'm not sure if this is reflective of a normal Qwik project, but in the TODO app, javascript fragments are not even downloaded until the event fires, which adds a very noticeable latency.
e.g: on first click (to check off a TODO item), my browser went and fetched q-6642ef59.js, which has the below contents and in turn caused the fetch of two other javascript fragments, which in turn caused a fetch of two more.
import{d as o}from"./q-dd8cb722.js";import{t}from"./q-3d9b01e7.js";const s=o((({item:o,todos:s})=>t(s,o)));export{s as Item_onRender_on_click};
Perhaps judicious use of preloading javascript and/or CSS animations could hide this from a user, but it seems icky, especially if you're targeting mobile with much higher latencies.
Re: JavaScript hydration is a workaround, not a solution
#176Earlier quoted context omitted.
Speed and uptime are also features. If customers like speed/uptime (they do) we need to make sure management prioritizes them and understands how certain features will work against speed/uptime.
been a juggling act for me for some time, and always comes down to - they'd rather take a performance hit vs. harm the branding/interactivity. tho we're in a very niche market that doesn't seem to mind (i do my best to make it as efficient as can be)
This.
We have a very slow eshop, worst than any competitor, yet the priority is always new features that will make the life of users even worse.
Re: JavaScript hydration is a workaround, not a solution
#177...get a PageSpeed score of 100/100 I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented this week) is what drives a lot of the complexity in web app dev. People refuse to throw out what they've learned, so every time there's a new metric to chase in case you lose SERPS ranking for being slow! devs heap another layer of complexity on to the Webpack bo…
And what do you do for more complex, stateful apps? I don't think it's fair to dismiss this problem as "just use HTML and CSS and a sprinkling of vanilla JS". What happens when you need to build anything more complex than a basic form? A dashboard, or web map, or Figma, or Slack, or Gmail, or Gsheets... everything from state to AJAX (and other async) to persistence to URL routing, etc. becomes insanely complex. I fee…
> Having a "build and bundle" step is just the webdev version of compiling developer-friendly code (React and frameworks) into the "lowest common denominator" code of browser-parseable HTML + JS.
One problem is that for all the building and bundling webdevs do, only a few very recent frameworks (Svelte and SolidJS) can even manage to compile into something that even approximates "plain vanilla", progressively-enhanced JS on the client. And use of these is still the exception rather than the rule.
Re: JavaScript hydration is a workaround, not a solution
#178I've been trying to stay away from doing public facing web apps for a decade, so, from my point of view, hydration doesn't make any sense. Authorization is in the browser, meaning I get to serve the login page "real fast". That said, I get the reasons people do it, but frankly, it doesn't sit well with me. It's guaranteed that the whole process is unreasonably complicated as opposed to serving a few static files that…
You can still cache ssr websites and render them only once.
Re: JavaScript hydration is a workaround, not a solution
#179Of all the terms in tech "hydration" makes me cringe the most.
Any idea what the origin of the term is? And why "progressive hydration" was needed over the pre-existing term "progressive enhancement"? I can't figure out what's different about "progressive hydration" that the old term didn't cover.
Re: JavaScript hydration is a workaround, not a solution
#180Earlier quoted context omitted.
"Just compromise your design", surprisingly, isn't a one size fits all solution. Especially when you can implement things yourself. Yes, it's harder than you think, but sometimes it needs to be done.
It is for things like checkboxes. If your design requires checkboxes to be special and different from everyone else's checkboxes, your design is wrong .
Everyone else’s checkboxes aren’t all the same though.