Hacker News Reader

Comment by tfha | Hacker News Reader

Shouldn't we consider it a giant, massive red flag that you need a corporation backing you to maintain one of the most critical pieces of web software?

That's how we ended up in this mess. You can't compete in the web browser battles unless you have hundreds of full time engineers behind you. That's a failure of the web.

None of this new decentralized technology is going to mean anything if we haven't learned that lesson. If you want free, open systems, competition needs to be easy. We need to be able to respond to a abusive platforms by making our own, and that means we need to live in an ecosystem where making our own platforms is easy enough that you can have 10-20 viable options simultaneously supported.

Linux distros are a fantastic example of this. It's easy enough to create a viable linux distro that there are 5+ popular ones, and if you don't like those there are 10+ less popular ones which are perfectly viable and reasonable choices for an OS.

We need to take the web back in that direction.

View on HN

There are two internets now -- the internet of documents and the internet of applications. For reading documents, including somewhat dynamic documents like HN, all I need is w3m. But for the internet of applications you need a thin client: a javascript VM and layout engine. I regard anything that runs javascript as inherently malicious, out to violate my privacy and drain my battery. Of these, shenanigans notwithstanding, Firefox is still the least bad of the bad actors. Like most of the community, I'm disgusted but not surprised by this stupid stunt.

I would in fact be happy if we could just have a simple VM and a low level rendering engine, let's say something like a WASM based VM (or even JS if we really have to), and WebGL or similar for rendering. Define a standard way to provide (or refuse) access to local and remote resources and leave all the rest (HTML, CSS, Web Workers, Audio Playback, Video Playback etc) as software running on the VM. This way you would not need a few GB of memory if you need only to display a wall of text and it would be easier both to share code between implementations and contribute software (as libraries ? plugins?) to the platform.

Because then every site would need to include a CSS + HTML rendering library to be executed in this VM - it would be like every site needing to include their JS framework of choice except much heavier.

No they wouldn't need to. They'd just have to advertise CSS + HTML, and the app browser would just use their internal CSS + HTML engine (possibly written in WASM for better sandboxing). There are probably a whole spectrum between those two extremes (all the code in the server, or all the code in the client).

I was thinking about something more like a "flash plugin": you may have to install once (or it might be bundled with the installer) and then "it just works". The main difference would be that it would be sandboxed and so limited on what it can do.

Actually it would be great - in the best interest of users - to make this distinction more pronounced. The "document web" should be a relatively safe space that you can comfortably browse with JS disabled. The "app web" is a different beast, and the trust of the user to turn on the JS engine should be earned. We could have "web browsers" and "app browsers", with the former being much more safe and less resource-consuming.

The distinction isn't pronounced. Few sites are, distinctly, only "apps" or "documents." So how would one define an "app" in this case, in a way that wouldn't encompass most of the existing web as "apps?"

Anything that uses JavaScript?

Or allows only the minimal subset required to implement AJAX type functionality.

The argument for expanding web standards has always been "if we don't, then they'll just appify it and we won't have any say" (see DRM debate).

An explicit decoupling of information from interactivity would lessen the pressure for that.

"Anything that uses Javascript" would include, as I said, almost the entire web, including sites which primarily serve text and act as documents, including Hacker News. View the source - it even uses AJAX.

I've just replied to you with JS disabled. I also created this account with no JS (this was a year ago). Upvoting also works without JS.

In my experience, of all the websites that don't work without JS, only a minority actually need it. Most of the time it's silly things like articles and blog posts that just show a blank screen without JS, or drop-down menus that rely on JS even though there are perfectly fine non-JS ways to do it, etc.

"Anything that requires JavaScript" might be a better criteria. Hn gracefully falls back without JavaScript enabled because it's not necessary, just some added convenience.

Even then, sites which lack graceful degradation aren't so qualitatively different from the few that do that they need to be moved to an entirely different platform, viewed from a different device and considered "applications" and not "documents." That seems like throwing the baby out with the bathwater.

What does make sense to me is a new platform based on WASM, with related tooling. Photoshop in the browser or something running the Unreal Engine or .Net is not the web enough to maybe deserve its own thing. But a new platform based on what are essentially complaints about complexity or efficiency would be too messy.

Yes.

