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

101–110 of 254 posts

Re: Things engineers believe about Web development

#101

Post by christophilus »

ryanbrunner wrote: post #88
christophilus wrote: post #75

Earlier quoted context omitted.

It also depends on your definition of simple. The architectural model of Preact is simple. You change state, your application renders correctly. The architectural model of an MPA with interactivity sprinkled in seems as simple, but quickly becomes more complex over time, and has ultimately not been as simple in my experience.

Preact / React is simple because it solves for a very small slice of what an application needs to do and willfully ignores the rest. For example, (P)React has no real opinion on how it interacts with a server, which is a fundamental requirement of 99% of web applications (the new server components stuff is a counterargment I guess, but even then it doesn't consider the complexities of what a backend needs to do and i…

But, that is a form of simplicity. It’s kind of the UNIX approach. I use Preact and a typed RPC client and a very simple router. The result is a reasonably small, easy-to-reason about program that I find very enjoyable to work on. If Preact shipped with their own communication layer and router, that would reduce the simplicity, and I’m not sure I’d actually like the choices they made for the part of the stack that is unrelated to rendering. Angular is an example of what you describe, and it’s not for me.

Re: Things engineers believe about Web development

#102

Post by eugenekolo »

mjburgess wrote: post #11

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

Re: Things engineers believe about Web development

#103

Post by sergiosgc »

christophilus wrote: post #87
xigoi wrote: post #74

Earlier quoted context omitted.

SPAs often require an uninterrupted internet connection even if it’s not technically necessary.

That’s not been my experience, but you may be right. Why do they require an uninterrupted internet connection?

Because they break when a request fails. MPAs have a request resubmission UI out of the box. They also have request history navigation, easy resource bookmarking and other stuff you can reimplement in an SPA but usually don't.

Re: Things engineers believe about Web development

#104

Post by ryanbrunner »

draw_down wrote: post #4

Who said every site should work without JS, even Figma? Honestly, who is saying that? Who is saying these things?

I tend to make all my pages function without Javascript even if I don't expect my users to turn off Javascript. It makes things easier to cover with automated tests if I can just exercise my backend servers with scripts vs. a headless browser, and if something does go wrong with serving Javascript or something it's nice to know my site is functional.

Generally speaking the experience will be horrible (what should be a modal or a partial page reload will be a full reload) but using the technologies I use it's not that hard and it makes my development experience easier while delivering some (rarely needed) benefits to end users, so it's an unqualified win for my particular use case.

Re: Things engineers believe about Web development

#105

Post by squidbeak »

blackoil wrote: post #62
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…

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

Accessibility workers have to hear rather too much of the "these people aren't relevant to the business" arguments. And while every business has its own concerns and priorities, standards based on exclusion don't belong on the web.

Re: Things engineers believe about Web development

#106

Post by endisneigh »

ryanbrunner wrote: post #92
endisneigh wrote: post #82

Earlier quoted context omitted.

Most professions do work like that, actually.

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

Re: Things engineers believe about Web development

#107

Post by xigoi »

christophilus wrote: post #87
xigoi wrote: post #74

Earlier quoted context omitted.

SPAs often require an uninterrupted internet connection even if it’s not technically necessary.

That’s not been my experience, but you may be right. Why do they require an uninterrupted internet connection?

I don’t know. Recently I was viewing an image in the Discord web app and it suddenly disappeared because my device had lost connection, even though the image was already fully loaded in the browser.

Re: Things engineers believe about Web development

#108

Post by ryanbrunner »

blackoil wrote: post #97
xigoi wrote: post #63

Earlier quoted context omitted.

> People disabling JS or working on satellite internet from a remote island are fringe cases and are not relevant for the business. How about people working on a train?

For most scenarios, the experience should be better with a well-designed SPA as while first load may be slow, and person may have to wait a min. Once loaded data transfer per interaction is much smaller. For a use-case of just loading a page reading it and submitting few fields on it, will be worse. But for complex things like multiple filtering, searching for different dates, seat selection it will be faster.

One difference is that server interactions on a MPA are usually more predictable. I can wait for a good internet connection to submit a form or click a link. On top of that, I'm using browser navigation to navigate a lot of the time, and while it's not impossible to provide good feedback about interactions in a SPA, many sites don't (or worse, use optimistic UI updates without handling failure states well so it's impossible to tell what's persisted and what's not).

Re: Things engineers believe about Web development

#109

Post by Aurornis »

blackoil wrote: post #62
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…

> 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 and even separate mobile apps if they’re a target market.

People who disable JS are virtually non-existent in the real world, outside of bubbles like HN comments. Building technology strategies to cater to this tiny minority is not a good decision.

Re: Things engineers believe about Web development

#110

Post by troupo »

diggan wrote: post #10
troupo wrote: post #2

While I agree with "web engine developers and web spec deveopers have little-to-no idea about web development" I disagree with "web browsers are good at handling complex and long-lived DOM trees with dynamic changes now"

> "web browsers are good at handling complex and long-lived DOM trees with dynamic changes now" Is there an alternative renderer/something that handles "complex and long-lived $something-trees with dynamic changes" better than web engines does? They've been optimized for just that during decades at this point, with huge investments both in human-hours and money. Hard to imagine there is something else that can handle…

> Is there an alternative renderer/something that handles "complex and long-lived $something-trees with dynamic changes" better than web engines does?

Literally everything else.

My favorite recent example is: 1000 objects with complex behaviour, lighting and animations takes 4 microseconds to render, at 9:36: https://youtu.be/kXd0VDZDSks?si=PjqeFVoSTPSsbdIk

> They've been optimized for just that during decades at this point

You can't optimize beyond the limitiations of the ad-hoc hackish nature of the web. There's only so much optimisation you can do when even the simplest of things will cause re-flow and re-render o the entire page.

Well, games redraw the entire screen, but they can draw thousands of objects in a fraction of time it takes the web browser to figure out how to layout them.

Edit:

- Figma had to reimplement everything from scratch in WebGL because browsers (that is, DOM) are just bad

- Google Docs and Google Sheets reimplemented everything in canvas, once again bypassing the "greatest renderer on earth" to be able to render and control the rendering.

Post reply on HN