Live data from Hacker News

Things engineers believe about Web development

birtles.blog

231–240 of 254 posts

Re: Things engineers believe about Web development

#231
post #56

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…

Sorry, but what’s wrong with microsoft docs?

Re: Things engineers believe about Web development

#232
post #227

Earlier quoted context omitted.

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

I think you're discounting (1) the fact that there is only one front end runtime, and any number of backend runtimes (2) the application is distributed across a network.

Those are the reasons why SPA and MPA are so different

Re: Things engineers believe about Web development

#233
post #226

Earlier quoted context omitted.

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

> but in practice browsers are much better sandboxes than desktop operating systems.

Do you know anything about sandboxing, or are you throwing that there for the sake of the argument?

> I would imagine writing a new desktop os would be even more complex than writing a browser app that runs on top of it.

Oh right, I guess you don't really know about sandboxing then. So it won't be a super constructive debate given that your position is apparently fundamentally based on your intuition about sandboxing.

> As a user I [...]

I don't know who invented that "As a user" thing, but I find it completely stupid. In my view it is just used as a justification for anything one wants when they don't have a better argument.

In this case users are perfectly fine running standalone apps on their smartphone, let's not pretend they would really not want the same model on their desktop.

> which to me feels like an implicit concession that desktop operating systems are indeed bad at sandboxing applications.

Not at all, I was just giving a real-world example of sandboxing of apps at scale.

> even mobile operating systems pale in comparison to a web browser when it comes to sandboxing

If your baseline is sending a full web browser with every app you make, on desktop you could run each app in a VM and it would obviously be better.

> A website can't even make a request to a third party domain unless the website has cors enabled.

An app can't make a request unless it has the internet permission, what's your point?

My point is that webapps move everything into the browser, going towards a world where something like ChromeOS is the only valid way to use a computer. I want to choose my OS, I don't want to rent an OS provided by BigTech, whether it is ChromeOS, Windows or anything else. The model where users pay for a product but don't own it is good for companies, not for users. "As a user", I want to own the product I pay for. And I want to pay for the product I want to own.

Re: Things engineers believe about Web development

#234
post #140

Earlier quoted context omitted.

A fun metaphor. A SPA-inclined team/consultancy/department will retreat to their motte when necessary. They'll live to fight another day. Given a chance, they'll return to the bailey, advocating for SPAs under a relaxed standard. Using this metaphor can imply significant disingenuity: a lack of honesty about one's true belief.

> Using this metaphor can imply significant disingenuity: a lack of honesty about one's true belief. I actually disagree. I think this is the natural state of people, and they come by it honestly. We make decisions emotionally and then justify them rationally. It's just the way we are. You could maybe say it's a lack of honesty about one's true belief to themselves . But even then it's hard to fault somebody for lack…

Two things. First, yes, people can deceive themselves. To the extent this is true, I take your point; it isn’t a matter of honesty in the usual sense; it is perhaps better stated in terms of self inconsistency; i.e. having internal contradictions in one’s beliefs.

Second, people do can and do lie about this kind of thing. I’m talking about conscious deception. Motives vary; they range from “I’ll pick my battles” to “this is good for my income stream” to “these other people don’t know it yet, but I’m right, and they’ll thank me later” and others.

Re: Things engineers believe about Web development

#235
post #140

Earlier quoted context omitted.

A fun metaphor. A SPA-inclined team/consultancy/department will retreat to their motte when necessary. They'll live to fight another day. Given a chance, they'll return to the bailey, advocating for SPAs under a relaxed standard. Using this metaphor can imply significant disingenuity: a lack of honesty about one's true belief.

> Using this metaphor can imply significant disingenuity: a lack of honesty about one's true belief. I actually disagree. I think this is the natural state of people, and they come by it honestly. We make decisions emotionally and then justify them rationally. It's just the way we are. You could maybe say it's a lack of honesty about one's true belief to themselves . But even then it's hard to fault somebody for lack…

> … I think pointing out this human tendency and calling it out with examples like this is the best way to combat it. Once people become aware of it, they are more likely to fight it internally.

Sometimes that works. Sometimes it just causes people to dig in deeper.

Re: Things engineers believe about Web development

#236
post #95

Earlier quoted context omitted.

As long as it’s implemented as a session cookie (or local storage as IIRC it also behaves as a session cookie) it should not need consent (as per 3.6 “UI customisation cookies” of https://ec.europa.eu/justice/article-29/documentation/opinio... )

I agree for something that's clearly customizing the UI of the whole site, but if it looks like you're choosing a language only for the currently displayed snippet then I think that wouldn't qualify?

I think it still qualifies - in the guidance doc (and a related doc focused on tracking cookies) the focus is on the purpose of the cookie - the intention is to avoid tracking the user - a session cookie that is specifically for remembering a choice a user made in relation to the UI passes the test of a) being necessary to enable a piece of functionality and b) being set as a result of an explicit action on the part of the user in clicking on the particular language tab.

Re: Things engineers believe about Web development

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

Sorry, but what’s wrong with microsoft docs?

Didn't necessarily say they is something wrong with them :) Though in this specific case the ones I skimmed did not look very useful, and in general they are organized quite differently than FOSS projects usually organize their code, was my impression so far.

Re: Things engineers believe about Web development

#238
post #233

Earlier quoted context omitted.

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

> but in practice browsers are much better sandboxes than desktop operating systems. Do you know anything about sandboxing, or are you throwing that there for the sake of the argument? > I would imagine writing a new desktop os would be even more complex than writing a browser app that runs on top of it. Oh right, I guess you don't really know about sandboxing then. So it won't be a super constructive debate given th…

