Things engineers believe about Web development • Hacker News Board

Re: Things engineers believe about Web development

#111

Post by jasode » Sun, Jan 07, 2024, 2:47 PM UTC

ryanbrunner wrote: post #71

blackoil wrote: post #62

Earlier quoted context omitted.

> The problem isn't so much those but how most developers lump themselves in with the incredibly interactive sites It is not only Figma or Photoshop. Any site with multiple steps of interactions or complex filters over search result etc. benefit from SPA and declarative code. The experience is smoother and development of anything, but simple forms is much faster. People disabling JS or working on satellite internet f…

Stuff like filtering search results is very easily accomplished by a MPA with query parameters to a results page. The specific elements that allow you to specify query parameters often require more interactivity, but this is easy to layer on with a progressive enhancement type approach on top of a fundamentally MPA application.

>Stuff like filtering search results is very easily accomplished by a MPA with query parameters to a results page.

But the "MPA to another results page" causing an HTML reload with a flickering blank screen is a jarring UI experience.

The issue isn't what's "easy" to implement. Instead, users prefer a fluid and responsive UI. An example of a website that has superfast filters in SPA style instead of "MPA results page" is McMaster-Carr: https://www.mcmaster.com/

On that website, when the user changes the categories or filters, the results of items instantly change without the jarring disruption and delay of a new page being loaded.

There were several previous HN threads about it. Based on the near-universal praise in the comments of those threads, I don't think converting McMaster architecture to your suggested "MPA search results" would be considered an improvement. :

+ https://news.ycombinator.com/item?id=32976978 : Mcmaster.com is the best e-commerce site I've ever used (bedelstein.com) 1402 points by runxel on Sept 25, 2022 | hide | past | favorite | 494 comments

+ https://news.ycombinator.com/item?id=34306793 : McMaster-Carr: A refreshingly fast, thoughtful, and well-organized website(https://www.mcmaster.com/) 102 points|jer0me|1 year ago|36 comments

+ https://news.ycombinator.com/item?id=24803857 : McMaster-Carr: Beautifully organized and informational industrial product store(https://www.mcmaster.com) 40 points|astrocat|3 years ago|27 comments

+ https://news.ycombinator.com/item?id=34000502 : Best ecommerce UX practices from mcmaster.com(https://medusajs.com/blog/9-best-ecommerce-ux-practices-with...) 322 points|amoopa|1 year ago|167 comments

Re: Things engineers believe about Web development

#112

Post by Aurornis » Sun, Jan 07, 2024, 2:48 PM UTC

t8sr wrote: post #68

blackoil wrote: post #62

Earlier quoted context omitted.

> The problem isn't so much those but how most developers lump themselves in with the incredibly interactive sites It is not only Figma or Photoshop. Any site with multiple steps of interactions or complex filters over search result etc. benefit from SPA and declarative code. The experience is smoother and development of anything, but simple forms is much faster. People disabling JS or working on satellite internet f…

This attitude is the reason why I now dread filling out any random web form, because a poorly implemented crappy JavaScript ”flow” will take over my browser, break the back button, accessibility and autofill features and randomly fail and start over in step 6 out of 19. It’s the reason why a simple web form requires 100 MB of bandwidth to deal with. People working from a train or on data roaming are not a fringe case…

> It’s the reason why a simple web form requires 100 MB of bandwidth to deal with.

I have a hard time taking these arguments seriously because they get so exaggerated on HN.

I’ve done a lot of work from flights and extremely low bandwidth, high latency connections in foreign hotels. Not once have I encountered anything like a web form taking 100MB.

Re: Things engineers believe about Web development

#113

Post by ksec » Sun, Jan 07, 2024, 2:49 PM UTC

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 usage dont deviate from mine that much.

The thing about JS SPA is that they are hard to make it 100% right. Even the simplest thing. And this goes back to the topic about Web Development and computing. Modern day web is designed by Google for Google. Making things easier for 98% of the web simply isn't their thing. And that is not just on the Web but everything else they do as well. And since no one gets fired for using what Google uses, we then end up with additional tools to solve the complexity of what Google uses.

Depending on how you count it we are now fast coming close to 20 years of Google dominance on the web. And there hasn't been a single day I didn't wish for an alternative to compete with them. I know this sounds stupid. But may be I should start another Yahoo.

Re: Things engineers believe about Web development

#114