Right now there's next to zero incentive not to use JavaScript. And only slightly more to engineer a working fallback page.

Bifurcating the web would provide one.

You're arguing for a technical solution to what is essentially a cultural problem.

I'd argue that the cultural problem (sites being VM-tech-heavy) is caused by a technology choice (never saying "this much technology is sufficient for a large part of the web").

Or to put it another way, extrapolated down this path README.txt files on the web in the future will only be accessible with a pair of VR goggles.

A document is static. It's neither necessary nor desirable that we access documents over the internet by contacting their owners. It's better for both privacy and resilience to handle documents over something like IPFS.

The web as we know it is much better suited to applications, where websites have behavior as well as content. Whether the rendering is server-side like HN or client-side like Facebook is irrelevant.

I'd argue that most sites are "documents" that have had "apps" unnecessarily shoehorned into them for cosmetic or financial reasons.

Seems kind of silly to ignore that javascript enables much more robust user interfaces. It can and is used poorly or maliciously, but it's used for far more than cosmetic or financial reasons.

What is "much more robust" even supposed to mean? It sounds like meaningless marketingspeak. The countless number of sites that break the back button, scrolling, general navigation, showering my eyes with distracting animations, or show some stupid popup when I select text make me lean towards the UI being much better without JS, and indeed I keep it off by default.

I once had a site beg me to enable JS "for a better user experience", one which didn't need it to work. I did, and promptly turned it off again when I realised what the "better" actually meant (see above). Not going to fall for that one again...

When I want to read an article in a newspaper, I don't need a "robust" user interface, I need the text and (sometimes) the pictures. Links to other relevant content are a bonus. This could be done with the very first web browser.

Yet for some reason (hint: money) newspaper websites load megabytes worth of scripts to display kilobytes of text.

Good point. The commingling of the two is probably more the "failure" of the web than anything else.

There's no reason I should be required to go through the "app" web (Flash, JS, Silverlight) to get something off the "document" web.

... and most use cases don't require an "app" web.

I really think there should be a .text TLD.

I don't know how you enforce it exactly, and maybe it's redundant with pastebin.

It still nags at me that sometimes I want to go to the web to just read a thing, measured in the tens of kilobytes, and all this other nonsense just gets in the way.

It's my kooky nostalgia probably. Old man yells at cloud. But other times, for fleeting moments, I think about applying for that TLD and feel just a bit like Ray Kinsella...

I really think there should be a .text TLD.

That would be great -- I'm imagining a whole TLD full of sites like http://text.npr.org and http://lite.cnn.io/en.

Doesn't have to be that minimalistic - I could see up-to-date CSS being a good member of a document-only web.

gopher://

I do find it interesting that within the last year, two new and viable gopher browsers have been created - one for Windows and one for Android.

There's .page that could work just as well. I'd be keen to see a movement like that too.

There isn't really any practical reason for most sites to support users with JS disabled, as they're a pretty small minority. So there isn't really any good reason sites or users would actually care about or bother making the distinction.

Just make a separate "document web", with a standard that isn't utterly lovecraftian and has all the functionality that current ostensibly "document-only" sites (i.e news, forums, etc) rely on JS for. Then, disguise it inside some hip web framework where the client end just acts as a viewer, client-side rendering to boot (with a fallback for users with JS disabled). Make sure an independent implementation can access the underlying "document" through the endpoints the clientside rendering uses. Now you're able to essentially fool people into supporting it.

Also, you could choose to represent your document sites as a pile of data and non-Turing-complete "scripts" that do the presentation, with state that can only change upon user interaction. That may seem like a really backwards way of doing it, but if done right, it would give you a really good bang for the buck in terms of functionality/UX vs implementation complexity.

>Of these, shenanigans notwithstanding, Firefox is still the least bad of the bad actors.

I would say Brave is better here. By default Brave blocks 3rd party cookies and ads. Brave has browser fingerprint blocking as well, but that is not enabled by default, presumably because that would break a lot of web applications and give the users a bad first impression of Brave.

Brave also comes with built in cryptocurrency micropayments as an optional way to sustain websites without advertisements.

The least bad actor in my view currently, is Brave.

Yep, don't wonder about the downvotes.

Agree with this, but the problem is user demand in competitive markets.

> I regard anything that runs javascript as inherently malicious, out to violate my privacy and drain my battery.

