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

71–80 of 254 posts

Re: Things engineers believe about Web development

#71

Post by ryanbrunner »

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…

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.

Re: Things engineers believe about Web development

#72

Post by [deleted] »

endisneigh wrote: post #8
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 for the simplest tool possible, and even further, you should strive to make solutions that require the simplest tools possible whenever you can. Why do you believe this? I couldn’t disagree more. People should strive for the most effective tool, and most of the time that’s what they already know, unless some new tools’ efficacy outweighs cost to learn it

[deleted]

Re: Things engineers believe about Web development

#73

Post by mostlylurks »

> “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 some pet website of a not-primarily-a-web-developer-by-trade into something more featureful, since expanding beyond the point where you can still reasonably avoid a build step suddenly requires acquiring a lot more exprertise and expending a lot of effort all in one go, instead of just being a smooth expansion into a more featureful project.

The simpler it is to make your own website without having extensive web development experience, the more people will be able to have their own website instead of being directed to the endless array of corporate silos like social media (which has largely replaced personal websites) and corporate middlemen (which have largely replaced in-house commercial websites for smaller actors) that take care of the burden of making your own website for you, with some rather obvious downsides.

Re: Things engineers believe about Web development

#74

Post by xigoi »

christophilus wrote: post #70
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?

Their experience shouldn’t be much different on an SPA vs an MPA. If they can do an MPA round trip involving a medium-size image, then they should be able to load an SPA.

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

Re: Things engineers believe about Web development

#75

Post by christophilus »

endisneigh wrote: post #8
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 for the simplest tool possible, and even further, you should strive to make solutions that require the simplest tools possible whenever you can. Why do you believe this? I couldn’t disagree more. People should strive for the most effective tool, and most of the time that’s what they already know, unless some new tools’ efficacy outweighs cost to learn it

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.

Re: Things engineers believe about Web development

#76

Post by lacerrr »

sidlls wrote: post #53
ko27 wrote: post #13

Earlier quoted context omitted.

It's funny that you, and probably a lot of HN folk, consider MPA simpler than SPA. It's opposite in my experience. The name itself is actually telling you that it has more complexity (multi page vs single page). In practice, you can make both as complicated as you want, but SPA seems like a simpler starting point.

How is SPA a simpler starting point? It requires more code and more abstractions in the client from the onset. One might argue that that complexity would just exist in the backend in an MPA, but that's not true: there is some additional backend complexity, but not nearly as much as required to support the multitude of clients that exist for the baseline in an MPA.

Because in most web apps you still need to have client-side logic anyways, like form validation and such, so familiarizing yourself with a SPA framework is simpler than learning to implement this in addition to the MPA framework you'll probably end up using anyway.

Re: Things engineers believe about Web development

#77

Post by christophilus »

pi-e-sigma wrote: post #61
seszett wrote: post #44

Earlier quoted context omitted.

I feel like we live in completely different worlds.

You have never seen the resume-driven development? Lucky you, because it's the vast majority of development out there

Without a study of some sort, we’re just exchanging anecdotes. I’ve seen resume-driven development a handful of times in my 20-year career. You may be right, but we won’t know until we come up with some way to measure it.

Most developers I’ve worked with have just been interested in solving problems.

Re: Things engineers believe about Web development

#78

Post by danielvaughn »

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

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 editors like Figma, you often have interactions based on key repeats, which usually fire at 50-200ms intervals. So client-side rendering is really the only feasible option.

Re: Things engineers believe about Web development

#79

Post by blackoil »

ko27 wrote: post #13
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…

It's funny that you, and probably a lot of HN folk, consider MPA simpler than SPA. It's opposite in my experience. The name itself is actually telling you that it has more complexity (multi page vs single page). In practice, you can make both as complicated as you want, but SPA seems like a simpler starting point.

It is the spectrum of interactivity. If you are a CPP/AI/Go dev who needs a static blog with simple form, you'll believe server rendered MPA are way to go. If your site has interactivity and dynamic status/notifications, you'll believe SPA makes sense. Unfortunately like in everything now days people assume other side is idiot and pick up pitchfork.

Re: Things engineers believe about Web development

#80

Post by Xeamek »

endisneigh wrote: post #65
Xeamek wrote: post #59

Earlier quoted context omitted.

>most of the time that’s what they already know, unless some new tools effficacy outweighs cost to learn it ....which any proponent of the new tool will argue it does

Yes which is why you should generally stick with what you know until you have an actual problem that needs solving… SPA, MPA, who cares. Ship.

That's not how anything in the world works though
Post reply on HN