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

201–210 of 254 posts

Re: Things engineers believe about Web development

#201

Post by threatofrain »

onli wrote: post #56
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 d…

IMO validation / boundary code ought be shared between frontend and backend.

Re: Things engineers believe about Web development

#202

Post by inopinatus »

graypegg wrote: post #86
inopinatus wrote: post #54

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.

Riddles are also explanatory.

The best programmer I ever worked with writes drivers for a hobby.

Re: Things engineers believe about Web development

#203

Post by throwitaway1123 »

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.

I couldn't disagree more. Desktop apps are often so invasive that they almost feel like malware. Every time I install a desktop app I have to ensure that it isn't reading random files from my filesystem, snooping on my clipboard, or making itself persistent so that it restarts automatically every time I reboot my computer.

Adobe apps like Photoshop are some of the worst offenders. Sometimes I'll kill an Adobe process running in the background, only to realize that there's an additional background process ready to restart the first one. It's like playing whack a mole trying to stop all of the creative cloud junk processes. I would much rather sandbox software like that in the browser where I can close a tab and be done with it (and where I'll be prompted before an app tries to read passwords from my clipboard or access files from my filesystem).

Re: Things engineers believe about Web development

#204

Post by inopinatus »

zozbot234 wrote: post #128
danielvaughn wrote: post #78

Earlier quoted context omitted.

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

> 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. Most real-world SPA sites perform a lot more roundtrips over the network than the MPA equivalent, not less. And every roundtrip adds yet another 800ms to your update latency, plus the risk that some random…

Those who do not remember Lotus Notes are doomed to reinvent it.

Re: Things engineers believe about Web development

#205

Post by yetanother12345 »

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…

> " ... is bringing to the table is the idea ..."

Wikipedia states that

    "Keep it simple, stupid!", is a design principle first noted by the U.S. Navy in 1960 [0]
... but some coders, including yours truly, has been brought up with that principle as a keystone of programming from day one (which was decades ago). It is related to the more modern DRY principle.

If this is brought to the table now it is only seemingly so, caused by the fact that those at the table must have forgot it, or never learned it. Of course, there are also commercial interests in keeping things as complicated as possible - it could just be that these have had too much influence for too long.

[0] https://en.wikipedia.org/wiki/KISS_principle

Re: Things engineers believe about Web development

#206

Post by JackMorgan »

url00 wrote: post #142
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 com…

This exactly summarizes how this last month has felt. Weird, frustrating issues that are weirdly hard to even find documentation on.

Re: Things engineers believe about Web development

#207

Post by jameshart »

csande17 wrote: post #183
jameshart wrote: post #168

Earlier quoted context omitted.

"Currently the only site I go regularly that are JS SPAs are ...." Are you sure about that? Well made SPAs don't look like apps. They navigate seamlessly and instantly because they're not redownloading and parsing all their header and footer HTML, re-constructing a brand new DOM, loading and reinterpreting CSS, and bootstrapping a new Javascript runtime on every click. Look at https://react.dev/learn , click around t…

If I go to react.dev/learn, click on "Escape hatches" in the menu, and scroll all the way to the bottom of the page, the browser Back button no longer works because they've added nine duplicate entries to my history. If the official React documentation website can't implement SPA page navigation properly, what chance does anyone else have?

Well that bug is clearly idiotic, and makes me feel a fool for thinking react.dev would be a strong example of sane SPA architecture to link to.

The idea is sound, and the basic loading behavior is as I said (not sure what the people who are encountering 1.5 second navigation times are doing), and the existence of an implementation bug doesn't undermine the theoretical soundness of the architecture.... although, as you say, having one on the react docs is embarrassing.

Re: Things engineers believe about Web development

#208

Post by jameshart »

ryanbrunner wrote: post #188
jameshart wrote: post #179

Earlier quoted context omitted.

What part of 'insanely snappy' did you miss? There's NO NEED for a browser to reload and reconstitute the entire page context on every interaction! It's a crazy way to architect applications!

Yes, and every major MPA framework optimizes this away, the same way that SPA approaches support server side rendering so you don't see a literal blank page before the app downloads.

"every major MPA framework optimizes this away"

... wut?

Wouldn't that make them 'compile to SPA' frameworks?

Re: Things engineers believe about Web development

#209

Post by mardifoufs »

zelphirkalt wrote: post #197
mardifoufs wrote: post #191

Earlier quoted context omitted.

Do you mean the pixel 5a? Just wondering because it would make a big difference if it was nexus 5 from 10 years ago, versus a much more recent pixel 5!

Whichever it is, it should certainly not take 1.5s to open a menu. Especially not on a website, that aims to teach people something about web development.

Absolutely, but it being a pixel5a makes it much worse! But as you said, even a nexus 5 should be able to run a doc website.

Re: Things engineers believe about Web development

#210

Post by jefftk »

troupo wrote: post #125
jefftk wrote: post #93

Earlier quoted context omitted.

GDPR and ePrivacy are different regulations. Under the latter even purely local data storage still requires consent unless it's "strictly necessary" to implement something the user has requested. For example, see the discussion the sibling commenter linked around storing UI customization choices for only the duration of the current session: https://ec.europa.eu/justice/article-29/documentation/opinio...

You don't need consent in this case, as clearly stated in 3.6 UI customization cookies --- start quote --- 3.6 UI customization cookies These customization functionalities are thus explicitly enabled by the user of an information society service (e.g. by clicking on button or ticking a box) although in the absence of additional information the intention of the user could not be interpreted as a preference to remember…

See discussion above: https://news.ycombinator.com/item?id=38901520

As long as it's clear to the user that they're making a site-wide UI customization choice and just not choosing the language for this specific example I agree with you, but I don't think it's clear in the typical case.

Post reply on HN