Tech people like those on HN may understand the centralizing corporate control that's embedded in the current structure of the internet.

Average users a) have zero technical understanding b) mainly use JS-heavy, DRM/surveillance-loaded "big tech" websites c) lack the skills, awareness, and desire to change anything for increased user freedom. There's more reward for positive features than lack of negatives.

Unless a compelling case can be made to the minimally-competent user who sees only speed, usability, and immediate real-world social use (I can watch DRM movies, play DRM music, use FB / YT / Google Apps / other "big tech"), any shift seems unlikely.

The problem is less technical than social. DRM / surveillance tech crapware is now a social norm, and there's rarely a good time to have a discussion. Most non-technical people just don't know or care.

Thanks for this! For years I've been looking for a unixy command line browser that cuts through all the web related cruft. W3m fits the bill nicely.

From my observations, a brief stint interacting with standards bodies, and a lot strong opinions about API designs and specs:

The problem starts with regulatory capture of standards and standards bodies. It is in the interests of large organizations to pack a standard with every bit of code they have created internally. It slows down the other members and it keeps small groups and independents out entirely.

You could in many cases have a standard that five people sharing an apartment could implement. Or you could have one that only half a dozen groups could, which is just enough competition to make it sportsmanlike.

Do you have any ideas on how a standards body or its procedures could be structured to fight against this tendency?

For the most part, they can't, because a new standards body will spin up. The history of WHATWG [1] is illuminating; WHATWG being the community -- of largely browser-makers -- behind HTML5 and other specs that moved the web forward from 2004 to now; notwithstanding how you feel about W3C or WHATWG, it's impossible to deny that once a standards-setting group no longer meets the goals of its members, those same members are likely to go start something else.

[1] https://en.wikipedia.org/wiki/WHATWG#History

One problem with standards organizations is that they have a bunch of people whose job is to make new versions of the standard. Look at the evolution of openGL, the web, C++, Unicode (love hotel? Poop emoji?) and so on. Even ASCII evolved to 8bit and the got ansi escape codes, but it's stable now. C is fairly stable now but that's because all the new stuff is in C++ (much like HTML replaced ASCII).

We’re pretty bad about frog boiling. When we amend a spec we think about how much more we added, not how big it’s gotten.

It’s part of the disconnect between new and old employees. Everyone who has been there for three years learned the system one piece at a time. They don’t understand why the new people look at them like they’re crazy.

The emoji character set originated in Japan. When it was turned to Unicode, they weren't going to just remove characters because some of the world doesn't care for it.

Emoji was clearly designed for a date when the Japanese phone and telcoms decided to set union all their icons as font glyphs. Why do you need both left and right magnifying glass, and so many variations of train?

What's wrong with the evolution of OpenGL? Everything from OpenGL 3 and on has simply been focused on fixing the API without completely breaking old code, or exposing new GPU features. All of that was necessary.

Initially I was going to let the other responses stand on their own but I had a new thought.

Unfortunately it seems the spec by fiat process is the least problematic this way.

Someone standardizes a thing that has been working for them for a while and they want their partners and maybe competitors to work with it.

It has to be a fairly conservative spec as well, something that can be defined concisely.

And let me be clear: this is a necessary but insufficient quality of a good specification. Ramming an opinionated spec down everyone's throat that is clearly tilted to only be achievable with your company's patent portfolio is not playing nice, and people tend to sense the insincerity.

That's how we ended up in this mess. You can't compete in the web browser battles unless you have hundreds of full time engineers behind you. That's a failure of the web.

I continue to find it ironic that Mozilla (and to a lesser extent, Google) have been pretty much continuously complaining about Microsoft/IE "holding back the Web", with a lot of people in agreement, when MS/IE's lack of support for the latest standards (not authored by them, naturally) is what keeps the former from having too much power over the Web as a whole. Imagine the company with huge browser marketshare rejecting all proposals to add new and more complex things to the standard, or refusing to implement them.

If you want free, open systems, competition needs to be easy.

By MS/IE "holding back the Web", it's actually making it easier for alternative browsers to compete, and I think that's a good thing. Consider that the non-mainstream alternatives like NetSurf and Dillo are probably at a similar level of Web standards support as IE6/7.

