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

181–190 of 254 posts

Re: Things engineers believe about Web development

#181

Post by paulddraper »

chriswarbo wrote: post #136
aatd86 wrote: post #130

Earlier quoted context omitted.

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…

> Strangely enough, this dichotomy seems to exist only for the web platform. > Everywhere else (desktop, mobile etc) the model is SPAs. It exists for CLIs too, where some projects provide a collection of single-purpose programs (e.g. imagemagick) and others provide a single program which can do many things (e.g. git)

No not really.

Yes there are two approaches, but you can switch between the two with 98% of the code intact.

Re: Things engineers believe about Web development

#182

Post by palata »

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.

Sure, I'm not saying it's easier. It would be completely stupid to go down the webapps road if the desktop apps one was both better and easier.

I kind of find it ironic, though: why not write one desktop app that only supports the latest version of Windows, and tell your users to use that? If you're big enough, surely you can force them to use the OS you want, right?

I am convinced that most people who love webapps kind of hate the idea of being forced to use the latest version of Windows. But somehow they find it okay to force everyone to use Chromium? What's the difference?

Re: Things engineers believe about Web development

#183

Post by csande17 »

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…

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?

Re: Things engineers believe about Web development

#184

Post by troupo »

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.

Ah, I fogot about PIP

Re: Things engineers believe about Web development

#185

Post by rramadass »

calderwoodra wrote: post #150
rramadass wrote: post #133

Well written informative article. What does it say about this whole domain when, as the author says, Web Apps and Sites/Blogs (also add in Mobile apps) are so very different from each other using a myriad set of technologies each of which has a learning curve? Where is the uniformity and commonality in all this? Why are developers even perpetuating this? That said, this might be a good place to ask for recommendation…

Businesses want uniformity and commonality since, in theory, it should lower development costs (see projects like flutter and fuschia, which have the goal to make every platform web based). The problem is that users/customers have higher expectations for their user experiences than the web can offer on mobile/desktop/etc. Robinhood, Duolingo, Slack are a few good examples of UX being huge differentiators.

I understand what you are saying but am not clear as to why it should be so. Having programmed GUI apps in Microsoft Windows and X-Windows/Motif (which can be remote) on Unix systems i am not sure why we cannot have a similar uniform architecture for "Web Apps". After all the "Browser" is considered a platform in itself. Also given that HTTP has now been munged into practically being a Transport protocol for anything, previous limitations are no longer an excuse.

Re: Things engineers believe about Web development

#186

Post by bombela »

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…

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

Re: Things engineers believe about Web development

#187

Post by g9yuayon »

I'd like to add another one: I don't need a separate NodeJS (or whatever engine) service to build my service dashboard. Before NodeJS got popular, backend engineers like me simply put web assets into a folder in my web app, so my service will have an admin page or a dashboard for per-node administrations. For some reason, such practice has become a taboo. My engineers have been insisting that they set up a separate NodeJS service just to build even a simple admin page. But I fail to see why. The reasons I got are usually these three: 1) a NodeJS service gives us optimized performance, though techniques like server-side rendering; 2) a separate service is easier to scale; 3) a separate service offers separation of concerns. However, 1) and 2) are premature optimization to me. All I need is standardized per-node admin page for my service. The QPS is probably one per day by a human. Why would I care about SSR or scalability at all? And 3) is quite hand-wavy. On the other hand, the overhead of managing a separate service as well as the dependencies brought by NodeJS' ecosystem seems high.

So, what's wrong with the old way of having embedded web assets in a service for building simple admin pages?

Re: Things engineers believe about Web development

#188

Post by ryanbrunner »

jameshart wrote: post #179
ryanbrunner wrote: post #176

Earlier quoted context omitted.

"Well designed SPAs look and feel like a MPA" isn't exactly a ringing endorsement when MPAs are less complex to build.

What part of 'insanely snappy' did you miss? There's NO NEED for a browser to reload and reconstitute the entire page context on every interaction! It's a crazy way to architect applications!

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.

Re: Things engineers believe about Web development

#189

Post by christophilus »

davidmurdoch wrote: post #115
christophilus wrote: post #34

Earlier quoted context omitted.

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…

Styling with WPF (the thing after winforms) was so confusing, at least from someone coming from CSS.

WPF. That was it. Yeah. It was terrible.

Re: Things engineers believe about Web development

#190

Post by marcosdumay »

jayceedenton wrote: post #57
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…

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

Oh, here we go.

When we start to even think about debate fallacies when comparing engineering methodologies, it's completely clear we already lost the game. In fact, we also lost the meta game, and probably some 2 or 3 outer meta layers of it.

So yes, we should design software for the specifics of the function it will provide. Do not let people evade their competency by talking in generalities.

Post reply on HN