Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things engineers believe about Web development

birtles.blog

Post reply on HN
Print view View original

211–220 of 254 posts

Re: Things engineers believe about Web development

#211

Post by rcxdude »

jameshart wrote: post #168
ksec wrote: post #113

Earlier quoted context omitted.

From my brief look at my log and history usage and generally my estimate, 95%, or dare I say 99% in terms of my traffic could be a MPA. Currently the only site I go regularly that are JS SPAs are Feedly, Youtube, Discourse Forums and Twitter. And apart from Twitter the others could have been MPAs and still be perfectly fine. ( Although Youtube is debatable ) I did like to think 80-90% of the web population browsing u…

"Currently the only site I go regularly that are JS SPAs are ...." Are you sure about that? Well made SPAs don't look like apps. They navigate seamlessly and instantly because they're not redownloading and parsing all their header and footer HTML, re-constructing a brand new DOM, loading and reinterpreting CSS, and bootstrapping a new Javascript runtime on every click. Look at https://react.dev/learn , click around t…

Then well-made SPAs seem to be exceptionally rare. Somehow that site lags more than opening a new page on HN. You list all the work the browser is doing and yet somehow the SPA is making it do more. I agree it makes no damn sense and yet that is the experience I have of using them.

Re: Things engineers believe about Web development

#212

Post by zelphirkalt »

ryanbrunner wrote: post #123
troupo wrote: post #120

Earlier quoted context omitted.

> Although Youtube is debatable It can definitely be an MPA. The only somewhat dynamic part it has is the comments. And now it's so egregiously bad that it's the single source of bad scores in Google's own metrics: https://twitter.com/dmitriid/status/1742669322487533801 and https://twitter.com/dmitriid/status/1742670032113402049 (yes, it loads 47KB of CSS/2.7 MB on desktop among other things)

There's the picture in picture stuff when you navigate away too. I recently did that with a MPA, and it was a not straightforward experience to get right.

Maybe such functionality is best left to the browser itself. Firefox already has the functionality to "detach" a video. Then you can scroll wherever you want and still see that video.

Re: Things engineers believe about Web development

#213

Post by zelphirkalt »

troupo wrote: post #184
ryanbrunner wrote: post #123

Earlier quoted context omitted.

There's the picture in picture stuff when you navigate away too. I recently did that with a MPA, and it was a not straightforward experience to get right.

Ah, I fogot about PIP

I still think you are not too wrong though. I usually use invidious and there are no interactive widgets, except for the video player, which I think is default HTML5 player. I rarely need anything else. And PIP can be done in Firefox with ease, without the website needing to implement anything.

Re: Things engineers believe about Web development

#214

Post by csande17 »

jameshart wrote: post #207
csande17 wrote: post #183

Earlier quoted context omitted.

If I go to react.dev/learn, click on "Escape hatches" in the menu, and scroll all the way to the bottom of the page, the browser Back button no longer works because they've added nine duplicate entries to my history. If the official React documentation website can't implement SPA page navigation properly, what chance does anyone else have?

Well that bug is clearly idiotic, and makes me feel a fool for thinking react.dev would be a strong example of sane SPA architecture to link to. The idea is sound, and the basic loading behavior is as I said (not sure what the people who are encountering 1.5 second navigation times are doing), and the existence of an implementation bug doesn't undermine the theoretical soundness of the architecture.... although, as y…

> (not sure what the people who are encountering 1.5 second navigation times are doing)

On CPU-limited devices (and my computer with 4x CPU throttling enabled in devtools), react.dev appears to block the main thread for 500-1000ms while navigating to some of the "Learn React" pages—even if all the data for that page is already cached in memory.

I remember reading all kinds of blog posts about how Concurrent Mode and Time Slicing were gonna magically solve this by breaking up long tasks and prioritizing above-the-fold content so that it would pop into view faster. It would be funny if, in addition to being unable to correctly use the History API, the React team was also unable to use their own framework's performance features.