Now that I think about it, I actually miss the Internet when the combination of XP and IE6 ruled --- certainly some sites tried to push the boundaries, but a lot of the rest remained "un-appified" and usable from other simple browsers too, with a bigger emphasis on content...

Except all Linux distros rely on the Linux kernel and repackage a vast number of GNU utilities which are maintained by... hundreds and hundreds of engineers.

If GNU/Linux were to die, so would all the distros, because it’s far too much work for any individual distro to maintain all that codebase. In much the same way, the intensive bit of maintenance work with Firefox is the rendering engine; there exist lots of “distros” (forks) of Firefox but they all rely on the same underlying codebase. It’s just not viable to have more than a small handful of rendering engines, much in the same way that there are only a very small handful of operating systems that can run on modern hardware.

> If GNU/Linux were to die

But there is no such entity as GNU/Linux. It's hundreds and hundreds of independently working engineers who would all have to be hit by buses at the same time.

10 companies are responsible for 57% of the changes to Linux. This is better than the typical 1 company responsible for the majority of changes in a browser, but it's not remotely close to "hundreds and hundreds of independently working engineers". Volunteers only make up ~8% of the changes.

What we don't have is any browser that's a multi-company project, though. WebKit used to almost be that, but then the blink fork happened. The closest currently would I suppose be Chromium as it's also backed by Opera.

I think we're in agreement that Linux is in a better state than the browser. To nit-pick at your argument, Linux development is driven by people who are interested in working on it; many of those are lucky enough to have employers who encourage them to use a company email address to submit changes, and part of their working hours. Nothing indicates they wouldn't still be contributing without the @intel.com attached to their name.

Furthermore in the study you are referencing, the "8% volunteers" is larger than any company's contribution besides Intel and RedHat - even more if you add in the individual "consultants".

https://www.linuxfoundation.org/blog/the-top-10-developers-a...

This is such a lovely idea on paper, but how do you put that into practice? Is the problem the monolithic design of a web browser, which now is basically an operating system all its own? Is the solution to break that into its component parts, so that each part can be maintained by a smaller group, and composed together to produce the browser as a whole?

The problem is the complexity of all the specifications that make up the Web. These specifications are heavily influenced by whatever major browsers already are doing (i.e. influenced by a handful of huge tech companies). These companies have a vested interest in making it hard to make a new, competitive browser.

I think the Web is unredeemable at this point; there is so much entrenched complexity, ugly hacks, centralization, and misuse of various technologies that it can never be undone. The only solution is to refuse to contribute to the Web at all, which is hardly an option for most of us here.

The solution is to fork, or start over.

I like the latter idea.

Are there any ongoing efforts in that regard? I guess IPFS, but even then, you're serving html.

its slow going, but that's what i'm trying to do with heropunch[0]. our goal is to create a p2p application platform using a handful of libre technologies: secure scuttlebutt, ipfs, lxc, enlightenment foundation libraries, rust, and elixir.

[1]: https://www.heropunch.io

Great. I support this.

Go build your new web and leave those of us who believe the existing web, despite its faults, has value, be.

just about anything people invest time into is going to have some sort of value, 'despite faults'.

that doesn't really speak to the value of progress, reflecting on the status quo, or creating something fresh with lessons learned from the past.

i don't really get the 'leave you be' bit.

>i don't really get the 'leave you be' bit.

Simple. More than a few people here seem to believe, as the grandparent comment suggests, that the web is a lost cause, or irredeemable, and all those people seem to want to do is to constantly complain about it.

I'm simply suggesting that if people feel the web has nothing to offer them, that it would be more productive for them to kindly leave it for a network that better suits their needs. Otherwise, rather than wanting to "fork the web and start over" they could consider working to improve what we have.

viewing the web as a lost cause or irredeemable is not the same as saying it has nothing to offer. 'leaving the web' also doesn't seem very pragmatic, at least until something better is available.

>viewing the web as a lost cause or irredeemable is not the same as saying it has nothing to offer

I disagree - if it has something to offer then it's not a lost cause. A lost cause by definition isn't worth saving, or even engaging with.

> 'leaving the web' also doesn't seem very pragmatic, at least until something better is available.

The comment I replied to earlier suggested that the only reasonable solution to the web was to fork it or start over, with starting over being preferable. I'm merely suggesting that someone should actually get started on that.

