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

141–150 of 254 posts

Re: Things engineers believe about Web development

#141

Post by dstroot »

palata wrote: post #139
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…

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

Re: Things engineers believe about Web development

#142

Post by url00 »

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…

Having done a similar project this year I completely agree with you. Maybe that's more a statement against Razor than MVC itself - I suspect it's much cleaner/easier to do a trad MPA+MVC-style app in a language+framework combo that is made for it like Rails.

I think the reality is that Razor has been left rotting for a while. It still works, and there's nothing that bad about it but the DX is not good, especially compared to modern JS frameworks.

It's hard to explain to people who haven't worked with Razor how annoying things like validation are. There is a "happy path" where the different parts of the validation framework all talk to each other, but it's not obvious and the Razor documentation on MSDN is very _not good_. It doesn't help that there's like 5 completely different things all called "Razor/Blazor" and a lot of semantic overlap between them all. Very frustrating to need to sift through so much to find something that feels like it should be easy and well supported.

Re: Things engineers believe about Web development

#143

Post by amadeuspagel »

> There are Twitter/X polls, for example, but they tend to only be answered by the Web developers on the bleeding edge and are easily skewed by who spreads the word about the poll.

Maybe MDN should have a comment section, like the PHP docs. That would be more representative.

Re: Things engineers believe about Web development

#144

Post by masfuerte »

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)

git is a facade and "git add" actually calls "git-add". On Windows this means separate exes, git-add.exe, git-commit.exe, git-update.exe, etc. But all these exes are actually identical. So git is multiple copies of a single program which can do many things!

Re: Things engineers believe about Web development

#145

Post by javcasas »

ryanbrunner wrote: post #98
croes wrote: post #47

Earlier quoted context omitted.

>Everything running in a browser is interpreted. That's exactly the reason for a build step. In a build step the code can be optimized to reduce and/or accelerate the code that needs to be interpreted.

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.

Re: Things engineers believe about Web development

#146

Post by Yaina »

mostlylurks wrote: post #73

> “Web development shouldn’t need a build step” A build step is a huge barrier that makes authoring your own websites require significantly more expretise than it otherwise would. It thus makes web development less accessible, and puts anything even a little bit complicated out of reach of anyone who isn't already an experienced web developer or exceptionally dedicated. It also discourages the slow development of som…

I mean, a build step is not required to build a website, but I'd say anyone who wants to have more than one HTML page and one stylesheet will probably want some sort of build step sooner rather than later.

Like, if you have two or more pages, you probably want them to share the same header or footer, and unless you want to A) repeat the same markup on each page or B) inject them with a client-side script, you will need some sort of build step. There are more accessible solutions out there, like Hugo.

How else are you going to achieve that? Sure you could use PHP, but I don't see how that is more accessible or maintainable than having a build step.

Re: Things engineers believe about Web development

#147

Post by giantrobot »

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.

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 way more jarring and experience breaking than a page load.

Re: Things engineers believe about Web development

#148

Post by giantrobot »

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…

> People who disable JS are virtually non-existent in the real world, outside of bubbles like HN comments.

Except for all the microbrowsers[0] and crawlers that don't have JavaScript enabled or don't run all the JavaScript bullshit on a page. Building accessible sites that can be used in the widest possible context is good engineering.

[0] https://24ways.org/2019/microbrowsers-are-everywhere/

Re: Things engineers believe about Web development

#149

Post by jwells89 »

kgdiem wrote: post #132
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…

> you should strive to make solutions that require the simplest tools possible whenever you can I’ve gone back to making MPA apps with minimal JS. It helps me actually ship my projects rather than tinkering and having an over complicated setup for mostly CRUD tasks. In one project that is a bit more data intensive and interactive I’m using Laravel Breeze / Laravel + inertajs (SSR react pages). I’m also a big fan of J…

A big factor in that “tinkeriness” of SPAs is how nearly every part of making an SPA well-behaved and pleasant to use falls almost entirely on the shoulders of the developer. Due to how little browsers provide on that front, well-behaved polished SPAs are very much not on the happy path or default. Even if you use the big popular libraries, special care must be taken to not build a product that’s a frustrating mess for users.

In comparison a server-side MPA will probably be at least decent to use unless the dev has been entirely careless, because that model better matches what browsers have been built for.

The takeaway is that for SPAs to be consistently good for both devs and users, browsers need to do the bulk of the heavy lifting and provide a “happy path”, largely eliminating the need for overwrought JS libraries that try to paper over browser inadequacies.

Re: Things engineers believe about Web development

#150

Post by calderwoodra »

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.

Post reply on HN