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

191–200 of 254 posts

Re: Things engineers believe about Web development

#191

Post by mardifoufs »

bombela wrote: post #186
jameshart wrote: post #168

Earlier quoted context omitted.

"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…

https://react.dev/learn is so slow on my phone, it takes 1.5s to open the burger menu, and about 1s to jump to a section. (Google pixel 5a). It must be some SPA that loads the whole documentation all at once I presume. A traditional MPA would probably work much better here. edit: and like the sibling comment noted, the history back button gets messed up. edit2: I mistakingly wrote nexus 5a instead of pixel 5a

Do you mean the pixel 5a? Just wondering because it would make a big difference if it was nexus 5 from 10 years ago, versus a much more recent pixel 5!

Re: Things engineers believe about Web development

#192

Post by mardifoufs »

traverseda wrote: post #21
ryanbrunner wrote: post #6

The refrain against the "we should go back to MPA apps with server rendered HTML" is often "well what about Figma and Photoshop", which of course, yes those don't really work in the MPA, server rendered HTML model. The problem isn't so much those but how most developers lump themselves in with the incredibly interactive sites because it sounds sexier and cooler to work on something complex than something simple. The…

For stuff like figma and photoshop I can't help but suspect that the creators would be better of writing their program in CPP with the GUI toolkit of their choice, and compiling it for the web with emscripten.

Why? If there's one thing JavaScript and browser tech is good at, it's making GUI dev easier. Just look at how even Qt is basically pivoting completely towards QML which to my naive eyes look very very similar to how GUI/Layouts/styling is done with html5/Js. Why would you purposefully use something worse just to not use browser related tech? I would agree if this was about raw number crunching, where compiling to wasm makes sense and where a html5 GUI can be used as a frontend, but the GUI itself has no reason to be built with CPP.

Re: Things engineers believe about Web development

#193

Post by kgdiem »

jwells89 wrote: post #149
kgdiem wrote: post #132

Earlier quoted context omitted.

> you should strive to make solutions that require the simplest tools possible whenever you can I’ve gone back to making MPA apps with minimal JS. It helps me actually ship my projects rather than tinkering and having an over complicated setup for mostly CRUD tasks. In one project that is a bit more data intensive and interactive I’m using Laravel Breeze / Laravel + inertajs (SSR react pages). I’m also a big fan of J…

A big factor in that “tinkeriness” of SPAs is how nearly every part of making an SPA well-behaved and pleasant to use falls almost entirely on the shoulders of the developer. Due to how little browsers provide on that front, well-behaved polished SPAs are very much not on the happy path or default. Even if you use the big popular libraries, special care must be taken to not build a product that’s a frustrating mess f…

Yes, can’t argue with that. Making apps for iOS and usually Android is often way more pleasant.

Have you seen any serious proposals on this front?

Re: Things engineers believe about Web development

#194

Post by ryanbrunner »

endisneigh wrote: post #106
ryanbrunner wrote: post #92

Earlier quoted context omitted.

- Hammer, screwdriver, who cares, fix it. - Scalpel, forceps, who cares, do surgery. - Reinforced concrete, 2x4s, who cares, build a bridge. No, pretty much every profession that uses tools cares about using the correct tools for the job.

Yea, tools and processes they’ve decided on decades ago. You don’t see these people writing blog posts about new tools and wasting time evaluating them yearly like in tech. If there’s an actual issue like there was with deaths in the medical profession due to not washing hands, then they evaluate.

1. There probably is quite a bit of discussion about tool selection in some fields. Surgical innovations didn't end with the invention of the scalpel. I'm sure there's lots of discussion about the appropriate use cases for robotic vs laprascopic vs traditional surgery, we just don't see them because we're on a tech forum and not where medical doctors discuss tools. I can say for a fact that I've seen more written about the merits of various screwdriver heads than I would have thought possible.

2. Software development is a little unique as an industry since it's not all that common that the users of the tools are also the people who make the tools. There's naturally going to be a lot of discussion about tools if you're both the maker and the user of them.

3. Us not having a standard for which tool to use is a reason to have these discussions, not a reason to say "pick whatever, it doesn't matter". The reason that those people don't write blog posts and have discussions about the merits of a hammer vs. a screwdriver is precisely because they're so well established - if both were a couple of years old, absolutely people in construction would be discussing whether to use nails or screws for an application.

Re: Things engineers believe about Web development

#195

Post by zelphirkalt »

christophilus wrote: post #34
ryanbrunner wrote: post #6

The refrain against the "we should go back to MPA apps with server rendered HTML" is often "well what about Figma and Photoshop", which of course, yes those don't really work in the MPA, server rendered HTML model. The problem isn't so much those but how most developers lump themselves in with the incredibly interactive sites because it sounds sexier and cooler to work on something complex than something simple. The…

That’s not why. In my experience, applications accumulate interactivity over time. At some point, they hit a threshold where you (as a developer— not an end user) wish you had gone with an interactive development model. Also, for me, the statically typed, component-based approach to UI development that I get with Preact is my favorite way to build UIs. I’ve used Rails, PHP, ASP (the og), ASP.NET, ASP.NET MVC, along w…