Or maybe revive Gopher. I hear that's still around.

people can get started on that, and probably are. but the web exists, and the web is pervasive. it doesn't make any sense to abandon it until a replacement arrives... just as it makes no sense to simply abandon gas engines (and what, walk?) before electric ones are ready to replace them.

the real question is whether the New Thing can avoid the problems of it's predecessor.

> all those people seem to want to do is to constantly complain about it.

Why are you taking those complaints so personally?

You don't need us to be content with the status quo. If all we are doing is complaining, we really aren't doing anything to you.

Well, I certainly don't want to do it alone, if I want to do it in the first place.

It sounds an awful lot like you are complaining, but about what, I am not sure.

I don't see how I am not letting you be, either. Creating a new system does not involve you at all, until you find a personal interest in that system, or its development.

I think we could build a simple standard that does the useful parts of layout / CSS and includes a sane scripting language in a reasonable timeframe. It would need to be accessible both for users and developers.

The hard part would be enforcing behavior so you don't end up with venders adding their own bits which destroy the entire point of the thing.

I think the Web is unredeemable at this point; there is so much entrenched complexity, ugly hacks, centralization, and misuse of various technologies that it can never be undone.

Somewhere, an AMP developer coughs indignantly

I think this idea has some merit to it, but I don't have any experience in building that kind of software.

This is essentially how teams that build huge software systems work. Like for instance, operating systems like windows/linux. The various teams at Microsoft, or trusted comitters for Linux, organize their various modules, components, subsystems, etc. independently, and eventually compose them into a coherent functioning whole to ship the whole system.

The biggest difficulty is tying components together.

There are a few methods:

1. Libraries linked by binaries.

This is the usual method, but it generally demands modules share some things, which usually couples them too tightly to their implementation.

2. IPC (Inter-Process Communication)

There are a few ways to accomplish this. Some are OS specific (named pipes), others are fairly generic (sockets). This requires modules to share a language, and has some overhead, but at least they aren't coupled.

3. Microkernel

Essentially the best points of 1 and 2, but generally a design challenge itself.

The biggest advantage to modular design is that you don't need to create all the modules before you get something useful.

Design and create the equivalent of a web browser in a modular fashion.

Yes, that is a lofty goal. That does not make it unreasonable.

> Is the solution to break that into its component parts, so that each part can be maintained by a smaller group, and composed together to produce the browser as a whole?

Possibly, but currently, a "web" browser depends on its monolithic qualities. A web page is a DOM, defined by HTML, styled by CSS, and manipulated by JavaScript.

I think it may be time to start designing something less inherently monolithic.

One advantage to modularity is that we don't need to finish before we can use it.

we are slowly working towards this goal[0], we try to team up with other projects and develop this stuff cooperatively. our focus is on the user and developer experience side of things. creating good comfy tools for developers and fighting for very high quality UX on the user side.

[0]: https://heropunch.io

That's very nontrivial task, if feasible at all, considering current overcomplicated state of affairs in CSS, HTML, JS, graphical, font-rendering and networking fields of browser's interest.

> Guys, there is a _reason_ why microkernels suck. This is an example of how things are _not_ "independent". The filesystems depend on the VM, and the VM depends on the filesystem. You can't just split them up as if they were two separate things (or rather: you _can_ split them up, but they still very much need to know about each other in very intimate ways).

http://yarchive.net/comp/linux/user_space_filesystems.html

> That's very nontrivial task

I imagine so.

And?

James Mickens gave a great talk about how we could build a better browser: https://www.youtube.com/watch?v=1uflg7LDmzI

Amazing talk, thanks!

You're right, this is great. Is the Atlantis source code available?

I've looked for it previously and not found anything. I'm hoping that MS are working on it in secret, but seems unlikely.

Linux distros are a terrible example.

Not only do they all rely on Torvalds and everyone else for the kernel (heavily funded by donations, companies, etc), but most Linux distributions are just cosmetic variations of the largest upstream distros.

If Debian died tomorrow, Ubuntu is on life support.

> most Linux distributions are just cosmetic variations of the largest upstream distros.

Plenty are not. I am impressed by how usable community-based (non-corporate) distros are (e.g. Gentoo, Arch). This is truly indigenous technology.

