Live data from Hacker News

Things engineers believe about Web development

birtles.blog

151–160 of 254 posts

Re: Things engineers believe about Web development

#151

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

> beneficial for those enthusiastic about SPAs

It's almost as if some developers choose technologies based on "what'll look good on my CV"

Re: Things engineers believe about Web development

#152
> Many didn’t know about new CSS features that had shipped 10 years ago. What’s more, even when we told them about them, they didn’t seem too excited. They were doing just fine with jQuery and WordPress, thank you.

...and if jQuery and WordPress do the job, they are sound technical decisions.

What is not a sound technical decision is forever chasing the latest fashion in technology. Also known as the "oh look a shiny thing development paradigm".

Re: Things engineers believe about Web development

#153

> “Web development shouldn’t need a build step” Everything running in a browser is interpreted. There is no reason for webdev to require a build step, and it largely does so because JS standards haven't delivered anything around static typing. Even a "this syntax is valid but ignored" would enable IDEs to provide checks via LSPs, but for no-build running. Build steps and development iteration overhead is something to…

A build step is fine. I think the point misses the real issue: that build step changing every 6 months in the web world.

Every time you have to go back to an "old" project you haven't worked on in six months there is a webpack/npm dependency hell greeting you.

Re: Things engineers believe about Web development

#154

nothing wrong with build steps until they go wrong. then you will spend 5 hours replacing/updating deprecated/newly incompatible npm/system issues.

The horrifying guidance I've gotten a number of times when I step into a project is "downgrade your node version 5 years and never update anything."

Re: Things engineers believe about Web development

#155

> “Web development shouldn’t need a build step” Everything running in a browser is interpreted. There is no reason for webdev to require a build step, and it largely does so because JS standards haven't delivered anything around static typing. Even a "this syntax is valid but ignored" would enable IDEs to provide checks via LSPs, but for no-build running. Build steps and development iteration overhead is something to…

I appreciate the build step in setups like Vite/Vue because the development server can automatically and accurately hotpatch the application when I make changes. I don’t think you’d want to change the standards to couple DOM and js in the way that makes this possible in Vue but it’s an iteration speed improvement nonetheless.

Re: Things engineers believe about Web development

#156
Absolutely fantastic writing —- clear, kind, authoritative. Don’t agree with it all but I think the last section sums it all up nicely, and is something I’ve felt for a while.

With new SSR frameworks like Next.js, I think this whole MPA/SPA dichotomy starts to dissolve a little bit. I’m thrilled that browser standards are evolving to help it along!

Re: Things engineers believe about Web development

#157
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. This is the worst and dumbest excuse for SPA bullshit. It's not jarring. You'll get over it. It's a fraction of a second where your devices is obviously doing a thing . Web devs love the word "jarring" like it's some world shattering visual effect. SPAs break all the time in dumb-ass ways that are…

>Web devs love the word "jarring" like it's some world shattering visual effect.

I've never been a web dev. I'm just explaining why the typical mainstream end users who don't have the same patience as HN-type techies (who more happily accept MPA) do not like the discontinuous UI of reloading pages.

Another example of that SSR MPA page reload/refresh would be old Mapquest before 2006. Screenshot: https://www.e-education.psu.edu/geog160/sites/www.e-educatio...

Each click on North/South/East/West buttons and Zoom In/Out blanked out the entire page and loaded a new page to shift the map viewport. This was a suboptimal UI experience for the typical user. I concede it wasn't "jarring" to you but it was to a lot of users -- especially compared to a CDROM maps experience. Example video of a smoother maps UI experience circa ~2000 from Microsoft CDROM desktop software without "blank reloading pages" to move a map around and change zoom levels: https://www.youtube.com/watch?v=4YO_KGdsUm4

The Mapquest "MPA page reloads" from 2006 was a UI that was less smooth than the Microsoft Streets CD software from 2000.

In 2005, when Google launched Google Maps with extensive usage of Javascript live-loading map tiles to provide smooth scrolling without reloading pages, end users liked that UI because it felt more interactive. In response, Mapquest also eventually switched away from the old-style SSR MPA page reloads: https://techcrunch.com/2007/10/12/exclusive-mapquest-plays-c...

The 2005 SPA-style of Google Maps just gets the UI back to what users already experienced in 2000 with desktop software. The SSR MPA page reloads was something that end users endured with Mapquest but it wasn't actually the UI they really wanted.

I'm not advocating the web devs use SPA (or SPA frameworks). Instead, I'm saying that responding with "SPA websites can be redone as MPA and it's trivial" is saying something that's true but still doesn't actually address the issue that mainstream endusers don't like the discontinuity of MPA type of UIs. That's the subthread I was addressing: https://news.ycombinator.com/item?id=38901249

E.g. McMaster.com is not a "web app" like Figma/Photopea but users prefer the SPA-style UI of that parts catalog website.

Re: Things engineers believe about Web development

#158
post #56

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…

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?

Re: Things engineers believe about Web development

#159

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…

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

This is very similar to the NoSQL arc. Some people at prestigious places posted about some cool problems they had, and a generation of inexperienced developers started that they needed MongoDB and Cassandra to build a CRUD app with several orders of magnitude fewer users, transactions, or developers. One of the biggest things our field needs to mature on is the idea of focusing on the problem our users have rather than what would look cool when applying for a new job.

The SPA obsession has been frustrating that way for me because I work with public-focused information-heavy sites where the benefits are usually negative and there’s a cost to users on older hardware – e.g. the median American user has JavaScript performance on par with an iPhone 6S so not requiring 4MB of JS to display text and pictures has real value – but that conflicts with hiring since every contractor is thinking about what’ll sound “modern” on their CV.

Re: Things engineers believe about Web development

#160

Earlier quoted context omitted.

Huh, Guess I was right :p So neither of those are a good argument in favour of these complicated javascript stacks, are they?

Just because Figma opted for this route doesn't make it right for all interactive web applications.

Yeah. That's what the little `:p` at the end of that comment meant.
Post reply on HN