Re: Things engineers believe about Web development

#215

Post by kurthr »

rramadass wrote: post #178
flashback2199 wrote: post #175

Earlier quoted context omitted.

We're not gobsmacked when you don't know Verilog, so I'm not sure why you think you can be gobsmacked some chip designers don't know C...

Because until that point i didn't know much about HDLs like Verilog/VHDL and how they were at a completely different level than "standard" programming languages like C/Python/etc. My then assumption was that since C was a low-level language and chip designers were working at a low-level they would be able to program in Assembly/C in their sleep and that they would be able to initiate me into the mysteries of how my C…

They probably used TCL for scripting though... it's bizarrely ubiquitous.

Re: Things engineers believe about Web development

#216

Post by csande17 »

jameshart wrote: post #208
ryanbrunner wrote: post #188

Earlier quoted context omitted.

Yes, and every major MPA framework optimizes this away, the same way that SPA approaches support server side rendering so you don't see a literal blank page before the app downloads.

"every major MPA framework optimizes this away" ... wut? Wouldn't that make them 'compile to SPA' frameworks?

I think GP is talking about solutions like https://turbo.hotwired.dev/, which just paste server-generated HTML into the page instead of passing JSON into a client-side UI framework.

Re: Things engineers believe about Web development

#217

Post by jameshart »

csande17 wrote: post #216
jameshart wrote: post #208

Earlier quoted context omitted.

"every major MPA framework optimizes this away" ... wut? Wouldn't that make them 'compile to SPA' frameworks?

I think GP is talking about solutions like https://turbo.hotwired.dev/ , which just paste server-generated HTML into the page instead of passing JSON into a client-side UI framework.

.... which is an SPA architecture.

> During rendering, Turbo Drive replaces the current element outright and merges the contents of the element. The JavaScript window and document objects, and the element, persist from one rendering to the next.

So... it makes your app into an SPA.

Re: Things engineers believe about Web development

#218

Post by 5350-uiop-1130 »

spcebar wrote: post #154
5350-uiop-1130 wrote: post #99

nothing wrong with build steps until they go wrong. then you will spend 5 hours replacing/updating deprecated/newly incompatible npm/system issues.

The horrifying guidance I've gotten a number of times when I step into a project is "downgrade your node version 5 years and never update anything."

a pragmatic solution. sometimes you don't have time and stakeholders don't understand or appreciate the side issues you need to deal with.

Re: Things engineers believe about Web development

#219

Post by rramadass »

flashback2199 wrote: post #180
rramadass wrote: post #178

Earlier quoted context omitted.

Because until that point i didn't know much about HDLs like Verilog/VHDL and how they were at a completely different level than "standard" programming languages like C/Python/etc. My then assumption was that since C was a low-level language and chip designers were working at a low-level they would be able to program in Assembly/C in their sleep and that they would be able to initiate me into the mysteries of how my C…

Ok, I guess that's fair. Having worked at one of the large chip makers, I can tell you there are plenty of people who know C and Verilog, you just weren't talking to any of them. Those who need to do, and those who don't, don't. It's certainly an industry with high degree of specialization.

So riddle me this; do those who know C & Verilog have a better idea of how the whole C->Assembly->MachineCode->Physical Processor circuitry works? I don't mean the logical model; but how exactly the program bitstream gets transformed into electrical signals by their HDL code.

Re: Things engineers believe about Web development

#220

Post by skydhash »

dstroot wrote: post #141
palata wrote: post #139

Earlier quoted context omitted.

> well what about Figma and Photoshop I, for one, don't want them rendered in my browser. I have an OS that can run apps, and I want my browser to be an app that renders simple HTML pages. If you want an app, make a damn Desktop app that can run on my OS.

Well… if you have ever supported a desktop app you know how difficult “version dispersion”, users that never update their OS, users that always update their OS, different hardware, other hostile software, etc. can be. If you know, you know.

What I remember was mostly minimum and standard requirements listed on the product pages.
Post reply on HN