> they all rely on Torvalds and everyone else for the kernel (heavily funded by donations, companies, etc)

This is an interesting thought. I believe the Linux kernel would continue to be viable on a purely volunteer basis, without corporate subsidies; I can't prove it though.

Without corporate subsidies, corporate subsidies would soon reappear. If it's useful enough, corporations will pay to continue having it.

I suspect you're right, but it would certainly be a tectonic event, and could potentially affect Linux's competitiveness until equilibrium recovered.

And you're right about "most" being wrong. "Many" would have been a better word, particularly if talking about the most popular.

(Another non-upstream-reliant distro that I find fascinating is GoboLinux. Very against the grain/orthodoxy!)

Kernels aren't any more important than compilers, xorg, user space utilities and so on. That Linux managed to get its name on the whole stack doesn't mean much. You might as well be complaining that linux distributions are vulnerable to power outages.

If anything the major distributions are defined by their package managers, of which there is a large and healthy number - aptitude, dnf, pacman, protage, and a heap of weird and wonderful other ones with minuscule usage.

> you need a corporation backing you to maintain one of the most critical pieces of web software

My understanding is that Mozilla is supposed to be a nonprofit first and foremost: the Mozilla Foundation. The for-profit Mozilla Corporation is a subsidiary which is owned by the Foundation. I don't know whether this is still reflected in practice nowadays, but this is how it's supposed to be structured...

> Linux distros are a fantastic example of this. It's easy enough to create a viable linux distro that there are 5+ popular ones, and if you don't like those there are 10+ less popular ones which are perfectly viable and reasonable choices for an OS.

But isn't this the same as all the Chromium/Firefox forks? I mean I understand they aren't as popular as the major players but you could say the same about all the Linux distributions compared to Windows or OS X.

This isn't just a problem with Web standards. Think of how few complete implementations of C, C++, Python, Java there are.

So yeah the web is complex but so are most popular runtimes.

The difference is that the web was originally designed to show documents, not build applications. The failings of the web are entirely a result of turning the browser into a VM for Javascript applivations.

I like the idea of having the web just being a static document format with hyperlinks and embeddable objects. No DOM just a tag for some narrowly defined supported formats (eg. .form, .game, .social, .store)

Size is not a requirement of a programming language: look at Lisp, Smalltalk, Lua, etc to see simple systems that can be fully comprehended and are quite powerful.

If anything, the monstrosities produced by committees are less powerful and less beautiful. (That we put up with them says more about us.)

Have you seen the Common Lisp specification?

Common Lisp is big because it's a bridge between MacLisp and InterLisp communities of the 80s. There are much smaller (and just as powerful) Lisps like Scheme or ISLISP.

Scheme is poorly expressive for daily programming and it's because of its small size. The documentation quantity for a useful Scheme like Racket is much larger.

Also, do we count all the pages expended on SRFI's? Or not?

>Have you seen the Common Lisp specification?

Yes, it is huge and gigantic, but worth it's weight in gold. The stuff "just works" and has almost no limits. I'd say that spec is a masterpiece.

Think of how few complete implementations of C, C++, Python, Java there are.

C++ is at least an order of magnitude more complex, but there have been plenty of C implementations, some even entirely the work of a single person[1]. "I wrote my own C (subset) compiler" seems to be a reasonably common thing on HN too.[2][3][4][5][6][7]

On the other hand, I haven't see very many "truly independent" webpage rendering engine implementations (e.g. HTML4 or HTML5-subset, CSS2.x), so if anyone wants to give it a go (or Go, if you like...), they are more than welcome to, if only to increase the diversity of available implementations --- something that could probably handle HTML4/CSS2 might not be all that difficult, and especially so if you don't care for 100% identical results to the mainstream browsers (which often differ slightly too.)

[1] https://en.wikipedia.org/wiki/Tiny_C_Compiler

[2] https://news.ycombinator.com/item?id=13914137

[3] https://news.ycombinator.com/item?id=15463738

[4] https://news.ycombinator.com/item?id=13778353

[5] https://news.ycombinator.com/item?id=8558822

[6] https://news.ycombinator.com/item?id=11903674

[7] https://news.ycombinator.com/item?id=9125912

> something that could probably handle HTML4/CSS2 might not be all that difficult

