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

221–230 of 254 posts

Re: Things engineers believe about Web development

#221

Post by skydhash »

mardifoufs wrote: post #192
traverseda wrote: post #21

Earlier quoted context omitted.

For stuff like figma and photoshop I can't help but suspect that the creators would be better of writing their program in CPP with the GUI toolkit of their choice, and compiling it for the web with emscripten.

Why? If there's one thing JavaScript and browser tech is good at, it's making GUI dev easier. Just look at how even Qt is basically pivoting completely towards QML which to my naive eyes look very very similar to how GUI/Layouts/styling is done with html5/Js. Why would you purposefully use something worse just to not use browser related tech? I would agree if this was about raw number crunching, where compiling to wa…

It’s reactive/declarative UI programming, which Android does with Jetpack Compose, and iOS and MacOS with SwiftUI. The other way is doing imperative UI, like the web was doing with jQuery.

Re: Things engineers believe about Web development

#222

Post by troupo »

jefftk wrote: post #210
troupo wrote: post #125

Earlier quoted context omitted.

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.

IMO this is splitting hairs, and no one will take you to court because you changed the snippet language across the entire site for the session

Re: Things engineers believe about Web development

#223

Post by skydhash »

threatofrain wrote: post #201
onli wrote: post #56

Earlier quoted context omitted.

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.

You can never trust the client. The only thing that you can do is warning about bad input, aka UI decorations.

Re: Things engineers believe about Web development

#224

Post by sfn42 »

aatd86 wrote: post #130
jayceedenton wrote: post #57

Earlier quoted context omitted.

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

Strangely enough, this dichotomy seems to exist only for the web platform. Everywhere else (desktop, mobile etc) the model is SPAs. The only reason people distinguish it for web is because of legacy: html + DOM, i.e. Documents. Documents don't generally require programmers even if using lateX. Both models can coexist. I believe that SPAs somewhat supersede MPAs and that an MPA can be a simplification sometimes for a…

To me, the core of this entire issue is complexity and where it belongs.

My view is that you should perform as much processing as possible in the backend. This allows you to send as little data as possible over the network and allows your application code to make more sense because all your domain logic is centered in one self-contained app.

Now this self-contained app is just a software library, it doesn't do anything on it's own. But you can throw a CLI on top of it and use it through the terminal. You put a web api on top of it and use it from an SPA. You can use it as a backend for a server side rendered app.

The ideal, in my eyes, is that th frontend only concerns itself with actually displaying things. It doesn't get a big list of data, filter and transform the data, then display it. It asks the backend for exactly what it needs and the backend provides exactly what it needs and it displays it and that's the end of it.

Now you can have a website and a mobile app that are both trivial to develop and both use the same backend - if you fix a bug in the backend you've fixed it on both frontends.

I realize this may not always be possible or practical, but I think it is both of those things more often than not.

Re: Things engineers believe about Web development

#225

Post by ksec »

jameshart wrote: post #207
csande17 wrote: post #183

Earlier quoted context omitted.

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

>The idea is sound, and the basic loading behavior is as I said

Yes, and that is why despite hating the idea from the get go, which was before 2009. I gave it plenty of time to mature. But the truth is, any technology is only as good as the human factor. We aren't perfect, and that is why even basic thing like this we would make mistake.

And this example just proves it even more. And I am ignoring the site's performance which felt really slow for what should be a MPA ( and it is not ).

Re: Things engineers believe about Web development

#226

Post by palata »

throwitaway1123 wrote: post #203
palata wrote: post #139

Earlier quoted context omitted.

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

You can sandbox desktop apps, you don't need to run them in a browser that is so complex that nobody can even imagine writing a new one.

For instance Android does that sandboxing by default.

Re: Things engineers believe about Web development

#227

Post by pas »

paulddraper wrote: post #181
chriswarbo wrote: post #136

Earlier quoted context omitted.

> Strangely enough, this dichotomy seems to exist only for the web platform. > Everywhere else (desktop, mobile etc) the model is SPAs. It exists for CLIs too, where some projects provide a collection of single-purpose programs (e.g. imagemagick) and others provide a single program which can do many things (e.g. git)

No not really. Yes there are two approaches, but you can switch between the two with 98% of the code intact.

