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

51–60 of 254 posts

Re: Things engineers believe about Web development

#51

Post by ryanbrunner »

rezonant wrote: post #42
ryanbrunner wrote: post #38

Earlier quoted context omitted.

Particularly with the web though, you're very rarely completely locked into one front end technology. It's 100% reasonable to say "this particular complex interaction should use React" without needing to port the entire application. I'm sure even Photoshop and Figma could build their account management or settings pages with MPA if they wanted to - I don't use them and have no idea if they do, but "some parts of my a…

Absolutely, but it's a matter of tradeoffs and where you place them. It's still plenty common to use an MPA framework like Rails or Django for the management or CMS portion of your solution, while using an SPA framework for your front presentation. It's much more acceptable to say "doing that for this staff workflow is hard to do with our stack" than "doing this for our customers is hard to do with our stack".

Sure! I think it's just a question of scale and knowing your problem. If it's "the entire customer-facing area needs a large amount of interactivity" then going with a SPA makes sense. If it's "this particular UI element on the customer app needs a large amount of interactivity", that's easy to build as an isolated component regardless of the technology of the rest of the app.

One thing that I'll always view as a smell though is "we don't need X now, but we might need X in the future, so we should adopt this more complex technology just in case". We've learned that lesson MANY times as developers, it's not any less true for front-end technologies.

Re: Things engineers believe about Web development

#52

Post by diggan »

Const-me wrote: post #50
diggan wrote: post #10

Earlier quoted context omitted.

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

On Windows, WPF is better: https://en.wikipedia.org/wiki/Windows_Presentation_Foundatio... The critical features missing from HTML are data binding and data templates. Last time I checked, many modern frontend frameworks contain overcomplicated, incomplete, and inefficient implementations of these features on top of HTML DOM.

I'm not super familiar with Microsoft's offerings, but is WPF available cross-platform? It's hard to argue something that is only on one platform is better when it only have to do 25% of what a cross-platform solution would do.

Re: Things engineers believe about Web development

#53

Post by sidlls »

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.

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.

Re: Things engineers believe about Web development

#55

Post by bacro »

Recently I was reading the Learn CSS the pedantic way book and the definition for inline boxes did not match the way that anonymous block boxes were generated when an inline-level element had a block-level element as its child. So I went looking elsewhere for a more appropriate definition for that case and found this issue on standards: https://github.com/w3c/csswg-drafts/issues/1477 It was really interesting to know that I was not the only one confused. My question was: Does the inline-box generated by the inline-level element contains the box generated by the block-level child or there wasn't an inline-box that was a parent of them all but there were 2 siblings inline-level boxes of the block-level box that were wrapped in another anonymous block boxes? Reading that issue I got to know the concept of fragments, which I did not know browsers had. But the issue seems to suggest that the box tree for this case should have the inline-box as being a parent of the block-box. Which led me to another question, in that case, if I apply a border to the parent inline-level element, shouldn't it apply to the overall box that is generated (it does not)? The answer is that borders between block-boxes and inline-level boxes should not intersect but that is really difficult to derive from reading the standards alone. Anyway it was headache-inducing trying to learn the box-model pedantically :) I wish I could learn more about layout in browsers and I trying to read the code of LayoutNG in Chromium but I need more aspirin hehehe

Re: Things engineers believe about Web development

#56

Post by onli »

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…

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 dev can't anticipate how they will grow in advance?

But what has validation to do with it? That's completely backend, how would that have been easier with React+Next?

> As an aside, I was surprised that getting HMR with C# is kind of a pain.

Proper systems dynamically interpret their templates on every request in dev mode because of this, like Ruby/Sinatra does.

Re: Things engineers believe about Web development

#57

Post by jayceedenton »

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, beneficial for those enthusiastic about SPAs but much harder to defend.

The only way to tease this issue apart is to stick to specifics and avoid casting SPAs or MPAs as universally good or bad. Show me the use-case and we can decide which route is best.

Re: Things engineers believe about Web development

#58

Post by icedchai »

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.

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.

Re: Things engineers believe about Web development

#59

Post by Xeamek »

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

>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

Post reply on HN