The entire webstack is such a broken mess of inconsistencies and thousands of hidden traps that can render the entire thing insecure.

People moan about C yet I find the web stack greatly more painful to write because you didn't even have control over the compiler following standards strictly (where stuff has even been standardised).

I really do wish we worked together to create a new standard for building and deploying documents and applications over the internet because this HTML (and all its supporting technologies) is an experiment that has gone bad. Id preferably want something that doesn't allow each browser to interpret the specifications differently and absolutely something that isn't controlled by Google (they would obviously need input but the last thing we need is another AMP).

Of course it will never happen, but one can dream / rant nonetheless.

The web is the state it's in because it's a no-mans-land between warring proprietary vendors. Any one of Apple, Microsoft, or Google (even secondary players like Amazon, Oracle, or Valve) would much prefer a world in which they had the dominant platform and could get a 30% cut and arbitrary veto over all software written for that platform.

The problem you describe does exist but I respectfully disagree that's the reason why writing web applications has become as cumbersome as it has. I think the issue there is more down to standards authorities being glacially slow to recognise the change in demands. This has obviously allowed a situation where browser vendors such as Microsoft and Google have felt they needed to run amok just to offer many of the features developers were asking for (and to an extent, consumers too since end users were lured in by prettier and more interactive sites).

There have been other examples in history where programming languages used to differ - sometimes even significantly - depending on which compiler / platform you were targeting and where a standards body later stepped in to create a basic subset of said language that should be universal across all dialects (please note they cannot enforce this). In those instances that has lead to code to become greatly more portable.

To some extent, this is now happening with the web as well; however my secondary point to the complaint about differing outputs between browsers is that I believe HTML et al is a lousy way to design applications from the outset. That definitely is not a problem created by warring proprietary vendors or slow revisions of standards but rather just an artefact of technology evolving past it's original purpose yet still having to retain backwards compatibility. Maybe the time has come that we need a second language for the web so we have HTML et al for legacy applications, blogs and other stuff that is following some of the original visions of the web, but have a new language for web applications and anything that requires a stronger security model.

The problem is that the original concept of websecurity doesn't apply to the current time anymore, but it's very hard to change anything because you have to be backwards compatible to literally the whole internet.

It's amazing if you look at it from that point. You can't have security by default because the old standard is insecure by default (by todays means) and that's what legacy applications depend on, yet there has been a lot of progress that you can opt into.

My favorite example are cookies. While everything else is origin based, those are still based on a model that is very close to dns (everything psl+1 is the same thing). This opens you up to a large number of attacks, especially in a man in the middle situation (even with https). You can secure your own application by using secure cookie prefixes, but everything else is doomed.

I don't think there's the ultimate solution to anything. On a high-level anything seems like it can be done easily, but the issue always lies in the details.

Maybe it isn't great in all the ways, but at least it's something that works and is flexible enough for all sort of things.

It's great for document markup. But the web has moved beyond that and writing interactive applications has always been a serious of kludges to work around the fact that the web is ostensibly just a network of documents (apologies for the massive over simplification here - please bare with me on this....)

I will grant you that things have gotten better in recent years and I do agree that there isn't such thing as a perfect solution, but given we're in an era where desktop software is being fazed out in favour of web applications (and even some desktop software is now being written using web technologies - such as Electron) it really feels like we're going wholesale into using a stack of technologies that could be significantly improved if we redesigned it from the ground up taking into account:

* what we have learned form the last ~25 years of the web,

* the change in how the internet (in a broader sense) is consumed over the last 10 years

* all the lessons we've learned from the decades of desktop software development.

Plus removing all the legacy cruft which your sibling commenter highlighted has to be seen as a bonus too.

I'm not suggesting we get rid of HTML entirely, but maybe have a new programming language for the modern web - like how we have different programming languages for other areas of computing for when we have different problems we are trying to solve. eg Bash, Perl, Go and C can all be used to write CLI tools but you'd use them to target different problems.

I guess to an extent developers are trying to do this already with some of the massive tooling you get that compiles down to CSS, Javascript and so forth. Plus the experiments we see in web assembly are another example of developers trying to break free from the constraints of scripting stuff inside a document. But I'd rather see a secondary development platform that is native to the web and is more application aware and security conscious than our current situation of having to run vast and complex frameworks that still, ultimately, compile down to the same inconsistent and insecure platform that we're currently stuck with.

But as I said, this is just soapbox ranting. I couldn't see it changing without one of the powerhouses developing it largely in isolation and then we run the risk of walled gardens which - in my opinion at least - is worse than the current status quo.

Chrome's sendBeacon content-type CORS bug is another fun one:

https://bugs.chromium.org/p/chromium/issues/detail?id=490015

Genuine question: why do you feel you've cut your teeth more than most?

I.e. what kind of dev work do you do that makes you have to deal with this more than the average developer?

The main reason is that I've had to re-implement it on the server side 2 times now by sheer "luck", as well as I feel like i've just hit more of the edge cases than most just because of the areas I ended up working in (which just happened to be a handful of canvas-based apps where a couple of them needed to call out to unknown 3rd parties and I had to be very careful about using opaque responses as they would ruin the canvas).

Maybe I'm just full of myself though!

Ah. That's interesting.

And in no way I meant to imply that you were full of yourself :)

I was just curious as I've only done some front-end dev and dealing with CORS was a minor part of it and I'm always interested in HNers with niche jobs or uncommon experience.

The kind of work where you need to run javascript loaded from third party sites and make it do stuff to the user (advertisements, chat).

Not OP, but my guess... Most devs aren't frontend devs and I would categorize this as mostly a frontend developer problem.

I think:

* Most devs are at least full stack

* Most apps now-a-days interact directly/indirectly with browser

* Attributing this problem to frontend devs without understanding why CORS and issues in handling that, makes you unaware of security issues with your backend services.

FYI: I am a backend developer.

Good points. Also, the strange case of access-control-allow-origin containing a list of origins. Or rather the lack of support for the whole standard.