and you have identified the problem. web dev tooling, despite the extreme churn, is still absolutely poo-poo to use the technical term.

of course, mostly because very few oh-new-shiny-woah-such-modern tools doesn't even attempt to solve the problem of backend-frontend state sync. sure, maybe you get a piece of the puzzle (eg. a library that conveniently rerenders on state change, React, or one that you can wire up with all the fancy observables, Angular, or one that's super simple, sleek, even has magical runes that help with only rerendering the things affected by the state change, Svelte ... and maybe on top of these you get a state manager library, and then you still end up writing a thousand mutator/reducer in Redux by hand).

So we are still nowhere near a nice end-to-end full-stack tool that helps model both backend and frontend changes and then helps to design and implement an efficient API between them. (Because, obviously, it seems that this is not obvious to most people. Hence we get solutions like expose your DB as REST API and ship your DB via WASM sqlite, and so on.) That said, even those might be better than one more frontend-only state management lib.

Re: Things engineers believe about Web development

#228

Post by omnimus »

amadeuspagel wrote: post #143

> There are Twitter/X polls, for example, but they tend to only be answered by the Web developers on the bleeding edge and are easily skewed by who spreads the word about the poll. Maybe MDN should have a comment section, like the PHP docs. That would be more representative.

The PHP docs comment section is pretty fascinating. I am not sure how these are allowed. But you will find 10year old comments with very distilled specific techniques or super well explained nuances. Not something i've seen in other languages.

Re: Things engineers believe about Web development

#229

Post by ryanbrunner »

jameshart wrote: post #217
csande17 wrote: post #216

Earlier quoted context omitted.

I think GP is talking about solutions like https://turbo.hotwired.dev/ , which just paste server-generated HTML into the page instead of passing JSON into a client-side UI framework.

.... which is an SPA architecture. > During rendering, Turbo Drive replaces the current element outright and merges the contents of the element. The JavaScript window and document objects, and the element, persist from one rendering to the next. So... it makes your app into an SPA.

Does SSR make React a MPA? If "MPA" limits us to only frameworks that have to do a full browser navigation for every interaction, it's a pointless discussion - "MPA" frameworks have had these sorts of optimizations for a decade+ (Hotwire is the newest, but there was Turbolinks before that and PJAX before that). Sure, I'll agree that React is a better approach than using the 2005 version of a framework, but that's not useful.

Architecturally, you'll still designing your application as though the user is performing a complete navigation, there's just Javascript present to optimize away some of the issues with that approach.

Re: Things engineers believe about Web development

#230

Post by throwitaway1123 »

palata wrote: post #226
throwitaway1123 wrote: post #203

Earlier quoted context omitted.

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…

You can sandbox desktop apps, you don't need to run them in a browser that is so complex that nobody can even imagine writing a new one. For instance Android does that sandboxing by default.

> You can sandbox desktop apps

You can do a lot of things in theory, but in practice browsers are much better sandboxes than desktop operating systems.

> a browser that is so complex that nobody can even imagine writing a new one.

I'm not sure how this is relevant? As a user I don't care how complex a browser is. I care that it sandboxes applications better than my desktop operating system. Unless you mean to say that the complexity implies a greater surface area for security related bugs, in which case surely the underlying os is even more complex (which is what native apps run on). I would imagine writing a new desktop os would be even more complex than writing a browser app that runs on top of it.

> For instance Android does that sandboxing by default.

Ok, so now we're talking about mobile operating systems rather than desktop operating systems, which to me feels like an implicit concession that desktop operating systems are indeed bad at sandboxing applications.

But even if we do shift the goalposts — even mobile operating systems pale in comparison to a web browser when it comes to sandboxing. Android and iOS will notify you if an app reads from the clipboard (which they've only recently started doing), but your browser won't just notify you, it'll ask you to confirm before a website reads from the clipboard. A website can't even make a request to a third party domain unless the website has cors enabled. And new vulnerabilities pop up all the time. There was an article that generated a lot of traction on HN just a few weeks ago about how certain iOS applications can pinpoint your location by scanning for known hot spots your device has access to [1].

[1] https://news.ycombinator.com/item?id=38720656

Post reply on HN