While KDE has had some contributions from large corporations, it would be a gross exaggeration to call KDE (or any Linux desktop) a popular success. It more closely resembles a hobbyist project than a commercial juggernaut.
While it may be true that KHTML/Konqueror was not as polished as WebKit/Safari or Blink/Chrome before those forks poured massive amounts of corporate development effort into those browsers, the fact is that it was a solid enough foundation for those later corporate contributors to leverage into world domination.
In other words: Today's small scrappy upstart browser that only hobbyists use may be the embryo of tomorrow's near-monopoly. Please don't abandon your ideas for new browsers+engines, give them a shot. Even if you do not directly benefit from its future success, at least you may give the web a gift that everyone will someday enjoy. The new boss Chrome is an unqualified improvement for the web over Internet Explorer, if only in standards support and open source code. I only hope that someday we can replace it with something better than a new corporate overlord.
Also, one point I'm making here is that a small dev may not be able to make a world-dominating project by themselves, but it may serve as the foundation of something larger later. Is that really surprising or controversial?
Perhaps a more important point I'd like to make is that neither Apple nor Google were quixotic enough to start a browser engine from scratch, for all of their expertise and cash. Without KHTML, we might still be suffering under IE or something even worse. It may take someone willing to tilt at windmills to dethrone Blink/Chrome, I don't think the suits will save us.
It was Firefox. Firefox 1's slogan was literally "take back the web".
It was only Firefox that took IE6 down.
(I'm a KDE contributor and I may even have a couple of patches on Konqueror)
Sure, garage scale nowadays means just a few millions of USD angel/seed, compared to the 100K USD a decade (?) ago, but it doesn't mean that there are no niches waiting to be occupied, no new markets emerging ever in the future, etc.
Sure, perhaps things will be in a different place in 5 years. (Especially if The Dispatchers Of Wisdom™ don't decide to give up and start again with a new UI and applications. Cynically not giving the current effort a high chance of surviving...)
OK, my point/question: I think one of the prerequisites for hobby projects to make it big is playing in a space that's largely uninteresting or undiscovered to the majority of people that will notice (and understand, and feel threatened by, and respond to) the new thing, before it has reached critical mass. Perceived risk being somewhat irrational and all that.
KDE and Unity feel like hobby projects because "desktop Linux" is forever the thing that never really existed, and the only people who pursue the idea are people that don't get that. But their work gives enterprises some free source code with APIs that let them make application windows with buttons in them! Nice! But there's no point for those enterprises to contribute functionality back to the UI engines, because that doesn't further the enterprises' application-specific focuses.
Web browsers definitely aren't an undiscovered thing by this point. I'm sure more people than might reasonably be expected probably check out where NetSurf is up to every 6-12 months or so, for example. (I don't mean hobby project users here, I mean would-be commercial users with adequate domain savvy to be aware of the entire ecosystem. Total theorization on my part but I do wonder if I'm right.)
"A new kind of web browser" is a fun idea, but impractical in practice as it's preeeety much the polar opposite of an unknown idea now. A new web browser would be subject to an atlas-holding-up-the-entire-world level of passive and active social scrutiny if it looked like it was taking itself seriously. (Servo is kind of a good reference example there. It wouldn't survive if it didn't have Firefox and the indefatigable Rust team behind it; and even as it is things are still struggling).
By the way, serious question - what does source-level access to Chrome mean, at the end of the day, for the vast majority of internet users? The only real quantitative (not qualitative) answer I have are the small high-reward collection of bug bounties that have been rewarded over the years to external contributors. The fact that you can build Chromium and ship it [as part of Linux distributions] does feel a bit like an implementation detail that fulfills Chrome's goal as a technology moat (and competitor to Firefox).
Servo is not a browser, it's a research project, it's the proving ground for Rust and Firefox's Rust-ified components.
I don't believe that it's impossible. It will take a lot of time and effort, sure. But not impossible. :)
“Taking a lot of time” is what’s implied by impossible.
By the time you are done building whatever-it-took-long-time-to-build a new generation of users have just emerged.
Your product is either a) obsolete to the youngest users, or b) you, as the product builder, lost the point of reference of the youngest generation
From the blog:
>I conclude that it is impossible to build a new web browser.
And a new OD. The entire world communicates now by two OSs only..android and iOS.
That's silly and reductionist. The world uses those OSs, but not only those. Almost every person that sits at a desk for work also uses something else. Every student in the US is expected to a use a computer with a keyboard for writing papers. I'd they don't have their own computer to do this, they are provided access to one.
For some disciplines, especially anything involving CAD, I think desktop computer is still necessary. That said, I think you'd be surprised just how much of a typical college education can be done on nothing more than a basic tablet and a handful of productivity apps.
* (...wow, it really was a decade. How the time flies.)
I think upon reflection this is less surprising than you might initially find it. After all, college predates computers.
Hi maram! It's not that kind of project. I'm building a new OS and browser for myself. There is no "product" and the only "user" I care about is me. :)
By the way he phrased his comment, even I could tell this was a project with personal, non-commercial ends.
On this basis, his product will ultimately be: accomplished, or not accomplished but having enriched himself a ton by mere virtue of the pursuit.
The entire world is not only communicating via Android and iOS. Those are the predominant OSs; however, we've all heard of Linux, haven't we?
It can be, when you have a moving target.
Regis McKenna made a point at 4:30 "The span from the first transistor to the first microprocessor is going to about a third" he was discussing product innovation.
“There will be certain points of time when everything collides together and reaches critical mass around a new concept or a new thing that ends up being hugely relevant to a high % of people or businesses. But it’s hard to predict those. I don’t believe anyone can” -Marc Andreessn
You could keep it simple, too, if you didn't need to support existing bloatware.. such as browsers.
Of course most people imagine themselves to be motivated and able to focus on goals. Then, after x hours of win, they log onto twitter or facebook, get calls, messages etc or lose half a day on HN.
Make something like a game console only the exact opposite. Imagine phone calls and work messages popping up in the middle of your xbox session and work being 1 click away at all time? I think that would be just as inappropriate and undesirable as doing it the other way around.
It cant be just me, as soon as I start the browser the entire internet circus is there, all of the clowns, balloons all over. This is where I'm suppose to get work done?
Much like the vernacular meaning of "A computer" usually includes mouse, keyboard, and monitor, even though those parts are completely interchangeable and you can run a computer headless with remote access (or no access at all, the computer simply churning through whatever program it was pre-loaded with and outputting to some exotic peripheral, or maybe even simply generating heat in the corner with no human-discernable output at all).
Applying to the topic about browsers, it's as if you were planning to build a skeleton of a browser, without those equivalents of GNU-tools-to-complete-distro-starting-with-Linus's-kernel. But Linus was able to get parts from GNU project - where would you get necessary parts to complete the browser which you're writing?
I'm hyperbolizing. However I believe the point of the article is that it's actually very hard to build a usable, full-blown browser - not a proof of concept, Unix-kernel-equivalent. Toys for playing - maybe; production quality, so somebody would use it day to day - unlikely.
I'm more interested with where do we go from here. Should we start with fixing W3C standards so that they would permit a simpler implementation? Or are there other ideas?
OpenGL ended up doing something like this with the death of the fixed-function pipeline (first via OpenGL ES omitting it from the parent standard and then via OpenGL's main standard marking it deprecated and killing it for all cards that don't mark themselves backwards-compatible). But the consequence of this is that some 3D apps simply won't work with some graphics cards (a situation users are accustom to in the brutal Wild West of high-performance gaming, so those incompatible cards aren't crippled in the marketplace for being unable to run older games and such).
Perhaps one could describe a simpler w3c standard that is an orthogonal set of "core" features, and then implement handlers atop that standard for all the legacy crap that browsers can do today? It'd be a hell of a project to even start identifying what the core feature set and architectural layer would look like.
The web as a platform has done this before for things like ActiveX, Java applets, and most recently Flash. Collectively, developers decided they were overcomplicated rubbish and abandoned them.
My personal preference would be for more specialized agents speaking protocols designed for their use case: email over SMTP/IMAP (or JMAP!), newsreaders with RSS, chat on XMPP, etc, content browsers with some limited markup language, maybe games and fat apps loaded as binaries to a sandbox VM.
Maybe this is unrealistic and that time is passed, but the internet used to work more like what I've described. Today, more and more things are just a JS webapp that only runs properly in Chrome.
Maybe it's too simplistic.
Of course, there's still a monoculture in transpilers, but at least there could be more browser competition after that point.
Regardless, the main things I aim to do differently:
1. No JS JIT, only interpreter. I don’t care that much about JS performance as a user and the difference in complexity is astounding.
2. I prefer the web as a platform for smart documents, not for applications. I don’t want to relinquish any control of my computer to the web, and don’t want most desktop integrations like notifications, etc.
3. In that same vein, very light on animations/transitions, that type of stuff.
4. Way less aggressive memory caching. I don’t like the sight of 100MB+ web content processes that’s so common these days.
One of the cool techniques we used in earlier versions of JSC (although someone told me it's been dialed back since then) was caching property accesses / method calls in the bytecode interpreter. This technique ended up getting published by someone else in a different context:
I think there's more to be explored along these lines.
>I prefer the web as a platform for smart documents, not for applications. I don’t want to relinquish any control of my computer to the web, and don’t want most desktop integrations like notifications, etc.
I wish more people share the same opinion. We haven't even perfected the Smart Documents yet, but browsers has abandoned that work and moved to Web Apps instead.
And along the 'control' axis, stuff running in the browser probably has less of that than the same stuff running outside of that sandbox.
A lot of features should be omitted, and also some more things added to provide better user control.
In addition to being too complicated, I also think web browsers are overused. Other programs often work better. Switch discussion forums (including this one) to NNTP, text-based interactive services to telnet or SSH, email to SMTP, chat to IRC, many kinds of calculations to local programs which do not use the internet at all, etc.
> A lot of features should be omitted
Since I actively don't want the vast majority of functionality that is included in modern browsers, I think that this is a very doable project. Very large, certainly, but I don't see a showstopper yet.
Filter by level recommendation and latest version, and there's only 295 specifications remaining. Even then, there's still some duplication (e.g., HTML 5.1 and HTML 5.2 still count as separate), and scrolling through the list, well less than half are actually relevant for a web browser.
So developers expect native OS level API access from browsers. This is the true source of the bloat. And to be honest, we're converging on an open standard cross platform API. this is great.
I dont even see any trend to suggest that is the case. Even if you count Electron as being one. Most Apps are not web based, and dont ever intends to be.
>So developers expect native OS level API access from browsers.
Exactly. It was certain group of developers that want the Web to be the default Application platform, starting with Mozilla's Firefox OS and later Chrome OS.
I think we need to differentiate a Web Page Engine and a Web App Engine. Although I would agree that even a Web Page Engine today is far too complex.
>> I dont even see any trend to suggest that is the case. Even if you count Electron as being one. Most Apps are not web based, and dont ever intends to be.
- Word Processing
A shorter list would be what isn't on the web platform?
- Video games
- Graphics programs
> - Video games
Video games (not talking about Flash/HTML5 games) are on the web platform. https://github.com/emscripten-core/emscripten/wiki/Porting-E...
If you count streaming in, AAA games can be played from the browser since a while ago. I'm not a Google Stadia user but I participated in Project Stream which streamed Assassin's Creed Odyssey to browsers and from my brief experience it was pretty impressive.
And the usage of Web Spreadsheets are not mainstream at all.
It's fun to dream about a more deliberate replacement, with the same local/remote transparency of a web app, but with well thought out abstractions for local hardware and permissions.. Like, binaries are LLVM IR, Jit'd to the local architecture. Audio is openAL, graphics are Vulkan, local devices are [no-current-equivalent-standard-API], with fine grained security on all features.
It could be run locally, or with resources streamed over network. Opening an application could just be a 'URL'..
A little like a progressive web app, but not a weird outgrowth of an old page layout standard.
The eventual advent of the iPhone and the subsequent explosion of the app store also demonstrates that ease of entry is unimportant. The iOS platform was and still is the public platform with the highest barrier to entry, yet none of that matters because getting secure software distributed easily to users is the ultimate killer feature.
Did it? Web applications are not inherently more (or less) stable than native applications, and OS compatibility issues were replaced with browser compatibility issues.
Absolutely. The browsers are extremely stable and generally don't crash. The individual applications may still be bug prone but those bugs generally don't take down the system.
> OS compatibility issues were replaced with browser compatibility issues
Sure, but it's a much less severe problem (the potential for bugs rather than binary incompatibility) and one that developers can easily remedy based on visitor statistics without customer's having to download, update or take any action. This problem also becomes much less of a problem every day as the browsers converge on common standards.
Only Firefox and Chromium are able to keep up. It's an improvement over native apps working only on Mac OS and Windows as they are mostly open source, but still only two platforms.
The killer feature is effective per-app sandboxing.
From there you can just be a simple site or scale up to some really impressive applications with a TON of free resources available on the internet. That's pretty amazing IMO.
As a webdev who has been dipping my toes into C#... I fire up a new command line application in VS and the fans on my laptop take off and there's just a lot of boilerplate ... come on man.
What boilerplate are you talking about in C#? If you think that's bad, you should try something like C++ (although it's got far better in recent years), and I say this as a fan of C++.
This is an issue that is worth bearing in mind for energy usage, and has a significant impact on our future if we just defer to "easy to write, expensive to run" web languages.
I'm not learning C# because I think it is bad ;)
They'll hopefully be restricted to small niches were they won't do much harm :-)
I realize this might be annoying but I'm not trying to annoy anyone, I'm trying to get a point through.
(And yes, I do have some experience here, I was significantly better and more productive with both JS, PHP and Python before I really learned Java.)
An example would be Chrome: why would anyone choose to run the All-Seeing Eye edition from Google when it's F/LOSS and de-Googled alternatives exist? Because modifying it is complex and expensive, testing it is complex and expensive, keeping up with changes is complex and expensive (Microsoft basically owned the desktop because of introducing changes so fast the desktop application competition was always spending a significant amount of their budget just supporting the latest change), distributing modified versions quickly and reliably is expensive and complex, getting the community to agree on which anti-features to remove is impossible, and marketing it to end users is expensive. Thus we end up with obviously user hostile open source software, which would be impossible with simpler software.
LLVM IR is not platform independent, it's really just a bunch of (closely-related, ofc.) platform-specific IR's. What's wrong with WASM? Everything else seems broadly OK, of course. (Also, WASM directly supports "applets", via Canvas.)
What I'm driving at is - if we can dream, why not aim for maximal hardware performance and minimal overhead? Even if it comes down to just pre-compiling native code for common architectures like Android apps do. Right now, the browser is an idiosyncratic HAL burdened by its past... what would a really nice next generation be?
Interesting thing to know about the LLVM IR - I'm only casually familiar.
That said, I agree that performance may be a dealbreaker on that idea. HTML/DOM is also tightly integrated into a lot of browser behaviors, so I have no idea whether it's feasible to extract it into a swappable module. EDIT: It's still an idea that gets me pretty excited to try.
Once we are done with WASM we will look at it, compare it with Java Applets and say: Look, we already had that!
Wake me when it can free memory.
When the headline comes out that DirectX13 will be a layer on top of Vulkan, then maybe it's a sign that the world is ready :)
It is rather focused on robotics but that is essentially what the Robotic Operating System (ROS) is, although it is less for users and more for autonomous systems. It allows an operating system to be distributed across many machines and multiple entities to collaborate. There are many extensions available but ROS core is just the bare minimum abstractions needed to have a distributed operating system to build applications on.
It's not platform agnostic (works best with Ubuntu Linux) and is hardly a layer above the native OS, just applications communicating via standardized means.
ROS2 supports Windows, OS X, and Linux. I expect the support will only get better as ROS2 matures.
> just applications communicating via standardized means
I can't imagine any way to make such a system work without some kind of middleware for applications which gladly is DDS now for ROS2.
You've basically described WASM, sans the LLVM part.
Firstly, judging a web browser’s compelxity by judging the spec catalogue is already unfair. The catalogue is basically a dump of things related to the web, for example the specs of JSON-LD. (Which probably has almost no relationship to implementing web browsers, since that’s just a data format of JSON.)
Also, word count doesn’t correlate with complexity. That’s like…. saying that a movie will be more entertaining than another one because it’s runtime is longer. Web-related specs are much, much more detailed than POSIX-specs because of their cross-platform nature: we’ve already seen what happens if web-related specs look like POSIX: anybody remember trying to make web pages that work both in IE, Safari, Firefox in the early 2000s? (Or, just try to make a shell script that works on both macOS, FreeBSD, Ubuntu, and Fedora without trying out on all four OSes. Can you make one with confidence?)
Really, it’s just tiring to hear the complaints about web browsers on HN, especially the ones about ‘It wasn’t like it in the 90s, why is every site bloated and complex? Do we really need SPAs?’ Things are there for a reason, and while I agree that not every web-API is useful (and some are harmful), one should not dismiss everything as ‘bloat’ or ‘useless complexity’.
Specs like JSON-LD are included but do not meaningfully change the numbers. Also, the word count I used in the article is less than half of the real word count I ended up with, just to put to rest any doubts like these about the margin of error.
>Also, word count doesn’t correlate with complexity. That’s like…. saying that a movie will be more entertaining than another one because it’s runtime is longer. Web-related specs are much, much more detailed than POSIX-specs because of their cross-platform nature: we’ve already seen what happens if web-related specs look like POSIX: anybody remember trying to make web pages that work both in IE, Safari, Firefox in the early 2000s? (Or, just try to make a shell script that works on both macOS, FreeBSD, Ubuntu, and Fedora without trying out on all four OSes. Can you make one with confidence?)
This doesn't seem right at all. How do you figure that POSIX is less specified than the web? Have you read either standard?
Can you make a website with confidence which works on all browsers? When was the last time you found a browser-specific issue? Mine was three days ago.
JSON-LD was a simple example that I just used b.c. it was on the front page. That JSON-LD doesn't meaningfully change the numbers doesn't change the fact that the catalogue is a dump of things related to the web, which is probably different from each spec (POSIX, C, C++, etc...) which has a narrow scope. For example, the link dump has 104 links that mentions CSS in the slug: it probably makes sense to make a comprehensive CSS spec (which would probably reduce the size since it will remove a lot of repetitive parts), but the web standards don't work like that.
> This doesn't seem right at all. How do you figure that POSIX is less specified than the web? Have you read either standard?
That's based on some @chubot's oilshell blog posts about shell.
Excerpts from blog post:
> POSIX Uses Brute Force: In theoretical terms, a language is described by a grammar, and a grammar accepts or rejects strings of infinite length. But POSIX apparently specifies no such thing. Only the "unspecified" cases are allowed to use a grammar!
> Over the last few years of implementing shell, I've found many times that a careful reading of the POSIX spec isn't sufficient.
> The POSIX shell spec says that shell arithmetic is C arithmetic, So it's natural to wonder what the creators of C used. They didn't use grammars to specify their language. The code came first and grammars came later.
> Discovery: all shells are highly POSIX compliant, for the areas of the language that POSIX specifies. But POSIX only covers a small portion of say dash, let alone bash.
There are probably much more posts about this, but I think this is sufficient enough to explain that POSIX is underspecified.
> Can you make a website with confidence which works on all browsers?
I can make a website that reasonably works well on all browsers with confidence.
At least on the level where one can develop a full SPA based on one browser and then try & test it on others.
Most browser-specific issues don't exist and when they do, it's usually a one-liner.
> When was the last time you found a browser-specific issue? Mine was three days ago.
That's interesting, what was it? (Genuinely interested in that one.)
In my experience, it doesn't surface that much unless you're trying to use WASM or some new/non-standard APIs.
>I can make a website that reasonably works well on all browsers with confidence. At least on the level where one can develop a full SPA based on one browser and then try & test it on others. Most browser-specific issues don't exist and when they do, it's usually a one-liner.
On Chrome and Firefox, maybe. How about IE or Safari? How about Netsurf or Lynx or w3m? SourceHut (of which I am the founder and lead developer) works in all of those browsers, by the way.
>That's interesting, what was it?
Believe it or not, it was in how they interpreted margins. This was the fix:
todo.sr.ht rendered differently on Firefox and Chrome before this change. I didn't dig into it enough to make any bug reports, so connecting the dots is up to you if you're interested.
I hit another browser bug a while ago because Chrome arbitrary decided that the maximum number of elements in a CSS grid is 1,000.
> These would normally be corrected with as much as one sentence, and by my intuition I would expect no more than 100,000 additional words would be necessary to fully specify these edge cases. It doesn't meaningfully move the dial on any of these numbers.
I expect it would take much more than that to specify exactly what bash, dash and a lot of other shells should do in a cross-platform manner, consolidate the language to one, and allow backwards compatibility (just like where the web APIs are based on the consolidation efforts of IE, Netscape, and a bunch of other browsers in the 90s)
> On Chrome and Firefox, maybe. How about IE or Safari? How about Netsurf or Lynx or w3m? SourceHut (of which I am the founder and lead developer) works in all of those browsers, by the way.
Chrome, Firefox, and Safari are pretty easy to target all at once, as they have the usual modern features.
Considering Lynx, Netsurf, or w3m as modern web browsers invalidate your points, since I'm pretty sure they don't implement a lot of the standards, does w3m implement flex box/CSS grid for example?
I can't say this in confidence, but I think it won't be that hard to (not that it's easy) implement a web browser with a complexity of w3m.
> Believe it or not, it was in how they interpreted margins. This was the fix:
Hmm, my intuition feels like that's a SCSS-compiling problem where they mixed up the rules... but if they weren't, that would definitely be at least one browser bug.
"Firefox is filling up with ads, tracking, and mandatory plugins."
I feel like I follow these issues pretty close, and I don't think that's accurate. Did I miss somethings? I know they've made at least a few bad moves, but in general they do the right thing, and have stepped back some of the bad things. It's entirely possible I'm missing something though.
https://www.zdnet.com/article/firefox-tests-cliqz-engine-whi... (ads, too)
There are more cases of each, but these are the ones I thought of off-hand. Setting up Firefox today still requires you to manually go to about:config and turn off a whole bunch of crap. A stock install of Firefox has ads and sends telemetry, searches, and more to both third- and first-party network services.
Come on, the Pocket hysteria? It's a bit of JS and a one button you can turn off with two clicks. Pocket is now owned by Mozilla. It's a Firefox feature now, and not any more of "mandatory plugin" than the Sync or Add On Store are. I thought you were at least flipping out about EME, which is a 3rd party code and actually a plug-in.
Your central point is valid. There's no need to embellish it with clickbait backed by sources that are clickbait themselves.
I'd consider opt-in rather than opt-out to be adequate.
This still would be a reasonable course of action even if your real concern is what is adequate for the wider community, not just for yourself. Threatening to switch to another browser isn't going to help because anything you switch to at this point is going to be a fork of Chrome or Firefox, probably with additional ads and tracking added from the other downstream vendor. Like it or not this is the funding model of the web. Edit: I haven't checked in a while but I believe there are actually already several privacy-focused forks of these browsers that ship with the default configs changed to remove ads and tracking, among other things.
An alternative is to use packages provided by Debian (and possibly other distributions), which turn most of this stuff off by default
Time to go back to Linux. Hopefully the desktop has improved since the abandonment of 30-year-old UI paradigms for "cleanliness and focus".
I just hope Firefox keeps being a real counterpart to Chrome and doesn't try to mirror it. Funding is a problem as Mozilla is far too dependant on Google, but I don't know a solution to that.
This calculation is wrong. For example searching for HTML reveals different versions of the same document, various informative notes ("HTML5 Differences from HTML4", "HTML/XML Task Force Report"), things no one uses like XForms, and other documents that really shouldn't be counted.
I looked at the full URL list and it includes things like the HTML 3.2 specification from 1997. A quick spot-check reveals many URLs that shouldn't be counted.
I'm reminded by the time in high school when I mixed up some numbers in some calculation and ended up with a door bell using 10A of power. The teacher, quite rightfully, berated me for blindly trusting the result of my calculations without looking at the result and judging if it's vaguely in the right ballpark. This is the same; 114 millions words is a ridiculously large result, and the author should have known this, and investigated further to ensure this number is correct (it's not) before writing about it.
I wouldn't be surprised if the actual word count is two orders of a magnitude smaller; perhaps more.
And the word count I gave in the article is half of the real count I ended up with, and I didn't even finish downloading all of the specs to consider.
My full write-up on the methodology is here:
Anyone who thinks that the web isn't hundreds or thousands of times more complicated than almost anything else out there is lying to themselves.
- Unrelated to an actual web standard (such as a guide for authors of web pages(www.w3.org/TR/html5-author/dimension-attributes.html
), or a guide on how to create a PDF for a W3 event (https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20160317/pdf_no...)
- a raw xml file (www.w3.org/TR/2012/WD-its20-20121023/examples/xml/EX-locale-filter-selector-2.xml)
- a diff (www.w3.org/TR/prov-dm/diff.html)
- an error (www.w3.org/TR/unicode-xml/index.html)
None were actual signal that relates to the web's specifications.
I explained why I included these in my methodology doc. They felt this necessary to document, so I included it. The same is true of other specs I compared against, such as POSIX.
>a raw xml file
This XML file is 18 words according to my measurement. The total words I claim in my article are 113 million. Do you really think that this changes anything?
Okay, I should have caught that. There are ~700 of these and I am computing the difference these make to the word count now. I expect it will be within the >100M word margin I left on these figures. [Edit: 28M words from diffs, which eats up about 25% of the 100M word budget I allocated for errors]
123 words. See my XML comment.
Out of curiosity, is it your intention to also look for flaws in my approach to word-counting the non-web specs I compared against?
I was finally able to find one, by looking elsewhere: https://www.w3.org/TR/css-grid-1/. You include 8 copies of the css-grid-1 standard in your count. So of the small fraction of documents that are actually web standards, you're miscounting by an order of magnitude. In other words, I expect that the actual count here is off by 2 orders of magnitude and that the real size of the "relevant" web standard is 1-2 million words, and the rest is just bad measurement.
> Out of curiosity, is it your intention to also look for flaws in my approach to word-counting the non-web specs I compared against?
No, I think pointing out a 2-3 order of magnitude mistake in your methodology speaks for itself.
> They felt this necessary to document, so I included it. The same is true of other specs I compared against, such as POSIX.
The posix spec includes examples and docs yes. But so do the actual web specs (see again the css grid spec doc). What the posix spec doesn't include is a parallel version of the docs meant entirely for posix users, that is wholly irrelevant to people who are building a posix shell. Again, you're including an analysis of which PDF readers to test the accessibility of the PDF you're writing in an analysis of web standards.
For an even more egregious example, https://www.w3.org/TR/2013/CR-xpath-datamodel-30-20130108/ is one of eighty versions of the xpath datamodel spec that you count, and xpath isn't even an officially supported browser thing.
1. The majority of the documents you are including are not reasonably considered web standards
2. Of those that are, you are counting each one 5-50 times.
That's two orders of magnitude.
All your analysis has proven is that it's (ironically) difficult to machine-parse the w3 data, and that you did so in a way to justify your preconceptions.
It is "impossible" to build a new browser in the sense that it's "impossible" to build a new Windows 10. Of course, a key difference is that the web is specified atop an open standard so someone can at least try.
Mozilla have been successful in swapping out large chunks of their browser for superior replacements (for instance replacing the JIT, several times iirc), but that's not quite the same thing.
Another point: why would a company bother? Amazon's 'Silk' is just another Chromium-based browser, but I imagine that works just fine for Amazon. What's the downside of taking Google's hard work and putting your branding on it?
And it doesn't find the rule wanting. Three years since it stealth-launched, and forward momentum on Fuchsia seems... Questionable?
It also seems I regularly see new posts about it on HN, with a generally positive reception and optimism among its users.
(Yes, it's not part of Fuchsia anymore, but so far I haven't heard anything about the remaining parts of Fuchsia that makes me inclined to care about it until Google forces me to care.)
If it succeeded in that, I think it would pave the way for faster, less-bloated software in general, so I'm rooting for the project to succeed.
Vim is 'real-time' responsive even over SSH. I don't see much room for improvement.
What's the basis of this claim? I use FF as my default browser, and I have not experienced anything like this?
Regarding ‘mandatory plugins’ I presume this is referring to the OpenH264 codec and Widevine CDM?
Not @op, but my thoughts on the matter (for what it's worth, I also use Firefox):
Pocket. Just try disabling it. Good luck getting it all.
Then there's the advertisements displayed on the default home page.
Firefox account and Sync. Non-starter for me. I have zero interest in storing credentials in my browser (eg, passwords, autofill, etc) and even less interest in storing anything browser-related outside of my machine; I have no interest in synchronizing tabs across devices using the browser's own functionality.
Then there's the bits about recommending extensions or features as you browse.
Pocket can be disabled with about:config => pocket.enabled set to false (non-obvious but easy).
FF accounts & sync do nothing if you don't use them. The data is e2e encrypted. It is extremely useful for a huge number of people while doing nothing bad to those who don't use it. FF would be a worse browser without it.
Extension & feature recommendations are done on browser with no personal data sent to Mozilla. You can search the web for details, iirc it was also mentioned on HN.
I disagree. I could have been a hell of a lot more vindictive.
> Pocket can be disabled with about:config => pocket.enabled set to false (non-obvious but easy).
That doesn't remove the feature from the right-click menu. And, there's a ton of other configs in about:config which mention Pocket, some of them include URLs. Does setting pocket.enabled=false disable retrieval of those URLs?
FF accounts & sync do nothing if you don't use them... except recommend to me that I use them. The data might be e2e encrypted but that's still more attack surface than _not_ having the data there in the first place. Yes, it's extremely useful for a huge number of people but nonetheless it's still a privacy issue for me.
Extension & feature recommendations being done in browser isn't the point. The point is that they're _done_ in the first place. Which means that not only does Firefox parse and render content, but it inspects it and tries to determine what I'm doing and what extensions "might" help. Thanks but that falls right into creepy territory for me. It's only one step away from sending that already-data-mined data to some marketing company.
Trying to save my passwords is particularly annoying till I disable it.
Telemetry = tracking.
Not sure about what he means regarding plugins.
for example the about:config setting wording is `extensions.pocket.RelevantFeatureHere`
I'm really glad it can be turned off, but I also wish it wasn't there. I have trouble wholeheartedly recommending Firefox to others, because the default experience (without about:config tweaks) feels messy.
We must find some way to rollback that spiralling complexity.
Or maybe, like in the old days, burn it all and start anew?
The experience was one of the big reasons Unicode 2.0 raised the limit, as they never wanted to go through that process again.
- drops all legacy features tht aren't needed to provide documents anymore
- provide sane defaults
- a choice between
- 1) no JS
- 2) JS based on a small number of vetted packages for stuff line autocomplete etc
No DRM. No JS frameworks. Just plain old HTML goodness plus more modern goodness (autocomplete) on top.
In my view there's even room for ads as long as they are injected server side and don't report back anything.
Hopefully this could be so much faster that it could become a hit in tech and academic circles.
This should hopefully get people to switch to our new browser and force other browsers to start competing.
So why would other browsers even bother to compete with you? Do they bother competing with Lynx?
Styling is totally OK. And the browser could even be Firefox, just with a separate rendering path if it detects the page is html5core or whatever.
Old pages works just as before. New, html5core compliant pages loads blazingly fast and displays just as nice though.
There's no reason for that to have its own separate rendering path, or even to be its own thing. The process of validating it as 'html5core' would probably take more time than just rendering it as is.
Html and a limited subset of css is OK. I'd try to remove unused constructs but more importantly for the speed: as much as possible of what stands in the way for efficient rendering.
It will definitely not take more time to decide: you add a marker to the start of the document. The browser then sends it the fast path.
Turning off JS entirely will kill a lot of common webpages, so that's not really an option any more. Instead, everybody runs a content blocker, to try to battle with corporations over what dumb junk we're exposed to, or exposed by.
Corporations are also writing most of the popular web browsers. This isn't a fair fight.
And that's the rub.
None of this is actually about wanting to improve the web with a sane minimalist subset of HTML, or separating "documents" from "apps", it's about wishing the web never left universities, never got mainstream, and never got complicated by modernity or tainted by capitalism.
But you can't put that genie back into the bottle and, honestly, I don't think it should be done were it possible. The modern web enables a great deal of creative freedom and cultural expression which simply wouldn't be possible if it were only plain hypertext documents.
As an example:
<script widgettype="http://example.org/ns/widget/unitconv" src="unitconv.js"></script>
...more stuff in between...
<li><widget widgettype="http://example.org/ns/widget/unitconv" a-unit="cups:236.5882365mL">4 cups</widget> of water
It has the following benefits:
- You can host all of the files yourself if you want to; no need for a separate package manager.
- Full backward compatibility.
- Works with browsers that don't implement <script> or <widget>, as well as browsers that implement one or the other, or both. (However, it needs to implement either <script> or the "unitconv" widget, and one or the other has to be enabled, in order for automatic unit conversion to work.)
- The user can disable features they don't want, or customize them.
- If <widget> is implemented and enabled, then the script need not be downloaded, even if <script> is implemented and enabled.
There are other possibilities too. For example, autocomplete could use wrapping a <input> inside of a <widget>.
It's HTML only. No JS or CSS. All styling is done browser side under user control. All interactions are done using simple GET or forms and POST.
There are no cookies, and not even hidden form fields, All data you send with a request is visible to the user.
However, there are some features missing from HTML unfortunately; I had a different idea for how icons should have been displayed instead (I posted before on Hacker News), and that there should be a special tag for footnotes, but there isn't. Still, it is probably good enough.
But it's obvious to anyone that that is rapidly changing. As people try to do more and more with web apps the corporations now in charge of web standandards implement more raw access to system hardware and all the benefits of being in a browser go away while none of the downsides do.
Building one's own native app that direct-binds to the networking layer, passes user credentials around without the paid-for-in-blood browser API, etc., is going to re-invent the wheel on a lot of security problems that browsers had to solve (and history has shown developers love to ignore given the opportunity). It isn't just whether the web app will be a better user experience; it's also whether the app will allow, say, exploits delivered via the server-side state (introduced to your web app via user-modifiable content on your site) to sniff the user's password out of the pastebuffer or some such nonsense.
And if you go for a competitive alternative based on a more sane stack than HTML/CSS/JS/..., then you cannot compete with the content. Unless your new tech stack is really really really really better for current usage.
It probably means designing it for mobile first: small footprint, low energy consumption and a lot of resilience wrt to network hiccups. Plus an integrated monetization scheme that doesn't waste half of the bandwidth for ads or half the battery capacity to try to circumvent ad blockers - all that without selling the color of the user's pants to anyone wanting to buy it.
I know, utopia, utopia.
The phrase "fractal of bad design" comes to mind.. Although it was originally used for PHP, this anti-design-pattern seems to rear its head almost inevitably with popular and long-lived languages/systems (which I suppose includes C++, though I'm not qualified to judge).
I've heard people pinning hopes on WebAssembly. It does seem possible that eventually it could allow new languages to replace CSS and JS, maybe even support the development of new kinds of applications that replace (the current paradigm of) the browser as a cross-platform VM.
Also a lot of the things I wanted 5-10 years ago that I had to work around are now being included. For example there is a decent-ish http request API.
I don't like web assembly. I think it is actually worse in a lot of ways than the huge JS frameworks that people think that it will replace.
True. But if the web did not adopt those features, then you would have to install more native applications to fill the void.
If you make a simpler web browser, one that is doable by a newcomer, with the subset of features that you deem appropriate for the web, nothing is stopping you. You could still visit most websites that are content only. But for some of the web applications you would have to install the native version of those applications to fill the void.
Either way you have the same outcome. You have a simple web browser that can be made by newcomers, but you have this other application platform (Windows, Mac, Android, Linux) where "the complexity is obscene, the creation of a new operating system would be comparable to the Apollo program or the Manhattan project."
I think the privacy and tracker-blocking crowd would have a lot more options. You could also have browsers designed for low-power or weak-CPU environments. Better automatic limits on what code runs and when.
Next category I picture are browsers with really customized interfaces and displays. Different approaches to navigation, hotkeys. Tiling sites across the screen.
Browser functionality could be built into more devices and contexts (e.g. inside another application).
I know none of these is "staggering" but I'm one person brainstorming for five minutes. If enthusiasts and hobbyists all over the world could more easily tinker and try things out, who knows what ideas would pop up.
That doesn't actually solve the problem. Excluding webgl so that someone can write an accessibility layer doesn't mean we have an accessible 3D site; it just means we can't do 3D sites.
The thing about cutting features because they aren't ones that fit one's use case is that there's always someone who doesn't need that use case. "Not a lot of people use it so we should cut it" isn't a great criteria for a platform.
* Presentation (generally and CSS specifically)
* and accessibility
I know there is much more to the web than that and notice that I did not mention security. Those 3 things took years and lots of research and failure to get to today's status quo. Everything else is comparatively trivial when compared on the basis of man hours and money spent.
If you can really nail those three quickly and cheaply then everything else is trivial from a perspective of money and time.
I would even allow for ads since they would at best be banner images, not pop ups, not things that track you around the internet, and what have you. As for page style? Let the client decide, which ultimately means: let the end-user decide what they're most comfortable with.
Also there is a newly developed Gopher alternative called Gemini  that uses TLS by default, and supports natively as an alternative to HTML a Markdown-based simplified format. (Given that Gemini and Gopher are much alike, most of the content is also available over `gopher://`, and via an HTTP gateway it can be accessed from a plain browser, like for example .)
I've tried some of these myself, and unfortunately the experience is one of two extremes:
* either everything just works, and it works flawlessly, the page loads instantly, no pesky cookie consent popups, no adds, and it's just a pleasure to browse that site; (most "small" blogs fall into this category;)
So, like with any civic right, everything is gained through participation: if we want a simpler web, we need to actively start consuming a simpler web. :)
 https://github.com/michael-lazar/rtv. No longer maintained.
rtv is still a hosted app; it's hosted in a command-line interface with command-line rules instead of an HTML-rendering interface with w3c standardized rules. Take away the shell, and rtv won't run any more than a web page "runs" without a browser to interpret it. But these things aren't quite so different as one may imagine (the capability set of one is much broader; the compatibility set of the other is probably much broader).
At the same time, I love the vibrant opportunities to be creative with the modern web. I recently made a submission for the 7-Day Roguelike competition and used WebGL, WebAudio, and other various APIs to make something I'm really proud of. It's incredible that someone with little formal training can create art and easily share it with others over the web.
Is there a balance here? I almost want webpages to have a "simple web" view and a "rich web" option that browsers both support.
We can add to that the churn of websites trying to remain in sync with browser 'features'
Mission accomplished. The W3C constituents have created facts with their own browsers, and then they burned the ladder behind them. The classical move to stop others to get to power the same way you did.
It isn't "ladder burning" that countries already have electrical grids so it's hard to build a competing electrical grid.
since the list is short atm the broser or OS can periodically download the index and register each known protocol to a dummy handler that simply displays what one can do with it.
Monetization (if needed) can be done by auctioning commercial slots in the list. (Marking clearly which are free and open source and which are commercial efforts to support that protocol.) Each entry can have an explainatory link to a world wide web document, pfd, text file, DOCX, XLSX, PPTX, etc (go nuts) explaining these new and exiting times.
Ideally the software to work with the protocol can also be installed from or by the dummy at whim. If multiple [say] video:// handlers are installed the dummy can be configured to pick a default or present a menu every time thereafter.
Then we can end the days of circular finger pointing where not explaining a protocol is always someone else's fault and we silently agree to have error pages (or worse search results) if one tries to open a link like ipfs:// gopher:// news:// nntp:// etc
If all members of the collective of IT nerds know exactly what the user is trying to do or what desired behavior looks like we cant be hiding behind "I dunno!?" type error pages. Its just to embarrassing. It is our responsibility to teach grandma how to use magnet uri's if she appertains it.
I think it would be ideal if the handlers were able to run on a platform that was defined by open standards and well-sandboxed by default... the web is a good example of this.
While we can create a system that supports n protocols we really only need a hand full of new things at a time.
The benefit is fetching stuff over ipfs, onion, gopher, freenet, zeronet, dat, blockstack, news and even irc
Until we can visit ipfs://example.com after a clean install the whole project borders a pipe dream.
I argue that if you cant see the benefits we've done a terrible job explaining them to you. It is sort of a chicken and egg problem. Why would I put a news:// link on my website if you cant do anything with it?
The expected behavior is a prompt asking if you want to install a news reader and register with a news server.
Don't expect grandma to figure out that stuff by herself. I might as well not post news:// links. She would just be confused.
Dillo finishes starting before I finish clicking on its icon.
(As in, it loads and displays itself all in the moment between the button-pressed and button-released events.)
- - - -
Check out Effbot's "Generating Tkinter User Interfaces from XML" https://www.effbot.org/zone/element-tkinter.htm
There's a gulf between that and XUL, eh? ( https://en.wikipedia.org/wiki/XUL )
"The Wheel of Reincarnation" has been turning for a long time now:
X Windows!? NeWS? Postscript and PDF? (PDF has JS in now!) I'm sure we could fill a book just with languages and frameworks for GUI, eh? VPRI STEPS program created Nile, etc...
Display problem, Y U NO solved yet?
Why hasn't something (better than HTML/CSS/JS soups) congealed in this area? Is it really so hard? Are we just running in circles?
I'm sure the various character sets, error correction and parity, control codes etc constituted standards hell for terminals back in the day. But a solid set of conventions seems to have survived.
I'm not sure how much of HTML will survive in 45 years, and with what historical 'depth of field'. Is it more likely to contain <marquee> or web components?
The unique thing about JS is the fact that it's locked down, and further permissions need user auth. Android API has a permissions model too.
Any browser needs to run some kind of code, but in a safe manner, so we need watertight code Gaols - outside the above mentioned, it's not so easy.
Plenty of people are building browsers, yours truly included, but they're not building their own rendering engine, indeed for the reasons outlined in this article.
I think browsers will continue adding features until they become the inevitable end result, a portable operating system. Once browsers reach this point it will probably slow down and the next goal will be pulling it to pieces and making it modular so we can deploy whatever subset of browser we want for any given use case.
And we will probably all be using some "distro" of chromium.
I feel as if we are hurtling faster and faster to our ultimate doom. And all we seem to do is mash the gas pedal harder.
If we agree on that then I'm very interested to hear about non-reckless alternatives to our current bloat web.
If we don't agree, then I am not at all interested in hearing about Amish web.
"Hey! Why is my browser using up 10GB of RAM all by itself? It's so bloated!"
tl;dr: don't just blame the browser
You can remove the google integrations fairly easily and still get patches from the main project for core browser work.
My main point is that Microsoft could have written a new browser instead but they saw it was more efficient to just fork one.
I mean, would you write your own networking stack? Probably not. You'd take an existing tool and, if you really want, make it your own.
Most of humanity and what we do is based on those who made our lives easier with tools they built, and that changed how the manufacturing process altogether.