> I personally think we should abolish JavaScript and not allow arbitrary remotely loaded code to execute on our computers.
> "I want web sites to do everything a native app can do" is a suicidal mistake.
If you think you're ceding a lot of power to Google and Apple when it comes to browsers, I fail to see how "That webapp you're building can't use Javascript so build it in Objective-C/Swift for iOS instead" would cede less power to Apple.
At least I don't need Apple's approval to build my website...
> I personally think we should abolish JavaScript and not allow arbitrary remotely loaded code to execute on our computers.
Yeah this is honestly where I stopped reading. The ship has long-since sailed on this one - on-demand software clearly wins on utility over local software in most cases, a fact which is proven by how dominant web is over native software despite it's many shortcomings.
I actually think what we need to advance software is a better stack/tooling for web to bring it closer to the native experience. I.e. I can imagine a world where my laptop is mostly a platform for running WASM/WebGPU code downloaded from network on demand - and it would be nice if that type of software was not so reliant on the browser as a middle-man.
No need to even go this far. Just have Javascript as an option, not a default. People seem to have lost sight of the fact that the web was and still is functional without all the added browser features. By all means, have the features, but making them defaults is something very different. It is denying the more basic functionality of the web. In some (read: many) cases, using the web in a more basic way without certain features reduces the amount of risk a user undertakes. Sometimes it is just plain faster and more reliable, too.
This developer-dictated "defaults" strategy is developer-friendly but user-hostile; it's why we end up with power users commenting on HN along the lines of "I can't turn off X, because then all sites will break." Most users (non-power users) cannot even turn off X because they do not even know they can. They haven't got a clue. Developers like it this way. This is some highly manipulative maneuvering; this is unethical IMO, but I think like a user not a developer.
Defaults are definitive. Perhaps that's why the current CEO of Google, before he became CEO, worked so intently to get vendors to make Google the "default search engine". Users do not change these defaults.
I think more effort should be put into cross browser support, but that said.
> "I want web sites to do everything a native app can do" is a suicidal mistake.
Most Mac users are just using MacOS as a windowing system to run Chromes browser engines multiple times across the bunch of Electron apps they use to do their work.
The age where Mac users were mostly working all day in native Cocoa apps is long dead, I think I might be the only person in my office that uses a text editor running on Cocoa not Chrome.
We didn't get here by accident, end of the day Figma is better than Sketch, Google Docs is better than passing Pages files around, Google Maps in a browser window where your actual research is happening is better than opening the Apple Maps app and Slack is better for work than Messages.
The world moved forward, Jeff might not like which tech stack it chose but no one is making anything written "natively" on Macs that can compete, and it's silly to say that it shouldn't exist while that fact is true.
I also fail to understand how "lets install native code to run on our OS" results in more security and privacy.
The browser is inherently more locked down than native apps. A Facebook app on your computer can read anything on it without any pesky browser security and privacy features getting in the way.
I think that goes back even further: The industry has invested a lot to push the concept of arbitrary automatic updates. Today it's not just normal that the code and functionality of your installed apps is constantly changing, it's almost expected. An app that doesn't get updates is considered dead.
Nevermind that this results in a system that is completely impossible to reason about, that this allows companies and corporations to play out business politics right on your hardware and that now suddenly apps can be taken over by malicious parties.
Suddenly, we need a privileged "app store" 3rd party that can constantly monitor apps and ban them, should they suddenly turn into malware.
>At least I don't need Apple's approval to build my website...
Yes. But some day you may need Apple's approval for Apple's user to visit your website due to security / privacy / or other ideology them deem unfit for their user's consumption.
Seems like the original tweet is now gone? But I do want to say, full fledged webapps have been an absolute game changer for internal tools at large companies. I can't even imagine maintaining internal tools any other way now.
Yes an independent small-time developer cannot create a browser engine from scratch today, but Apple does not fall into that category. Their choices with Safari are not born out of lack of resources or expertise but deliberate planning.
Yes large companies have seized control over the web from W3C. Apple is one of those large companies. They refuse to follow standards that they themselves dictate for others.
Yes pushing more features to the web is going to result in loss of privacy. But Apple doesn't want vanilla websites, they want developers to make iOS apps (gated behind their store) which are worse in every way.
Plus it doesn't address the biggest argument, which is that even if you say Apple can do whatever it wants with Safari, what is their rationale for blocking other browsers on iOS? It sure isn't because Apple loves the open web.
> Yes large companies have seized control over the web from W3C
The W3C is a consortium, that's what the "C" stands for. Said consortium is comprised of "very large companies" and it always has been. That's the point: cooperative game-theory.
> Yes an independent small-time developer cannot create a browser engine from scratch today, but Apple does not fall into that category.
What do you think of Mozilla and Servo? Because quite honestly, I think a moderately sized team should be able to accomplish it with enough time. Yet Mozilla canned the Servo team. It feels like practically nobody can create a standards compliant browser engine from scratch these days.
> Their choices with Safari are not born out of lack of resources
Eh, depends what you mean by "resources". Apply is (in)famously a relatively frugal and small company, given it's worth and value. Even it's native platforms, its crown jewels, suffer from this.
"Imagine a small company trying to write their own web browser from scratch nowadays. It's just not possible! "
Imagine the much more common case of a small company (or individual) trying to make a useful app that is available to everyone. If they can make it in a browser, it's possible, if they have to make it for every proprietary platform (iOS, Android, Windows, Mac, Linux...).... often impossible.
I'm happy that web browsers can do a lot. Many of the "security nightmare" arguments don't make sense. It wouldn't be a security nightmare if, for instance, Safari could allow a MIDI keyboard to talk to the web browser as it does in Chrome (ignoring Sysex support, which is the security excuse for holding it back.... there is very little need for that in a browser). God forbid I want to do a piano learning app. This is just one of many examples that may not affect you, but affects some subset of apps. (there are tons more, that one happens to affect my app) People are quick to say "I don't need that in a web browser", but you could say that about just about anything, for instance camera support.
I do look forward to a day when most apps run in a browser rather than having to be platform specific, or require giant teams of developers to be cross platform.
Cross platform is, frankly, overrated. Depending on the market you're aiming for you have a very limited set of platforms that matter and directly targeting a native look and feel, as well as accounting for hardware and OS constraints, will always produce a better experience.
Games? Target Windows and the consoles (web isn't a "real" solution on them anyway!), test on Proton if you care about Linux, and Mac isn't worth your time. Office software? Windows. Any kind of appliance (emulation station, kodi, etc), Linux. Developer tools? Linux and Windows. Bullshit addictive eyeball farming social media platform? Mobile. Artsy stuff? Mac-first and probably also Windows if you feel like it.
Even so, people were targeting many more platforms than exist today throughout the 80s and early 90s with native ports for each (or a custom VM target, see: SCUMM, Z-machine, Another World/Out of This World) and they had to deal with assembly and a lot fewer standard APIs and no universal toolkits. And they did it with fewer developers, worse tooling, and no Stack Overflow to copy-paste from. I don't really think having multiple native ports is the herculean task so many developers make it out to be.
As a Linux developer, I can test my site in Firefox and Chrome (including on my CI). I can't test it in Safari. The fact that it differs the most makes it a real pain.
I don't really care whether an iOS developer considers this "invalid". My apps support platforms that I can afford to test on, and those that are compatible.
Any time I look at the new features in Chrome, I ask myself, "whose actually using this stuff?". Even though Firefox usually keeps pace pretty well it's pretty common for implementations to differ, and thus you're on the hook for browser quirk issues in any new feature you adopt immediately. Not to mention I've always had the anchor that is IE to temper any hastiness to use a feature (even if you simply don't implement the feature for IE, that's still an extra error state to handle unless you're willing to drop IE support altogether).
It can't even be 1% of websites out there embracing this stuff. I'm guessing the biggest consumer for most of the new features in Chrome is probably Google web developers. There's quite a lot of things that only end up half implemented, too.
Although the RFC these days seems to just be a design spec doc for Google, I suspect you could carve it down to less than half of what it is and render 99.9% of websites out there just fine.
The author’s conclusion is that due to the current situation being non-optimal, we should give up on browsers all together? I’m not sure what exactly he is proposing as it’s obviously too late to turn the clock back on the existence of interactive web sites.
I don’t expect small developers to be able to make a top-notch browser engine any more than I expect them to make software equivalent to Photoshop or Final Fantasy XIV. Standards are there to guide compatibility between products of large players and content producers. Apple is not a small company compared to Google or anyone; they’re merely not trying very hard. Mozilla is somehow doing a decent job despite not having $300 billion in cash stashed away.
I do believe that browsers doing what native apps can do is reasonable and useful. The arguments about security are not particularly persuasive. The biggest threats to mobile security currently seem to be apps in official app stores.
>I don’t expect small developers to be able to make a top-notch browser engine any more than I expect them to make software equivalent to Photoshop
Specifically for this example I do strongly believe Photoshop will be dethroned in the next 5 years and the app that will achieve it will be by a <30 person dev team.
Think this is an outlier though because it's so antiquated and barely uses your computing power and the dev team clearly doesn't want to actually do anything challenging to fix it. Yet a team starting from scratch today would build it in a very different way, much more GPU focused and I think it will surprise us just how much better it is.
As a developer who started noodling on 8 bit BASIC, the power of a web browser that is essentially a universal, network-capable application engine is beyond amazing.
As a user, the constant misuse of dark patterns and the glut of careless unoptimized and insecure code and coders is nightmare fuel. Consider I grew up coding, trying to explain modern websites and web applications my folks is simply painful because quite often it just doesn't make sense. A lot of UX never actually asked a user how they want it to work, or disregarded their input.
The best websites for me are still those which adhere to pre web 2.0 design patterns. I find them easier to navigate and use, ie old reddit vs new - the new design doesn't bring anything useful other than nagware to register and install the app - reading a thread and click outside the main area by mistake, it navigates you back in history and you wait 10 seconds for all the ajax to finish popping into place. My old online banking interface was a simple list of my accounts and balances with links to common functions. The "new" app-inspired interface hides everything under animated menus and ugly graphs I don't need to want, while constant monte-carlo simulations mean basic features always move; my wife and I often have completely different UX, it's just another annoying half-baked web app with ajax popping in and out all over the place.
There's good stuff and well design applications of course. Shadertoy is amazing. For music there's fully-fledged DAW's in the browser - fantastic! Collaborative document editing in real time, brilliant!
But I think I am down with the concept of a different engine or mode for "web surfing" vs "web application execution" - it's a completely arbitrary distinction I know, but as a user I've got a completely different set of wants and needs when I'm just surfing, vs when I need an "application."
The salient issue with Safari is where lack of feature parity coincides with Apple's business interest in maintaining control over its App Store and keeping native APIs ahead of web APIs.
The situation is similar for Chrome with regard to APIs that dovetail with Google's business interests (e.g. Manifest v3 extension APIs and content blocking).
Lars Knoll is one of the main authors of KHTML, the foundation for both WebKit (powers Safari) and Blink (powers Google Chrome and Microsoft Edge). And he has this to say about this Twitter thread [1]:
--- start quote ---
He’s absolutely right. Implementing a browser engine from scratch was a lot of work in 1999/2000, it’s close to impossible today.
Safari is a bane of my life. Simple things just dont work. Like svg rendering just doesn't work unless you display none then block. It's been years since this was reported.
I think I must be missing something. Is the case here that Mozilla (an entity whose primary active project is a browser) and Apple (one of the largest tech companies in the world) can’t be expected to compete with Google in terms of features for their browsers?
I was already hesitant at the idea of somebody on Twitter telling me which criticisms are “valid”, but that premise threw me entirely.
What you're missing is that Google implementing a "feature" doesn't automatically make it a desirable thing to have. Competing doesn't mean slavishly imitating the whims of the market leader, always a step behind.
I feel you, I'm a macOS user, and I love using Safari, but for Linux users/developers , not being able to test their web apps in Safari, just because they don't have access to a Mac, is ridiculous. If I were in that position, I would not support Safari, until I can afford a Mac, or just throw a warning banner in my site for Safari users.
> Imagine a small company trying to write their own web browser from scratch nowadays. It's just not possible!
This is also because the web has a firing problem.
APIs and features barely get deprecated, even when they are obviously superceded. When they do its years and years after the fact. We also just except whacky quirks instead of fixing them and moving on.
A very clear example: we do not need CSS float anymore. It can be removed with zero impact on the development of new websites.
There's a new proposal for date-time features that replace the Date class. Except it won't, they will coexist and you have to support the Date class and all its bullshit indefinitely.
Do we really need anything other than template literals for strings?
I'm not sure what the solution is to these but an ever-growing spec seems like a big part of the problem to me.
A new implementation could choose to not add those older features, but there will always be some websites that still rely on them. Who is going to use a website that isn't able to display the sites they want?
[+] [-] dang|4 years ago|reply
A critique of Safari's influence on the web - https://news.ycombinator.com/item?id=27985783 - July 2021 (184 comments)
[+] [-] Permit|4 years ago|reply
> "I want web sites to do everything a native app can do" is a suicidal mistake.
If you think you're ceding a lot of power to Google and Apple when it comes to browsers, I fail to see how "That webapp you're building can't use Javascript so build it in Objective-C/Swift for iOS instead" would cede less power to Apple.
At least I don't need Apple's approval to build my website...
[+] [-] skohan|4 years ago|reply
Yeah this is honestly where I stopped reading. The ship has long-since sailed on this one - on-demand software clearly wins on utility over local software in most cases, a fact which is proven by how dominant web is over native software despite it's many shortcomings.
I actually think what we need to advance software is a better stack/tooling for web to bring it closer to the native experience. I.e. I can imagine a world where my laptop is mostly a platform for running WASM/WebGPU code downloaded from network on demand - and it would be nice if that type of software was not so reliant on the browser as a middle-man.
[+] [-] 1vuio0pswjnm7|4 years ago|reply
This developer-dictated "defaults" strategy is developer-friendly but user-hostile; it's why we end up with power users commenting on HN along the lines of "I can't turn off X, because then all sites will break." Most users (non-power users) cannot even turn off X because they do not even know they can. They haven't got a clue. Developers like it this way. This is some highly manipulative maneuvering; this is unethical IMO, but I think like a user not a developer.
Defaults are definitive. Perhaps that's why the current CEO of Google, before he became CEO, worked so intently to get vendors to make Google the "default search engine". Users do not change these defaults.
[+] [-] whywhywhywhy|4 years ago|reply
> "I want web sites to do everything a native app can do" is a suicidal mistake.
Most Mac users are just using MacOS as a windowing system to run Chromes browser engines multiple times across the bunch of Electron apps they use to do their work.
The age where Mac users were mostly working all day in native Cocoa apps is long dead, I think I might be the only person in my office that uses a text editor running on Cocoa not Chrome.
We didn't get here by accident, end of the day Figma is better than Sketch, Google Docs is better than passing Pages files around, Google Maps in a browser window where your actual research is happening is better than opening the Apple Maps app and Slack is better for work than Messages.
The world moved forward, Jeff might not like which tech stack it chose but no one is making anything written "natively" on Macs that can compete, and it's silly to say that it shouldn't exist while that fact is true.
[+] [-] madeofpalk|4 years ago|reply
The browser is inherently more locked down than native apps. A Facebook app on your computer can read anything on it without any pesky browser security and privacy features getting in the way.
[+] [-] danjac|4 years ago|reply
[+] [-] xg15|4 years ago|reply
Nevermind that this results in a system that is completely impossible to reason about, that this allows companies and corporations to play out business politics right on your hardware and that now suddenly apps can be taken over by malicious parties.
Suddenly, we need a privileged "app store" 3rd party that can constantly monitor apps and ban them, should they suddenly turn into malware.
That is suicidal.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] ksec|4 years ago|reply
Yes. But some day you may need Apple's approval for Apple's user to visit your website due to security / privacy / or other ideology them deem unfit for their user's consumption.
[+] [-] city41|4 years ago|reply
[+] [-] zepto|4 years ago|reply
[+] [-] paxys|4 years ago|reply
Yes an independent small-time developer cannot create a browser engine from scratch today, but Apple does not fall into that category. Their choices with Safari are not born out of lack of resources or expertise but deliberate planning.
Yes large companies have seized control over the web from W3C. Apple is one of those large companies. They refuse to follow standards that they themselves dictate for others.
Yes pushing more features to the web is going to result in loss of privacy. But Apple doesn't want vanilla websites, they want developers to make iOS apps (gated behind their store) which are worse in every way.
Plus it doesn't address the biggest argument, which is that even if you say Apple can do whatever it wants with Safari, what is their rationale for blocking other browsers on iOS? It sure isn't because Apple loves the open web.
[+] [-] DaiPlusPlus|4 years ago|reply
The W3C is a consortium, that's what the "C" stands for. Said consortium is comprised of "very large companies" and it always has been. That's the point: cooperative game-theory.
[+] [-] Shank|4 years ago|reply
What do you think of Mozilla and Servo? Because quite honestly, I think a moderately sized team should be able to accomplish it with enough time. Yet Mozilla canned the Servo team. It feels like practically nobody can create a standards compliant browser engine from scratch these days.
[+] [-] madeofpalk|4 years ago|reply
Eh, depends what you mean by "resources". Apply is (in)famously a relatively frugal and small company, given it's worth and value. Even it's native platforms, its crown jewels, suffer from this.
[+] [-] jmull|4 years ago|reply
Privacy and security.
[+] [-] layoutIfNeeded|4 years ago|reply
Same reason you can’t install custom system fonts on iOS. They want to keep the iOS experience coherent. If you don’t like it, buy Android.
Edit: a system font is a font that system dialogs use. Not just any random custom font installed in the font library.
[+] [-] robbrown451|4 years ago|reply
Imagine the much more common case of a small company (or individual) trying to make a useful app that is available to everyone. If they can make it in a browser, it's possible, if they have to make it for every proprietary platform (iOS, Android, Windows, Mac, Linux...).... often impossible.
I'm happy that web browsers can do a lot. Many of the "security nightmare" arguments don't make sense. It wouldn't be a security nightmare if, for instance, Safari could allow a MIDI keyboard to talk to the web browser as it does in Chrome (ignoring Sysex support, which is the security excuse for holding it back.... there is very little need for that in a browser). God forbid I want to do a piano learning app. This is just one of many examples that may not affect you, but affects some subset of apps. (there are tons more, that one happens to affect my app) People are quick to say "I don't need that in a web browser", but you could say that about just about anything, for instance camera support.
I do look forward to a day when most apps run in a browser rather than having to be platform specific, or require giant teams of developers to be cross platform.
[+] [-] AnIdiotOnTheNet|4 years ago|reply
Cross platform is, frankly, overrated. Depending on the market you're aiming for you have a very limited set of platforms that matter and directly targeting a native look and feel, as well as accounting for hardware and OS constraints, will always produce a better experience.
Games? Target Windows and the consoles (web isn't a "real" solution on them anyway!), test on Proton if you care about Linux, and Mac isn't worth your time. Office software? Windows. Any kind of appliance (emulation station, kodi, etc), Linux. Developer tools? Linux and Windows. Bullshit addictive eyeball farming social media platform? Mobile. Artsy stuff? Mac-first and probably also Windows if you feel like it.
Even so, people were targeting many more platforms than exist today throughout the 80s and early 90s with native ports for each (or a custom VM target, see: SCUMM, Z-machine, Another World/Out of This World) and they had to deal with assembly and a lot fewer standard APIs and no universal toolkits. And they did it with fewer developers, worse tooling, and no Stack Overflow to copy-paste from. I don't really think having multiple native ports is the herculean task so many developers make it out to be.
[+] [-] timw4mail|4 years ago|reply
[+] [-] remram|4 years ago|reply
I don't really care whether an iOS developer considers this "invalid". My apps support platforms that I can afford to test on, and those that are compatible.
[+] [-] debaserab2|4 years ago|reply
It can't even be 1% of websites out there embracing this stuff. I'm guessing the biggest consumer for most of the new features in Chrome is probably Google web developers. There's quite a lot of things that only end up half implemented, too.
Although the RFC these days seems to just be a design spec doc for Google, I suspect you could carve it down to less than half of what it is and render 99.9% of websites out there just fine.
[+] [-] code_duck|4 years ago|reply
I don’t expect small developers to be able to make a top-notch browser engine any more than I expect them to make software equivalent to Photoshop or Final Fantasy XIV. Standards are there to guide compatibility between products of large players and content producers. Apple is not a small company compared to Google or anyone; they’re merely not trying very hard. Mozilla is somehow doing a decent job despite not having $300 billion in cash stashed away.
I do believe that browsers doing what native apps can do is reasonable and useful. The arguments about security are not particularly persuasive. The biggest threats to mobile security currently seem to be apps in official app stores.
[+] [-] dmitriid|4 years ago|reply
Procreate. Acorn. Pixelmator. Affinity.
All small developers. All successful and eating a chunk of Photoshop's lunch.
Sketch and Figma outright stole Adobe's lunch.
> or Final Fantasy XIV.
Not all games have to be FFXIV to be enjoyable or playable. And indie games are thriving.
However, you require a fully-features browser to browse the modern web.
[+] [-] whywhywhywhy|4 years ago|reply
Specifically for this example I do strongly believe Photoshop will be dethroned in the next 5 years and the app that will achieve it will be by a <30 person dev team.
Think this is an outlier though because it's so antiquated and barely uses your computing power and the dev team clearly doesn't want to actually do anything challenging to fix it. Yet a team starting from scratch today would build it in a very different way, much more GPU focused and I think it will surprise us just how much better it is.
[+] [-] parksy|4 years ago|reply
As a user, the constant misuse of dark patterns and the glut of careless unoptimized and insecure code and coders is nightmare fuel. Consider I grew up coding, trying to explain modern websites and web applications my folks is simply painful because quite often it just doesn't make sense. A lot of UX never actually asked a user how they want it to work, or disregarded their input.
The best websites for me are still those which adhere to pre web 2.0 design patterns. I find them easier to navigate and use, ie old reddit vs new - the new design doesn't bring anything useful other than nagware to register and install the app - reading a thread and click outside the main area by mistake, it navigates you back in history and you wait 10 seconds for all the ajax to finish popping into place. My old online banking interface was a simple list of my accounts and balances with links to common functions. The "new" app-inspired interface hides everything under animated menus and ugly graphs I don't need to want, while constant monte-carlo simulations mean basic features always move; my wife and I often have completely different UX, it's just another annoying half-baked web app with ajax popping in and out all over the place.
There's good stuff and well design applications of course. Shadertoy is amazing. For music there's fully-fledged DAW's in the browser - fantastic! Collaborative document editing in real time, brilliant!
But I think I am down with the concept of a different engine or mode for "web surfing" vs "web application execution" - it's a completely arbitrary distinction I know, but as a user I've got a completely different set of wants and needs when I'm just surfing, vs when I need an "application."
[+] [-] Dotnaught|4 years ago|reply
The situation is similar for Chrome with regard to APIs that dovetail with Google's business interests (e.g. Manifest v3 extension APIs and content blocking).
[+] [-] kevincox|4 years ago|reply
[+] [-] cryptoquick|4 years ago|reply
[+] [-] nanis|4 years ago|reply
> Why did someone post my tweet on Hacker News?
> It's not news! It's not an announcement of anything. It doesn't contain any novel information.
> If anyone on HN is reading this tweet, post a link telling people to stop discussing my other tweet please. :-)
[1]: https://twitter.com/lapcatsoftware/status/142125132814429798...
[+] [-] dmitriid|4 years ago|reply
--- start quote ---
He’s absolutely right. Implementing a browser engine from scratch was a lot of work in 1999/2000, it’s close to impossible today.
--- end quote ---
[1] https://twitter.com/LarsKnoll/status/1421121639845187585
[+] [-] c7DJTLrn|4 years ago|reply
[+] [-] snet0|4 years ago|reply
[+] [-] shadowgovt|4 years ago|reply
Browsers are the new OS. Most attempts at a feature-complete OS that is able to run software intended for other OSes would be incredibly expensive.
Plan 9's been in development for over 29 years, and it's still niche.
[+] [-] adam_arthur|4 years ago|reply
Google and Apple are both anti-competitive in different ways.
A distinction needs to be made in regards to the anti competitive nature of controlling a large walled garden, and network effect stickiness.
Anti-trust laws will catch up and lead to regulation of big tech.
Though, we may actually see something soon with Apple depending on how the Epic case resolves.
[+] [-] PetahNZ|4 years ago|reply
[+] [-] emodendroket|4 years ago|reply
[+] [-] dTal|4 years ago|reply
[+] [-] akerl_|4 years ago|reply
I was already hesitant at the idea of somebody on Twitter telling me which criticisms are “valid”, but that premise threw me entirely.
[+] [-] dTal|4 years ago|reply
[+] [-] masterof0|4 years ago|reply
[+] [-] Griffinsauce|4 years ago|reply
This is also because the web has a firing problem.
APIs and features barely get deprecated, even when they are obviously superceded. When they do its years and years after the fact. We also just except whacky quirks instead of fixing them and moving on.
A very clear example: we do not need CSS float anymore. It can be removed with zero impact on the development of new websites.
There's a new proposal for date-time features that replace the Date class. Except it won't, they will coexist and you have to support the Date class and all its bullshit indefinitely.
Do we really need anything other than template literals for strings?
I'm not sure what the solution is to these but an ever-growing spec seems like a big part of the problem to me.
[+] [-] graftak|4 years ago|reply
[+] [-] cdirkx|4 years ago|reply
[+] [-] dewanto|4 years ago|reply
Apple strategy is NativeApps with AppStore.
Microsoft strategy is half-half.
...
Google workers complain Safari bad. That's their job. So, business as usual
[+] [-] felixfbecker|4 years ago|reply
[+] [-] coldtea|4 years ago|reply
[+] [-] MeinBlutIstBlau|4 years ago|reply
[deleted]
[+] [-] mmis1000|4 years ago|reply
Tencent do has one pretty much spec compliance browser engine (X5) for their own use. (Obviously not a small company either)
It is also a mobile only browser used mostly in China (so you are unlikely to test it during dev)
And I only got a few incompatibility reports from it (like 2 or 3?).
Compares to the nightmare on safari (dozens of bugs), it actually works surprisingly good.