Browsers are pretty good at loading pages • Hacker News Board

Re: Browsers are pretty good at loading pages

#321

Post by ryacko » Tue, Jul 23, 2019, 1:00 AM UTC

kowdermeister wrote: post #91

ryacko wrote: post #72

Earlier quoted context omitted.

CSS doesn’t require javascript, and allows for nearly all the features of a SPA.

Like plotting an equation to canvas? Editing video? Handling drag and drop events? I've seen that blog post where a guy demonstrated that many UI elements can be done with CSS, I like that. I try to do that myself as much as I can, but let's not pretend that CSS is a programming language and it can replace ANY JavaScript.

It is debatable that CSS is or isn’t Turing complete, but as long as the task isn’t totally automated without user input, CSS could replace most Javascript.

Re: Browsers are pretty good at loading pages

#322

Post by manigandham » Tue, Jul 23, 2019, 1:21 AM UTC

gray_-_wolf wrote: post #313

manigandham wrote: post #231

Earlier quoted context omitted.

Yes, Chrome uses V8 which has Isolates (also used by some FaaS platforms like Cloudflare Workers), and adds more optimizations on top like disk-based caching to share across processes. The script is keyed from a hash of its contents. https://v8.dev/blog/code-caching-for-devs

How can the download step be skipped then if you are using the hash of the content as a key??

That's what HTTP caching is. Browsers use headers and heuristics.

Re: Browsers are pretty good at loading pages

#323

Post by buzzert » Tue, Jul 23, 2019, 3:14 AM UTC

lnl wrote: post #308

bzbarsky wrote: post #295

Earlier quoted context omitted.

Note that some browsers are planning to start doing lazy image loading themselves. See https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...

As another lazy loading hater, I think that's a good thing. If a website wants to use lazy loading, it should be handled by the browser, rather than using a custom JavaScript code that the webpage requests. There being one universal method means that there is only one setting that I need to disable to avoid lazy loading. Currently I use a userscript based on heuristics to load all lazy-loading images, but it often do…

> Currently I use a userscript based on heuristics to load all lazy-loading images, but it often doesn't work, as websites use a wide variety of methods to implement it.

Would you mind sharing this script? I use NoScript heavily and something would certainly be better than nothing in a lot of cases.

Re: Browsers are pretty good at loading pages

#324

Post by lnl » Tue, Jul 23, 2019, 7:49 AM UTC

buzzert wrote: post #323

lnl wrote: post #308

Earlier quoted context omitted.

As another lazy loading hater, I think that's a good thing. If a website wants to use lazy loading, it should be handled by the browser, rather than using a custom JavaScript code that the webpage requests. There being one universal method means that there is only one setting that I need to disable to avoid lazy loading. Currently I use a userscript based on heuristics to load all lazy-loading images, but it often do…

> Currently I use a userscript based on heuristics to load all lazy-loading images, but it often doesn't work, as websites use a wide variety of methods to implement it. Would you mind sharing this script? I use NoScript heavily and something would certainly be better than nothing in a lot of cases.

Mine was based on the answer here[1], now I see that the script in the answer was edited after I started using it. I should try the new version to see if it works better.

My experience with the previous version was that while it sometimes worked, on some websites it broke more than it fixed; and when I modified the script to account for that issue, it broke something somewhere else, as websites use very different methods to display images that I couldn't imagine (hence I welcome a standard way of doing it). So I ended up using the script on a whitelist basis instead. Maybe the new version works more properly, so that I can enable it globally again.

[1] https://superuser.com/questions/938345/load-all-images-even-...

Re: Browsers are pretty good at loading pages

#325

Post by barbarbar » Tue, Jul 23, 2019, 9:37 AM UTC

Have just read this article again. The author has a very pleasant style of writing. Very good explanations and good reasoning in the conclusion. What could also be mentioned is the sideeffect from having n different proprietary "Routers" from different framework vendors as well as "code-splitting" and so on.

Re: Browsers are pretty good at loading pages

#326

Post by bzbarsky » Tue, Jul 23, 2019, 1:15 PM UTC

lnl wrote: post #317

bzbarsky wrote: post #310

Earlier quoted context omitted.

The NoScript point is a good one. I don't necessarily expect browsers that implement it to have a user-visible way to disable lazy loading, though, so you may be out of luck there. You _might_ be able to create userscripts that force non-lazy loading on all potentially-lazy elements by using the opt-out frob browsers would add for websites.

I would hope that Firefox would have an about:config setting to disable it, but with the direction they are going, removing customizability left and right, who knows. Normally I would have also expected addons to disable this browser-side lazy loading, but since Firefox 57 they are more like glorified userscripts, so they probably wouldn't be able to. On Chromium side, maybe Vivaldi and the like could provide the opt…

Firefox does not have plans to implement lazy loading at this time, fwiw. If we do, yes, I expect we will have a way to disable it.

Re: Browsers are pretty good at loading pages

#327

Post by syllable_studio » Tue, Jul 23, 2019, 1:37 PM UTC

Page load speed is not the only reason why client-side rendering is important. When traditional server-side rendered pages need to update state on the page they have two choices: Use DOM manipulation or reload the entire page from the back-end just to update one small piece of the page. The more state that needs updating, the more complex it becomes to manage rendering on both the server and the client. Code redundancies creep in as html templates are duplicated on both sides.

In my experience, as soon as a website has any app-like qualities at all, a tool like react just makes sense. It's a great tool that solves a very real problem. I always use universal rendering so that you get the best of both worlds and the page still renders fine for the no-js folks out there (respect).

Re: Browsers are pretty good at loading pages

#328

Post by rellekio » Tue, Jul 23, 2019, 10:34 PM UTC

peteforde wrote: post #247

rellekio wrote: post #120

Earlier quoted context omitted.

Reduces server costs. Able to process data on client, including mathematical computation via We ebAssembley. Which in effect allows you to create "Web Apps," rather than just a news site, blog, ecommerce, etc... figma.com is an excellent example. Not to mention that SPA have been used for video game UI. Rather than building that system from the ground up. If your client's needs are to just display a static and do not…

Honestly, what do you think we did before the Facebook gods deigned to grace us with React? You understand that we didn't need SPAs to build everything, right? Most of what's gotten better on the web has been about standardization and drastic improvements to EcmaScript. Unfortunately, we've taken all of these new toys and made sites that load slower, on average, on today's phones than typical sites did in 2009. The p…

I use Angular and Svelte professionally. Reactive to me is reactive programming via the rx package that spans many languages. However I only use those frameworks if the job calls for it.

Call me a blending edge buff, but once WebGPU rolls out you can blur the distinction of web site and native program. But I would not utilize such on statically rendered website. But I would use it on a portable version of Photoshop, Blender, AutoCAD, or Minecraft.

Can you do the above today, inefficiently yes. But once WebGPU (gpu multi processing via a compute shaders with shared instructions) hits in combination with WebAssembley Workers (shared instruction cpu processing with proper floats across X cores) it will be an entirely different story.

What is insane to me is that these UI frameworks run in combination with the DOM on the main thread. That they are not designed from the ground up to run SSR and it is an afterthought.

Or in the instance of third world can even be managed by a Service Worker that drip feeds updates and presents th em on the site they are on next time they visit.

1 million and one ways to skin a cat. No way is better, it depends on the client's budget and use case.