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

161–170 of 254 posts

Re: Things engineers believe about Web development

#161

Post by ryanbrunner »

christophilus wrote: post #101
ryanbrunner wrote: post #88

Earlier quoted context omitted.

Preact / React is simple because it solves for a very small slice of what an application needs to do and willfully ignores the rest. For example, (P)React has no real opinion on how it interacts with a server, which is a fundamental requirement of 99% of web applications (the new server components stuff is a counterargment I guess, but even then it doesn't consider the complexities of what a backend needs to do and i…

But, that is a form of simplicity. It’s kind of the UNIX approach. I use Preact and a typed RPC client and a very simple router. The result is a reasonably small, easy-to-reason about program that I find very enjoyable to work on. If Preact shipped with their own communication layer and router, that would reduce the simplicity, and I’m not sure I’d actually like the choices they made for the part of the stack that is…

Sure, that's fine, I'm just saying they're not really directly comparable. A batteries included framework is an entirely different beast than a view library.

Re: Things engineers believe about Web development

#162

Post by bluefirebrand »

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.

It's kind of an awful experience though? Do people actually want their videos to follow them? If I'm navigating away it's because I'm done, it actually makes me kind of angry that the video chases me.

Re: Things engineers believe about Web development

#163

Post by vbezhenar »

javcasas wrote: post #145
ryanbrunner wrote: post #98

Earlier quoted context omitted.

JS builds today do not appreciably accelerate code, and minimization is of marginal benefit when served assets are appropriately compressed using technologies browsers already support.

No matter how fancy your compression, that code with comments stripped will compress to less bytes than the same code with comments.

No matter how much would you try to save those 10 KB, someone will put 30 MB image file just to display tiny flag in the top right corner. Stripping comments is unnecessary optimization.

Re: Things engineers believe about Web development

#164

Post by freedomben »

xpe wrote: post #140
jayceedenton wrote: post #57

Earlier quoted context omitted.

This is motte-and-bailey argumentation in my opinion. The motte: SPAs are a good way to write highly complex applications in the browser, like Photoshop and Figma, to compete with desktop apps. The bailey: SPAs are a good way to write most web applications. If you attack the bailey, proponents retreat to the motte, which is hard to disagree with. With the motte successfully defended, proponents return to the bailey,…

A fun metaphor. A SPA-inclined team/consultancy/department will retreat to their motte when necessary. They'll live to fight another day. Given a chance, they'll return to the bailey, advocating for SPAs under a relaxed standard. Using this metaphor can imply significant disingenuity: a lack of honesty about one's true belief.

> Using this metaphor can imply significant disingenuity: a lack of honesty about one's true belief.

I actually disagree. I think this is the natural state of people, and they come by it honestly. We make decisions emotionally and then justify them rationally. It's just the way we are.

You could maybe say it's a lack of honesty about one's true belief to themselves. But even then it's hard to fault somebody for lack of awareness for something that is very subtle.

Honestly I think pointing out this human tendency and calling it out with examples like this is the best way to combat it. Once people become aware of it, they are more likely to fight it internally.

Re: Things engineers believe about Web development

#165

Post by wickedsickeune »

tantalor wrote: post #158
onli wrote: post #56

Earlier quoted context omitted.

The jump from JS to the microsoft world is always hard. Hell, jumping from anywhere into microsoft environments has to be hard. No surprise that it was a difficult transition if that wasn't in your background so far. The docs alone will cause a culture shock! > But for me, with a project with increasingly complex display logic and validation It always sucks if the requirements are not clear in the beginning, if the d…

What is HMR? Is it edit/refresh?

Hot Module Reload, changing the code in a "module" and not having to refresh the whole page.

Re: Things engineers believe about Web development

#166

Post by acdha »

aatd86 wrote: post #130
jayceedenton wrote: post #57

Earlier quoted context omitted.

This is motte-and-bailey argumentation in my opinion. The motte: SPAs are a good way to write highly complex applications in the browser, like Photoshop and Figma, to compete with desktop apps. The bailey: SPAs are a good way to write most web applications. If you attack the bailey, proponents retreat to the motte, which is hard to disagree with. With the motte successfully defended, proponents return to the bailey,…

Strangely enough, this dichotomy seems to exist only for the web platform. Everywhere else (desktop, mobile etc) the model is SPAs. The only reason people distinguish it for web is because of legacy: html + DOM, i.e. Documents. Documents don't generally require programmers even if using lateX. Both models can coexist. I believe that SPAs somewhat supersede MPAs and that an MPA can be a simplification sometimes for a…

> Everywhere else (desktop, mobile etc) the model is SPAs.

> The only reason people distinguish it for web is because of legacy: html + DOM, i.e. Documents.

There’s another key difference: the other model has preinstalled software and most functionality is on trusted clients. If I email you a Word document, you don’t have to download Word from the Office servers to open it, which creates very different trade offs. There’s also a big difference in trust: I don’t need to ask whether I want each web page I open to have access to the data on my computer.

The web’s big selling point was the immediacy of being able open anything quickly and not needing to trust the remote server to run native code on your system (even in the 90s we knew that was a bad idea), so it’s not surprising that there’s so much gravity to its core model. The addition of more app-like abilities is really useful but it’s lead to a certain amount of app-envy where people often pick the cool technical challenge without asking whether they’re working on an app which needs it.

Re: Things engineers believe about Web development

#167

Post by ryanbrunner »

jasode wrote: post #129
ryanbrunner wrote: post #119

Earlier quoted context omitted.

> But the "MPA to another results page" causing an HTML reload with a flickering blank screen is a jarring UI experience. Pretty much every modern full stack framework includes approaches to do 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…

>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 not really strictly the same thing as what the acronyms SPA and MPA, but in reality, people refer to a Rails application that uses large amounts of Hotwire as a "MPA" (even if it never results in full page refreshes and often doesn't even feel like navigating pages) and things built with tools like React as "SPAs" (even if you're perfectly capable of navigating between pages and getting React rendered by the server until the client takes over routing.

If your definition of "MPA" is "every interaction requires a full page load", it's a pointless discussion, because that's not really the reality of development even with "MPA" frameworks like Rails or Phoenix (I can't really speak to stuff like Laravel, but I'm sure they have an equivalent)

Maybe a good way to think about it is that the fundamental interaction model of frameworks like Rails is that they're built around the concept of the server returning new pages on navigation, and optimize that to provide a better experience, and SPAs are designed around the idea of a single web page visit instantiating an application at which point the client is control of navigation, but they optimize that to provide a better user experience (i.e. server side rendering of pages on first load).

Re: Things engineers believe about Web development

#168

Post by jameshart »

ksec wrote: post #113
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…

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 the documentation pages - do you think that's an SPA or an MPA?

Open up your network tab, and you'll find out what's happening: When you hover over a nav header, it starts preloading a JSON file containing the content for that page. When you click on a navigation link, that content's loaded into the react DOM and some more prefetches of just JSON content for likely next pages are loaded up. Your browser navi is updated, but you are still in the same original page context you started in. It is insanely snappy to interact with.

Re: Things engineers believe about Web development

#170

Post by jauntywundrkind »

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…

Simplest feels like a folly. No project of significance stays in a simple phase. They all grow and expand.

Having a stable reliable generally applicable decision/toolset you can apply beats this hunt for optimization to smithereens. Don't optimize case by case. Optimize for your org, for your life, lean into good tools you can use universally and stop special casing your stuff. There's nearly no reason to complicate things by hounding for "simplicity." Other people won't be happier if you keep doing side quests for simple, and you won't be either.

(Do learn to get good with a front-end router, so you can avoid >50% of the practical downsides of SPAs. And I hope over time I can recommend WebComponents as a good-for-all un-framework.)

Post reply on HN