I don't see why you cannot add interactivity later on. Frameworks like VueJS provide an easy way to deliver interactive widgets on a subset of rendered pages of a traditional website. If you need an API on the backend, you need to write that API one way or another anyway.

This way people who are just looking for some information on a website can go visit, get, and leave, without having to enable intrusive JS blobs, while those in for the interative things on the website can get their preferred experience as well. Instead many websites are developed with only the second group in mind, often intentionally forcing you to run their code on your computer, or not delivering useful information at all.

Re: Things engineers believe about Web development

#196

Post by stephenr »

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…

> click around the documentation pages - do you think that's an SPA or an MPA?

I think it's a page with broken use of the history api.

I clicked your link, opened the menu (as a comment mentioned it being slow), and then had to hit back 3 times to return here.

Re: Things engineers believe about Web development

#197

Post by zelphirkalt »

mardifoufs wrote: post #191
bombela wrote: post #186

Earlier quoted context omitted.

https://react.dev/learn is so slow on my phone, it takes 1.5s to open the burger menu, and about 1s to jump to a section. (Google pixel 5a). It must be some SPA that loads the whole documentation all at once I presume. A traditional MPA would probably work much better here. edit: and like the sibling comment noted, the history back button gets messed up. edit2: I mistakingly wrote nexus 5a instead of pixel 5a

Do you mean the pixel 5a? Just wondering because it would make a big difference if it was nexus 5 from 10 years ago, versus a much more recent pixel 5!

Whichever it is, it should certainly not take 1.5s to open a menu. Especially not on a website, that aims to teach people something about web development.

Re: Things engineers believe about Web development

#198

Post by bombela »

mardifoufs wrote: post #191
bombela wrote: post #186

Earlier quoted context omitted.

https://react.dev/learn is so slow on my phone, it takes 1.5s to open the burger menu, and about 1s to jump to a section. (Google pixel 5a). It must be some SPA that loads the whole documentation all at once I presume. A traditional MPA would probably work much better here. edit: and like the sibling comment noted, the history back button gets messed up. edit2: I mistakingly wrote nexus 5a instead of pixel 5a

Do you mean the pixel 5a? Just wondering because it would make a big difference if it was nexus 5 from 10 years ago, versus a much more recent pixel 5!

Yes pixel 5a, thank you. Edited.

Re: Things engineers believe about Web development

#199

Post by jasode »

ryanbrunner wrote: post #167
jasode wrote: post #129

Earlier quoted context omitted.

>partial renders and / or DOM morphs of server generated HTML responses, eliminating the full-page refresh effect. www.mcmaster.com seems to utilize this to some degree, actually - while yes there are JSON responses, there are what appear to be HTML partial responses as well that are presumably injected on the page. Uhm... yes?!? The behavior you listed is exactly why I gave you that McMaster example. So I guess I'm…

I think a lot of the time "SPA" vs "MPA" essentially actually means "does the client largely render it's own HTML" or "does the server render HTML and the client just displays it". Whether it displays that with a full page refresh or by injecting HTML via Javascript does not in practice matter. The idea of using AJAX to render HTML fragments to increase interactivity predates the term "SPA" by about a decade. That's…

>I think a lot of the time "SPA" vs "MPA" essentially actually means "does the client largely render it's own HTML" or "does the server render HTML and the client just displays it".

It seems like there was already terminology of CSR-vs-SSR (client-side vs server-side rendering) to differentiate that so there was no need for SPA-vs-MPA to overlap with CSR/SSR to try and make the same distinction.

>Whether it displays that with a full _page_ refresh or by injecting HTML via Javascript does not in practice matter.

It seemed like the 'P' in SPA-vs-MPA is literally about the Page(s) being reloaded. It's "single page" or "multiple pages". That's why developers like to clarify that Next.js -- even with SSR HTML hydration of various subpages -- is still an SPA because the page on the client-side browser isn't reloaded. I just did some skimming of various "SPA vs MPA" search results and none seemed to use those acronyms as a way to classify CSR-vs-SSR. (https://www.google.com/search?q=spa+vs+mpa)

I'm also not clear how you classify Mcmaster.com ? Is it an MPA to you?

>If your definition of "MPA" is "every interaction requires a full page load", it's a pointless discussion,

No I'm not saying every interaction. I was responding to your original suggestion of "MPA with query parameters to a results page" ... and showing how McMaster.com search filters do not work the way you recommend it should. Each click of navigation and filters triggers a JSON payload and dynamically rebuilds the DOM tree. The browser's performance.timing.loadEventEnd property value does not change.

Re: Things engineers believe about Web development

#200

Post by jwells89 »

kgdiem wrote: post #193
jwells89 wrote: post #149

Earlier quoted context omitted.

A big factor in that “tinkeriness” of SPAs is how nearly every part of making an SPA well-behaved and pleasant to use falls almost entirely on the shoulders of the developer. Due to how little browsers provide on that front, well-behaved polished SPAs are very much not on the happy path or default. Even if you use the big popular libraries, special care must be taken to not build a product that’s a frustrating mess f…

Yes, can’t argue with that. Making apps for iOS and usually Android is often way more pleasant. Have you seen any serious proposals on this front?

I track web engine development only loosely, but no I haven’t seen much movement in that realm.
Post reply on HN