> I don't know who invented that "As a user" thing, but I find it completely stupid. In my view it is just used as a justification for anything one wants when they don't have a better argument.

> "As a user", I want to own the product I pay for.

Ironically, you're the one who lacks a concrete argument, which is why you're attacking the wording of my statement, rather than the substance of it. You're honing in on the first three words of my sentence, because you can't debate the argument on its merits. You then use the exact same wording in your final sentence, but encase it in quotes as if that somehow absolves you of your hypocrisy. Given that this website is frequented by software developers, I think there's a useful distinction to be made between thinking about problems in terms of their development, versus thinking about them in terms of their utility to end users.

> Not at all, I was just giving a real-world example of sandboxing of apps at scale.

It would be charitable of me to call it a "real-word example". You simply said "Android does that sandboxing by default", without a single supporting statement or example, despite your so-called extensive knowledge of sandboxing.

> If your baseline is sending a full web browser with every app you make, on desktop you could run each app in a VM and it would obviously be better.

No one is "sending a full web browser with every app you make". Browsers come preinstalled on every popular operating system.

> An app can't make a request unless it has the internet permission, what's your point?

What in the world is "the internet permission"? I've never had an operating system ask me if I'd like to grant an app "the internet permission". Have you operated a computer before?

> Do you know anything about sandboxing, or are you throwing that there for the sake of the argument?

> Oh right, I guess you don't really know about sandboxing then. So it won't be a super constructive debate given that your position is apparently fundamentally based on your intuition about sandboxing.

As someone who's written both web apps and desktop apps, I do in fact know a considerable amount about sandboxing. Do you know anything about sandboxing? You're questioning my knowledge to deflect from your lack of a coherent rebuttal. What exactly have you written during this conversation to demonstrate your comprehensive knowledge of sandboxing? You're concluding that I lack knowledge on sandboxing because I admitted to not having single-handedly written an operating system or web browser? Really? Are you writing an OS in your free time when you're not writing about the mysterious "internet permission"?

> My point is that webapps move everything into the browser, going towards a world where something like ChromeOS is the only valid way to use a computer. I want to choose my OS, I don't want to rent an OS provided by BigTech

You've got it backwards. If I want to add support for users running a free open-source operating system like Linux, as a web app developer I don't have to do anything special. Linux can run web browsers, and therefore it can run web apps. Case in point is Photoshop. Neither Photoshop nor the rest of the Adobe Creative Suite runs on Linux, but the Photoshop web app does, because web apps are universal. There's a reason why Apple took years to finally add push notification support to iOS web apps, because web apps threaten the mobile operating system duopoly.

Re: Things engineers believe about Web development

#239
post #95

Earlier quoted context omitted.

I agree for something that's clearly customizing the UI of the whole site, but if it looks like you're choosing a language only for the currently displayed snippet then I think that wouldn't qualify?

I think it still qualifies - in the guidance doc (and a related doc focused on tracking cookies) the focus is on the purpose of the cookie - the intention is to avoid tracking the user - a session cookie that is specifically for remembering a choice a user made in relation to the UI passes the test of a) being necessary to enable a piece of functionality and b) being set as a result of an explicit action on the part…

I think the place where it gets tricky is whether you're meeting the "strictly necessary in order to provide an information society service explicitly requested by the subscriber or user" standard. If the control looks like it only affects the current box, then I don't think storing the choice to apply beyond the current page meets that standard.

Re: Things engineers believe about Web development

#240
post #233

Earlier quoted context omitted.

> but in practice browsers are much better sandboxes than desktop operating systems. Do you know anything about sandboxing, or are you throwing that there for the sake of the argument? > I would imagine writing a new desktop os would be even more complex than writing a browser app that runs on top of it. Oh right, I guess you don't really know about sandboxing then. So it won't be a super constructive debate given th…

> I don't know who invented that "As a user" thing, but I find it completely stupid. In my view it is just used as a justification for anything one wants when they don't have a better argument. > "As a user", I want to own the product I pay for. Ironically, you're the one who lacks a concrete argument, which is why you're attacking the wording of my statement, rather than the substance of it. You're honing in on the…

> Ironically, [...] You then use the exact same wording in your final sentence

Thanks for explaining to me what I did ;-).

> You simply said "Android does that sandboxing by default", without a single supporting statement or example

Are you questioning the fact that Android apps are sandboxed? If yes, you may need to do some reading on your own. I am not here to teach you how Android works.

> No one is "sending a full web browser with every app you make".

All the webapps that try to look like Desktop apps have to ship a browser with them. You mentioned VScode, right?

> What in the world is "the internet permission"? I've never had an operating system ask me if I'd like to grant an app "the internet permission". Have you operated a computer before?

Oh come on... you just don't have the slightest idea how native apps work, do you? It's literally called "android.permission.INTERNET". Have you ever tried something not web?

> Are you writing an OS in your free time when you're not writing about the mysterious "internet permission"?

As a matter of fact, not an OS but embedded distributions. That... wait for it... use sandboxing. Do I need to get back on the "mysterious" internet permission? Wait, here's a link to help you: https://developer.android.com/develop/connectivity/network-o....

> as a web app developer I don't have to do anything special.

Not even Google "Internet permission" before dismissing someone's point. I love that kind of webapp developers.

> because web apps threaten the mobile operating system duopoly.

They threaten every platform by making everything a ChromeOS system (no, not literally ChromeOS, but something based more and more around Chromium, which is owned by Google).

Post reply on HN