As someone who did a lot of the work to implement a from-scratch HTML4/CSS2 engine, I struggle to come up with words that would adequately express to you just how much you are underestimating the difficulty of this.

I think we should stop writing code, and start thinking about the future, and write draft specs for an open web, and build a platform to discuss those specs.

Mozilla is great because they have good management, not just because they have great coders. The rest of us should take an example if this. This means that we should stop scratching our itches, and do some real thinking and have discussions before engaging in our next side project.

> "start thinking about the future, and write draft specs for an open web..."

There has been tons of attempts at this. Maybe we should start examining why these attempts have failed to succeed.

“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.” - Fuller

One possible reason is that a truly open web would include things advocates for an open web don't want, such as advertising and commercial interests, or javascript.

Excellent point. I fear many attempts at the open web failed because they were a little too anti-capitalist or FOSS-purist and ignored basic economic realities.

> they have good management

In light of recent events, this would seem to be up for debate.

The comparison with linux distros isn't quite fair, as they are not full reimplementations of the same standard. They are are better compared with chromium based browsers, which are easy to create and of which there are many.

What do you suggest to do to make competition easy? We could throw out most of features, but then the resulting standard won't be useful, and almost no one will use it.

> Linux distros are a fantastic example of this.

I'm still looking for a Linux distro that runs on my phone without hassles.

This is because hardware manufacturers don't upstream drivers.

Or, for that matter, one that I can use for gaming.

What are you talking about? I've been gaming exclusively on Linux distros (Ubuntu, Fedora, SteamOS and Solus) for the last few years and it's been great. Site/community gamingonlinux.com is a testament to Linux gaming being a viable platform.

The sad truth is that some great titles only run on Windows.

If no one writes game for any given platform, is it the platform's fault? Network effect don't explain everything, but they do explain a lot.

There is more than 3000 games on Linux on Steam right now. A lot of it is indie, but still thats a lot of games.

i have used at least 4 different distros for gaming so I have no idea what your comment is supposed to be about.

Seems like we should expect that in a competitive market, production values will keep rising until it's no longer easy to compete? So the mystery isn't why browsers are so competitive, it's why other niches don't attract strong competitors.

"Shouldn't we consider it a giant, massive red flag that you need a corporation backing you to maintain one of the most critical pieces of web software?"

Yes.

Interestingly Mozilla Foundation is not asking for donations.

Mozilla Corporation is selling traffic to ad-supported search engines, and profiting handsomely.

Instead they are asking for user cooperation in their experiments.

Why not create a different breed of browser that does not expose users to advertising. Profit motive?

Let users support it with donations.

This should be the mission.

It might interest you that most Linux development is, in fact, done by corporations, and not by broke-ass developers funded by donations.

>Shouldn't we consider it a giant, massive red flag that you need a corporation backing you to maintain one of the most critical pieces of web software?

That's the price of doing business, isn't it? It's why communism doesn't pan out as well as capitalism. What's that a red flag against? The human animal?

I agree--let's replace 'em with super AI instead or something, but, in the interim...

>we need to live in an ecosystem where making our own platforms is easy enough that you can have 10-20 viable options simultaneously supported. Linux distros are a fantastic example of this.

They are not. Pale Moon is about as "viable" against Firefox or Chrome as Ubuntu or Mint are "viable" against Windows or MacOS for the average user. (And one of those [the better, much more popular one] has a corporation backing it!)

> Pale Moon is about as "viable" against Firefox or Chrome as Ubuntu or Mint are "viable" against Windows or MacOS for the average user. (And one of those [the better, much more popular one] has a corporation backing it!)

Funny, I appreciate the Pale Moon community (I'm "officially" part of it since I use the browser) more than I appreciate or support anything to do with Mozilla for years now. I don't see it being non-viable, because there are plenty of people who are actively involved in providing a better browser with specific goals. And, there are plenty more people on top of that who act as concerned watchdogs to make sure the browser doesn't lose sight of those goals. That's what Mozilla lost. When the powerusers turned into an echo chamber, Mozilla lost the way. When the community openly approved of the offloading of plugins (the start of multi-process nonsense), the new interface, the move to WebExtensions... this is the fault of the people who kept saying, 'yes keep changing stop being Mozilla stop being Firefox be Chrome-2'.

Reply on news.ycombinator.com