4 ms·
1. "Lil' indie dev can make an engine" is irrelevant in terms of standards or browser/engine marketshare unless he can obtain significant browser/engine markets
by concinds 1y ago
1. "Lil' indie dev can make an engine" is irrelevant in terms of standards or browser/engine marketshare unless he can obtain significant browser/engine marketshare. He can't. So framing the current state of the browser engine market/"monopolies" as a barriers-to-entry problem with engine/standards complexity is completely nonsensical. Especially when engines are fully open-source.
2. Super-simple engines that any indie can solo-code means disregarding 95% of feature demands by web developers (your audience, remember?), even basic things like encryption, video/audio streaming, chatting, conferencing, that users (your "actual" audience) expects and demands. It means killing basically every part of the web that isn't text documents, which means turning everything else into native apps beholden to their own monopolies, that are mostly crappy (contractor-made, less sandboxed/secure than on the current web). That's also nonsensical, if your objective is "consumers". And it means making every company's revenue dependent on Apple/Google/MS instead of a web domain they control.
Really you should examine your assumptions and logic far more thoroughly.
- lapcat 1y ago> "Lil' indie dev can make an engine" is irrelevant in terms of standards or browser/engine marketshare unless he can obtain significant browser/engine marketshare. He can't. How is market share relevant? What would be wrong with designing simple web standards and as a result having 1000 options each with 0.1% market share? > Super-simple engines that any indie can solo-code This is a straw man. > video/audio streaming There used to be browser plugins for things like this. > web developers (your audience, remember?) > users (your "actual" audience) Which is it? Catering almost exclusively to web developers, as the browsers have done, unfortunately, is not in the best interest of web users. > native apps beholden to their own monopolies, that are mostly crappy (contractor-made, less sandboxed/secure than on the current web) This is false. > And it means making every company's revenue dependent on Apple/Google/MS This is true regardless, native or web. And people like the article author like to claim that Apple is forcing companies to write native apps, but notice that on Android, where there are alternative web browser engines, these same companies still write native apps. That's not because WebKit is bad, because WebKit is irrelevant on Android. Rather, it's because smartphone browsing is generally inconvenient and also native apps offer some inherent advantages over web pages. To be clear, monopolies are bad, both for operating systems and for web browsers. But turning web browsers into operating systems won't break the current monopolies, because it's the same companies in either case. The unfettered market has failed. We really need democratic governments to break up the monopolies. Whether that will happen or not remains to be seen. > instead of a web domain they control. Do you even "control" a web domain? Web browsers can throw scary warnings over http and force you to adopt https certificates. Then the web browsers can decided which certificate vendors to trust or distrust. And all the web browsers have so-called "safe browsing" that can arbitrarily decide, with no warning and no resource, that your domain is unsafe.
- concinds 1y agoMarket share is relevant to your argument because it determines the standards that determine engine complexity. > turning web browsers into operating systems won't break the current monopolies, because it's the same companies in either case False. Linux is a perfectly great mainstream desktop option thanks largely to web apps (+Electron). Basically everything's available. How incredible is that? Or swap Linux with any other alternative. The fact is you can make an indie engine right now. It won't support most of the web, but then again you don't want any of that to exist because of the additional barriers to entry for engines. So what's the problem? Make it. In your world, somehow every platform vendor stops making web browsers, and we might have a bunch of browsers with 0.1% marketshare. How? Ludicrous. And proprietary browser plugins, really? So you're not looking to reduce complexity after all, then? Again I don't think you've thought it through.
- lapcat 1y ago> Market share is relevant to your argument because it determines the standards that determine engine complexity. I talked about two different things, (1) what is and (2) what should be. (1) "The web standards bodies are a joke now because of the dominance of these few companies over web browsers". (2) "the web standards should be so simple that a little indie developer could write a full-fledged web browser." You appear to be criticizing (2) by assuming (1), but (1) is the opposite of (2). The latter is an ideal, not the sad reality. > Linux is a perfectly great mainstream desktop option Linux is not a mainstream desktop option, because consumers can't walk into a computer retailer and buy a desktop running Linux. That's why Linux has a practically nonexistent consumer market share. Of course techies can run Linux, though I wouldn't call Electron apps "great" by any measure. > In your world, somehow every platform vendor stops making web browsers, and we might have a bunch of browsers with 0.1% marketshare. How? Ludicrous. It was purely a hypothetical scenario. The point of the hypothetical scenario was to explain why market share shouldn't be relevant to standards (as I also explained at the beginning of this comment). > And proprietary browser plugins, really? They were in fact not all proprietary and are not necessarily proprietary. What's wrong with modularity? Some software vendors can specialize in HTML/CSS, some in video, etc. > Again I don't think you've thought it through. You can disagree with me, but these continuing, unnecessary, personal, condescending comments are in violation of the HN guidelines. Please stop.