Live data from Hacker News

Things engineers believe about Web development

birtles.blog

81–90 of 254 posts

Re: Things engineers believe about Web development

#81
post #74

Earlier quoted context omitted.

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.

Many of them use 'websockets', which break when you have interrupted connectivity.

Re: Things engineers believe about Web development

#82
post #80

Earlier quoted context omitted.

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

Most professions do work like that, actually.

Re: Things engineers believe about Web development

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

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

Re: Things engineers believe about Web development

#84

Earlier quoted context omitted.

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.

Physicists work on interesting problems. Developers work on profitable problems, mostly manufactured, for huge piles of money, from home, and with yoga over lunch.

Re: Things engineers believe about Web development

#86

The tech sector is riddled with such divisions of perspective. ”In a high-level language like C...” - chip designer ”In a low-level language like C...” - application programmer

“Riddled” has a tinge of negativity to it. I would say it’s actually a useful thing, “level” is a count of abstraction layers relative to the abstraction you’re familiar with. It’s more just a way to communicate some personal responsibility/knowledge range. I’ve heard people call Python “a low level way of using a computer” or similar.

Re: Things engineers believe about Web development

#87
post #74

Earlier quoted context omitted.

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.

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

Re: Things engineers believe about Web development

#88

Earlier quoted context omitted.

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

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 is essentially a "put backend stuff here" slot)

MPA frameworks tend to present themselves as complete and batteries included. If you're using Rails, you can build a complete application without thinking about a single other library than what Rails ships with.

Neither approach is correct, but comparing them is like saying that HTML is so much simpler than C++ so everyone should use HTML.

Re: Things engineers believe about Web development

#90

Earlier quoted context omitted.

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.

Physicists work on interesting problems. Developers work on profitable problems, mostly manufactured, for huge piles of money, from home, and with yoga over lunch.

Maybe you just haven't looked for better jobs. Because although I've read about what you're describing, I haven't seen it yet in real life.

I'm not planning on experiencing it either in the future. Though I'm sure some people like this kind of environment, and good for them.

Post reply on HN