Post by endisneigh » Sun, Jan 07, 2024, 2:50 PM UTC

Technology is not a religion and it doesn’t need prophets. Why are people so hell bent on convincing others to join them in their use of whatever technology?

Pick what solves your problem. In the context of web development that overwhelming means using whatever is most popular given your preferred programming language.

Re: Things engineers believe about Web development

#115

Post by davidmurdoch » Sun, Jan 07, 2024, 2:53 PM UTC

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…

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

Re: Things engineers believe about Web development

#116

Post by t8sr » Sun, Jan 07, 2024, 2:55 PM UTC

Aurornis wrote: post #112

t8sr wrote: post #68

Earlier quoted context omitted.

This attitude is the reason why I now dread filling out any random web form, because a poorly implemented crappy JavaScript ”flow” will take over my browser, break the back button, accessibility and autofill features and randomly fail and start over in step 6 out of 19. It’s the reason why a simple web form requires 100 MB of bandwidth to deal with. People working from a train or on data roaming are not a fringe case…

> It’s the reason why a simple web form requires 100 MB of bandwidth to deal with. I have a hard time taking these arguments seriously because they get so exaggerated on HN. I’ve done a lot of work from flights and extremely low bandwidth, high latency connections in foreign hotels. Not once have I encountered anything like a web form taking 100MB.

Two weeks ago, I let my partner use my data roaming to submit two forms on some Adobe collaboration thing, reply to a chat message on Teams and send an email. The counter on my phone said these actions used about 500 MB of bandwidth in the space of about 20 minutes.

I agree it sounds exaggerated, but I don’t think it is. This is kind of my point, it’s past the point you would think likely.

Re: Things engineers believe about Web development

#117

Post by davidmurdoch » Sun, Jan 07, 2024, 2:55 PM UTC

Aurornis wrote: post #109

blackoil wrote: post #62

Earlier quoted context omitted.

> The problem isn't so much those but how most developers lump themselves in with the incredibly interactive sites It is not only Figma or Photoshop. Any site with multiple steps of interactions or complex filters over search result etc. benefit from SPA and declarative code. The experience is smoother and development of anything, but simple forms is much faster. People disabling JS or working on satellite internet f…

> People disabling JS or working on satellite internet from a remote island are fringe cases and are not relevant for the business. Satellite internet (even before Starlink) is actually plenty fast for a modern website, as long as delivery is halfway optimized to avoid a thousand round trips. It’s people on mobile phones in 3rd-world countries that suffer the most, but they end up with specially optimized websites an…

Often times people don't disable JS, networking hiccups and bad JS disable JS.

Re: Things engineers believe about Web development

#118

Post by Xeamek » Sun, Jan 07, 2024, 2:56 PM UTC

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.

...except those field are literally a thousands years old, while software industry is about 70? Them being more mature doesn't change the fact that processes and tools are crucial

Re: Things engineers believe about Web development

#119

Post by ryanbrunner » Sun, Jan 07, 2024, 2:57 PM UTC

jasode wrote: post #111

ryanbrunner wrote: post #71

Earlier quoted context omitted.

Stuff like filtering search results is very easily accomplished by a MPA with query parameters to a results page. The specific elements that allow you to specify query parameters often require more interactivity, but this is easy to layer on with a progressive enhancement type approach on top of a fundamentally MPA application.

>Stuff like filtering search results is very easily accomplished by a MPA with query parameters to a results page. But the "MPA to another results page" causing an HTML reload with a flickering blank screen is a jarring UI experience . The issue isn't what's "easy" to implement. Instead, users prefer a fluid and responsive UI . An example of a website that has superfast filters in SPA style instead of "MPA results pa…

> 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 what appear to be HTML partial responses as well that are presumably injected on the page. In any case, everything on that search engine would be trivially accomplished using a server rendered HTML approach without needing to utilize a SPA. It's actually a great example of something that would work great with progressive enhancement - the search bar can start as a simple input that leads to full page search results, the navigation can do a full page refresh if the partial page refresh JS isn't available for some reason. Javascript can make it better without being a requirement.

A good rule of thumb is that if an interaction existed at roughly the same fidelity during the Web 2.0 days, it's not something that requires a SPA framework. Typeahead search results and categorized product listings existed and were functional to the level of the site you linked back then.

Re: Things engineers believe about Web development

#120

Post by troupo » Sun, Jan 07, 2024, 2:58 PM UTC

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…

> 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)