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

121–130 of 254 posts

Re: Things engineers believe about Web development

#121

Post by endisneigh »

Xeamek wrote: post #118
endisneigh wrote: post #106

Earlier quoted context omitted.

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

No one is disagreeing with that.

Re: Things engineers believe about Web development

#122

Post by troupo »

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…

> The issue isn't what's "easy" to implement. Instead, users prefer a fluid and responsive UI.

Most SPAs can't give you that either.

Re: Things engineers believe about Web development

#123

Post by ryanbrunner »

troupo wrote: post #120
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…

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

Re: Things engineers believe about Web development

#124

Post by sidlls »

blackoil wrote: post #83
icedchai wrote: post #58

Earlier quoted context omitted.

The earliest web apps I worked on were multi-page apps, with pages generated by Perl CGIs, later PHP. There was almost nothing going on on the client side except form submissions and a bit of JS-based form validation. I can tell you with 100% certainty this was simpler to build than most anything I see today with React SPAs and REST APIs. Even a simple form submission can be a PITA with modern tools.

> Even a simple form submission can be a PITA with modern tools. SPA excel in complex interactions if you need only very simple forms it will be PITA

I think the argument is generally that most applications' "complex interactions" are artificial contrivances and are unnecessary. I certainly think so.

Re: Things engineers believe about Web development

#125

Post by troupo »

jefftk wrote: post #93
Gustek wrote: post #20

Earlier quoted context omitted.

My understanding of ePrivacy (mostly GDPR) is that this kind of feature does not require consent. It's only features that would allow you for tracking of the user that require consent. Storing some setting in a local storage, never sending it to the server is fine. Things get a bit muddy when sending to server but even then you may not need a consent if it is a feature that is required for correct working of the webs…

GDPR and ePrivacy are different regulations. Under the latter even purely local data storage still requires consent unless it's "strictly necessary" to implement something the user has requested. For example, see the discussion the sibling commenter linked around storing UI customization choices for only the duration of the current session: https://ec.europa.eu/justice/article-29/documentation/opinio...

You don't need consent in this case, as clearly stated in 3.6 UI customization cookies

--- start quote ---

3.6 UI customization cookies

These customization functionalities are thus explicitly enabled by the user of an information society service (e.g. by clicking on button or ticking a box) although in the absence of additional information the intention of the user could not be interpreted as a preference to remember that choice for longer than a browser session (or no more than a few additional hours). As such only session (or short term) cookies storing such information are exempted under CRITERION B

--- end quote ---

Re: Things engineers believe about Web development

#126

Post by quest88 »

JackMorgan wrote: post #17

Last month a client asked me to build them a crud form only using old school C# MVC with Razor templates. And by golly it was much harder for me than just doing it in React+Next. I had some nostalgic notion that MVC was going to be a smooth ride. That all this JS cruft was slowing me down. Then I needed a search bar, then validation, then I kept running into weird surprises with Razor templates. After a month I ruefu…

Are you surprised that it took you longer with a tool you don't know compared to a tool you do know? IMO, that should be expected.

Re: Things engineers believe about Web development

#127

Post by Yaina »

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…

I think it's (increasingly) not as binary as either MPA or SPA. Although it has been for quite some time now.

A lot of web developers strive for some amount of templating and client-side interactivity on their websites. And when frameworks like React came up they solved interactivity issues but made it hard to integrate into existing server-side templating systems, which were mostly using different programming languages.

So because integrating the frameworks for client-side interactivity was hard, the frameworks also took on the job of templating the entire site and suddenly SPAs were popular. I think a big draw here was that the entire tooling became JavaScript.

But the drawbacks were apparent, I guess a big one was that search engines could not index these sites and of course performance, so the frameworks got SSR support. The site was still written in the framework, rendered to HTML on the server and then hydrated back to a SPA on the client.

Now, even more recently we got stuff like islands, where you still use the handy web framework but can choose which parts of your site should actually be interactive (i.e. hydrated) on the client. And I believe this is the capability that has just long been missing. Some sites require no JS on the client (could even be SSGs), others require a little interactivity, and some make most sense as full blown SPAs.

We're finally entering the era where the developer has that choice even though they use the same underlying framework.

Re: Things engineers believe about Web development

#128

Post by zozbot234 »

danielvaughn wrote: post #78
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,…

Or even avoid discussing SPAs or MPAs entirely. At the end of the day, we're talking about whether a specific interaction (or a set of interactions) can be handled over the network or not. If you need the interaction to fully resolve (as in the state is updated and the success or failure of the interaction is visible to the user) within 800ms or so, then it shouldn't be performed over the network. For interactive edi…

> If you need the interaction to fully resolve (as in the state is updated and the success or failure of the interaction is visible to the user) within 800ms or so, then it shouldn't be performed over the network.

Most real-world SPA sites perform a lot more roundtrips over the network than the MPA equivalent, not less. And every roundtrip adds yet another 800ms to your update latency, plus the risk that some random network failure will break the SPA state update and force you to reload it from scratch.

Re: Things engineers believe about Web development

#129

Post by jasode »

ryanbrunner wrote: post #119
jasode wrote: post #111

Earlier quoted context omitted.

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

>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 a little confused. In any case, your comment matches up with the wikipedia definition of SPA (https://en.wikipedia.org/wiki/Single-page_application):

>A single-page application (SPA) is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the web server, instead of the default method of a web browser loading entire new pages. The goal is faster transitions that make the website feel more like a native app.

An alternate way of interpreting your reply to me is if you also categorize McMaster's website behavior as a form of "MPA". In other words, you classify McMaster's loading of new HTML fragments and rewriting DOM as "multiple pages". I've not heard others define MPA in this way.

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

Yes, we've already agreed about it being technically trivial. The issue is end user's preferred UI experience. Users don't want the "page refresh/reload" even though it's trivial.

Re: Things engineers believe about Web development

#130

Post by aatd86 »

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

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 specific kind of apps, a website being simply an app that has been broken apart and is sent piece by piece.

Post reply on HN