Kosmonaut: web browser from scratch in Rust
github.com
github.com
Such a simpler web spec would be relatively fast moving, not focused on backwards compatibility, but instead on simplicity of implementation. HTML would have to be written correctly (eg. balanced tags), old styling mechanisms would be removed so that layout engines wouldn't have to accommodate them. Everything would be pared down.
I believe this would open the playing field for many people to create browsers, would breath life into the now basically empty browser space and the Web in general.
Of course adoption would be a big issue, but that's always a big issue. I wonder why this wouldn't make sense to try, given the current state of affairs. It doesn't make sense to just give up on the Web. Why not re-invent it a litte?
A huge issue. Nobody is going to use a browser that doesn’t work with 99% of websites.
But, what's the alternative? Giving up the Web and giving it away to Google?
Right now I'm able to attend conferences I couldn't go to before the pandemic, because they have moved online, and some of the best ones are in far away countries.
Realistically, that can't happen in a primarily offline world. I'll miss them when they go back to offline, because I won't be able to attend any more.
But even before, many things I enjoy, as well as many opportunities, are not happening in any one location on the planet. They aren't local, and still won't be wherever I move.
Even reading & commenting on HN is not replicable offline. I've tried it: I've run real-life communities, places for people to meet and talk and make things together. As interesting as these are, the range of perspectives is narrow compared with the interestingness of an international community, even a niche-interest community like HN.
I think you may be right about "long-term consequences", but I don't think we'll find we can change most of what we do online to offline locally. Instead I think we'll find we just have to stop doing what we do online, and do something else instead. Hopefully something we enjoy, rather than something that feels forced upon us.
A good browser/server/IDE would both be easier and more powerful than any of the messy mixes of languages and document formats we use right now.
One day Intel goes and implements instructions which support video decoding. And then Microsoft takes advantage of them, and now users have a better experience. Now open source compilers have to implement them and AMD has to implement them and the cost of competing with the giants goes up.
Same thing with browser DRM. Either Firefox implements it, or Netflix tells all of their users that chrome is a requirement.
I don't know how to stop this type of creep.
For one, it would've helped if Firefox didn't drop the ball in the late-00s, when Chrome became the de facto best browser around. Google + Chrome did more bad for the web than Microsoft + IE ever dreamt of doing. Having the very same companies that make browsers vested in certain web features is a big no-no, but that cat's already out of the bag.
I'm not really sure if we can put it back in.
The reason people pay is the convenience! The DRM isn't required for that. If they dropped all DRM tomorrow, they would lose far fewer subscriber dollars than they spend on DRM implementations, license servers, key management, etc. They're just greedy, want control, and want to keep it illegal to break out of that control.
Meanwhile, any media "purchases" you make are gone in a blink if the company you bought them from goes out of business or just decides they don't feel like offering the service anymore. The funny thing is that most of the buy-to-"own" (where you don't actually own it) prices are similar to the cost of a DVD or blu-ray disc. Ditto for Kindle books and their paperback counterparts. All the promises of digital distribution giving consumers lower prices were predictable lies.
Regarding purchases and licensing, those are still stuck in the same business model and pricing as in the analogue days, this is true. But saying overall consumer prices are the same is ridiculous, since all-you-can-eat content subscriptions is a massive transition with no comparable offerings in the analogue past.
If you want to culturally enrich people, there has never been a better time to consume huge amounts of quality stuff for barely any money.
I'm not sure that's really true. Do you remember the bad old IE days? Half the web was simply broken on non-Microsoft operating systems, because Microsoft refused to follow standards.
They built proprietary extensions to the web, which the rest of the world - and particularly the open source world - had to reverse engineer and spend ridiculous amounts of effort to implement. And despite all that effort, we often never managed to do it - cough _ActiveX_ cough.
The situation back then was much, much worse than today in terms of open standards and cross-browser (let alone cross-OS) compatibility. And that was pretty much Microsoft's fault.
Google and Chrome have lots of problems. But they build on top of Chromium, which is completely open source. It does not have 100% of the features of Chrome, but from a practical perspective that seems to be mostly a non-issue, at least for me.
But Google has done more lasting damage I think. The effects are more subtle, things work. ...The way Google wants. We may never know what was crushed or lost by submitting to Google’s will. So the harm will be less visible.
One example is XHR, which is probably the single defining feature of the modern web.
Good standards simply codify whatever "proprietary" features we've found are useful.
It is like a kid just a saw a few rounds of cross fire than ran and tell the world how is was like World War 2.
Take your example. In 2020 there are already many ways that video can be decoded simply, efficiently and with excellent quality. We don't need to accept marginal user experience improvement at the cost of simplicity. So we don't accept changes to the standards at the expense of cost implementation complexity.
It's about having a different mantra. Instead of an emphasis on backwards compatibility and bleeding edge user experience, there's an emphasis on a democracy by simplicity.
Each of the two standards might not receive enough attention on their own, but they complement each other: getting rid of the necessity of ads means going lite is an option for website owners, and the lite web will allow for many different lite web clients (that might finance itself through in-app ads shown to the user). In combination these two might overcome some threshold and gain traction!
Which might not happen, ever. Sadly.
One natural place is for packaging apps. I have a lot of modern web apps packaged so they run as if they were separate applications rather than my main browser. A browser that was focussed on doing this well would still be very useful even if it only worked with the most up to date sites.
Lots of game UIs use internal browsers, which again could be another niche.
And, especially for languages with limited UI capability, a good embeddable browser could provide a decent way to build UIs. Again a niche where backwards compatibility is not so important.
I'd be pretty happy to make a split where I use one browser for document consumption and a totally different one for applications, and perhaps yet another for really old school sites. In an ideal world they could launch each other for the appropriate sites.
But... my beloved <marquee>!
We got most of the standard including CSS compressed down to 85K, using every trick I’d ever heard of and a few we invented.
By far the most fun I ever had at work, and top 2 for nostalgia.
But it got cancelled, and I’m not sure anyone else made a real go of implementing it, alas.
This is an opinion regarding style. Adding support for unbalanced tags is one of the easiest things.
No, it is not.
Yes, I bloody do!
And by the way there is a less radical alternative option: just give up support for all the legacy features, quirks and redundancies - perhaps this might simplify the code significantly already.
Another fact to keep in mind: there already are Gemini and Gopher.
Rather than a new web standard or ignoring "legacy", I'd point out that there are even web browsers for the Commodore 64 and Apple II. You don't need to implement every tag, the point of HTML is to ignore tags you don't understand and it should still render. Pages with correct markup are still readable in ancient browsers that don't understand CSS. If your page isn't readable in Lynx and Links, you didn't code it properly.
You can't support every site obviously, but Links [3] has shown you can go a long way by just supporting a subset of web features. The speed when you're not trying to render pixel perfect layouts is astonishing.
[1] http://www.jaruzel.com/gopher/gopher-client-browser-for-wind...
IMHO it could help a lot if a browser could let you configure the way it treat a particular unknown tag: just ignore it with its entire content or treat it like another kind of tag it knows.
Lynx/Links could really use an update (excuse me if they already have it - they didn't the last time I checked). There is nothing hard nor improper in supporting/using most of the HTML5 semantic tags.
Another thought: what if browsers develop the ability to render markdown natively (in addition to HTML)?
But indeed I'd love Markdown or something like that (AFAIK AsciiDoc is better) to be everywhere.
I actually evangelize Markdown on daily basis encouraging everybody to use Typora instead of MS/Libre Office in every case when there is no practical reason to use the latter.
People use command line based browsers. A limited browser is usable, just not for full web apps.
To start it, offer a website that checks websites for their compliance. At the same time, let webmasters register their site so that you can offer a directory of available content.
If you want to monetize your project, offer a search engine with ads for all sites that passed the test.
The icing on the cake would be a proxy service that transcodes complex websites into the simple standard by analysing the site with a headless browser.
That's why it's not going to happen. Even if you managed to reset the cycle it will just happen again but this time even faster. EEE/standards corruption is just too powerful, I haven't read a single successful strategy to stop that long term. So even a parallel subset of the web doesn't seem immune to that. Like the other day I was reading about KaiOS and you can guess who's already investing in that platform.
Google (and the subsequent overlords) are cancer and there's no cure.
I don't think it would ever replace the browser but I can certainly see it finding a niche for things like small communities like single board computer enthusiasts where resources are at a premium.
I have plenty of ideas that I have doodled over the years of how things could be done in the browser space, and I'm fairly sure I'm not unique in that respect. There must be some pretty good ideas out there.
The thing about balancing tags is a red herring. The HTML parsing logic is not the complex and slow part in a web browser.
A team at FB implemented flex to power React Native. I'm thinking that effort was made much easier given that they didn't have to account for floats, etc.
But the user is NOT an expert at styling a website, this is why we have designers to figure out which combination of layout, fonts, and colors work well together.
Firefox (barely) still has that option but it's disabled by default, Chrome had removed it many version ago, and Edge never had it from the beginning. IE11 still has the option.
(Additional unprivileged commands may also be useful, such as ability to specify colours by index number, and ability to specify the names of user configuration values where other values are expected.)
Of course this assumes users are competent designers. I think reader mode and similar is a much better solution to the problem.
But most websites have diverged from this since a long time ago, even such which represent mostly immutable content.
And floats are useful for primary-textual content. Wikipedia uses it a lot for example. Probably less useful for application-like interfaces.
WebAssembly + Skia engine via WebGL.
Using a programming language that only matters in the context of Flutter applications.
then you make a browser that is much faster for sites written in the new thing and build in blink for fallback. also make something in the same niche as electron, but only using the new thing. win devs over and try to cultivate another "this site best viewed in" phenomenon. gradually demote the existing paradigm to second-class status
the important thing is you probably need a well-heeled patron but you don't need to win over the existing browser vendors. (tbh I'm surprised facebook hasn't tried this yet, they'd benefit immensely from it even aside from being able to stick it to google)
make something better and people will gradually switch. reaching non-technical types isn't as hard as it's made out to be, there was a point where every early adopter geek type was going out of their way to install chrome (and firefox before that!) on their parents' and friends' computers for them. and if people switch, other browsers will have to follow
of course it's also likely that all the problems that necessitate a switch will come back even worse after. google made a js engine that was 1000x faster so people made sites that were 10000x slower. google sandboxed tabs so a bad site wouldn't crash the whole browser, and now complicated sites crash constantly because there's less consequences to it. but hey you have to imagine sisyphus happy after all
It was never terribly popular, because who wants to make two sites? Really, that plauges all such plans; everyone wants to build the fanciest, most "modern" site possible, and not do it again for a more constrained version. That's why few sites offer a JS-less version. Only AMP has made some headway, with the weight of the Google hegemon behind it.
Taking it further - the website author could possibly specify rendering engine it prefers to be rendered with(as specific version could simply be downloaded on demand from cdn, like common js/css libraries are). And pure webassembly apps (ie flutter) could skip the html/css/js bloat altogether.
But fair enough. In the wild you would have to use fallback pretty much always.
Still, webassembly-able gecko would be handy and would allow for experimenting with above mentioned streamlined 'web standard'. Web author could simply sign it's compliance to the 'standard' using meta tags, http headers or some other way.
There are certainly folks at hosting providers and similar service companies who advocate using different browsers for different purposes, e.g., for security reasons. For example, it makes little sense to use the same program to browse random sites on the web as you do to log in to your bank's website. However there are more reasons that just "security" (namely performance, IMO). If "security" is the only reason one would use a different program, then people just point to "sandboxing" and use one browser for everything.
As for paring down HTML, isn't that sort of what Firefox "Reader" mode or AMP does? If you try viewing some AMP urls in links text-only browser, they look particularly good, and the news site "paywalls" do not work. I have been using text-only browser and other, smaller programs to perform text retrieval from the web for many years and they work very well, much better than the gigantic omnibus everything-in-one programs supplied by the ad tech corporations.
Thus, the responses that claim "It would never work" make little sense to me because in my case it has already worked for decades. I doubt I am the only user who values speed and simplicity.
So, I don't think it's developers that are the problem. As a web dev myself, I'd much rather have less, mostly unnecessary, complexity to deal with, but I can't see a rational path towards that.
#1 80/20 is more than sufficient. If your browser legibly renders Facebook, Bootstrap, and maybe a dozen others, call it good.
#2 Fidelity is overrated. With adblockers and reader view, who cares about pixel perfect? Twitter, Reddit, and most other popular websites already look terrible. A better web browser doesn't help.
#3 Sites that care about that extra polish should use bespoke layout managers.
For a while, I had a thing about design grids and ensuring text baselines were properly aligned. Spent way too much time wrestling with layout managers.
Finally gave up and rolled my own. Less code, easy to debug, got exactly what I wanted.
Always had a notion to "port" my design grid based layout manager to the web, but I just don't care any more. I consume most of my news via RSS. Assume my target audience would do the same. So any future content I publish will be as stupid simple as possible.
There's terrible, and then there's terrible. If you try to implement things in a much simpler way, you will get many completely unreadable websites. Images will cover text, some text will be off the screen, it will be a garbled mess.
" [...] which explores the space inbetween gopher and the web, striving to address (perceived) limitations of one while avoiding the (undeniable) pitfalls of the other."
Yes, yes, yes!
would be relatively fast moving, not focused on backwards compatibility
No, no, no! Constant churn is precisely the problem with the web today, as it is what creates all that complexity and bloat. What you really need is a simple and stable set of standards, ideally something that won't change in decades (somewhat like how ASCII has been) so that any implementors don't have to engage in mindless trendchasing.
In fact, we already have a simpler set of web standards. It's called HTML4 and CSS2. Browsers like Dillo and NetSurf handle them well, and site like HN and Craigslist are an example of what the resulting format is like.
(But honestly tables suck bad time, I did wrote some table base hobby website back in 2009? or so and it wasn't nice (the experience, not the website which was quite fine). Sure basing a GUI on a grid is the best thing to do in many cases but tables are no grids. Grids are more flexible.)
(or it would if 5% of my users weren’t still using IE11, but that’s another story.)
You’re right, back in the day when everyone’s screen sizes were somewhat consistent, it worked, though still had many quirks.
It saddens me when Web sites assume they are in a full-screen window :(
The real issue with using <table> is semanticism, breaking DOM flow (sometimes creates issues for screen readers), and separation of concerns wrt data and style like you mentioned. Also, <table>s are hard to style over, like wtf is display: table-cell? Nobody seems to know.
But the number of times I see a colleague or fellow frontend cretin re-creating a tabular interface with a bunch of <div class="row"> etc... or wondering how to dynamically size the nested columns to fit the largest cell, I remind them: just use a table. Please.
You might notice that Hacker News layout uses <table>.
Now table layouts where quite a pain because they got very complex very fast. Flexbox and Grid are fine I guess, but I always found them a bit harder to understand than float and did not so much they offered that I needed.
Which of the view tens or so ascii's you mean? Probably us-ascii right? I.e. a thing so limited that it's only supports english and not even most of the other Latin writing based languages.
On the other side if we speak about plain text it hasn't be that stable at all for many years and only somewhat stabilized now with Unicode + utf-8 and utf-16 for legacy reasons. And even now we still frequently get Unicode updates.
The idea that us-ascii is enough/usable/acceptable for anything interfacing with users is IMHO a bubble limited to (small? part of) IT people from certain english native countries.
> In fact, we already have a simpler set of web standards. It's called HTML4 and CSS2.
CSS2 isn't simple. It's also fundamentally unsuited for web applications, which IMHO was still also true for CSS3 until recently (css gid). I mean think about how frameworks (e.g. bootstrap) for years did all kinds of tricks to emulate a css gird like features.
Also HTML5 tags like header/footer/article etc. are a must have IMHO and something like custom elements for better composition and reuse are a must have, too.
The problem with the current complexity of the web lies in my opinion in the combination of how all kind of features where bolted on top of a foundation which wasn't designed for given use cases and many of this features being over engineered.
So I believe such an approach needs to fundamentally revamp or replace both the DOM API and CSS.
That's an odd ratio to consider. Is high better or low? Or is there some particular positive optimal value we want to target?
In this case by contrast with CSS where no matter how much sophistication one tries to introduce into the styles its capabilities seem to be horizontally asymptotic or very substantially sublinear.
I reach for the word ratio because the concept (of two parameters whose magnitude varies and that would be meaningful in some relation) is a friend, and the word “better” is a writing trick to avoid having to define exactly what those are whilst still expressing the sentiment.
The use of ratio is entirely appropriate for conveying this, even in non-technical settings (and such use is pretty common). But to my ear, there's a definite implication that the relationship involves the two things typically moving in the same direction (and roughly linearly) such that it's notable when they've moved in opposite directions. (It's still very much qualitative - we're not really going to be able to assign meaningful numbers). Had you spoken of complexity/power, I wouldn't have noticed anything unusual.
Even so, I only really commented because I was enjoying playing with the idea of a simplicity/power ratio being somehow informative.
Now if you know which things to avoid (e.g. never put "--" inside your comments) and don't care about "pixel-perfect" rendering or any sort of interesting layout, HTML4 and CSS2 are not terrible. But if you care about any of that, watch out for dragons.
And before someone brings up "tables" for "interesting layout": table layout is unspecified. In CSS2, and CSS3 for that matter. Not only is it unspecified, it's not entirely interoperable across browsers even now, after literally decades of reverse-engineering each other. And for extra fun, WebKit/Blink's implementation is definitely not interoperable with the IE (Trident) implementation most table-based layouts targeted... As one example, changing the order of rows in the table can change the column widths in Blink but not in Trident.
Anyway, if one wanted to start with HTML4 and CSS2, one _could_ try to turn them into proper standards that can be interoperably implemented. It would take quite a lot of effort to do that, I suspect. 50 person-years is my initial guess, but there are a _lot_ of unknowns involved and a lot would depend on how much of the HTML5 and CSS-post-2 work that defined things rigorously could be leveraged.
A common theme in all these "reinvent the web/browser" discussion is going back to the web as a hyperlinked document library and not an application platform, in which case pixel-perfect rendering is neither necesary nor even a goal.
For example, implementing comment parsing per the letter of the HTML4 spec is extremely not-web-compatible
HTML5 parsing is completely specified and definitely compatible, even the error cases. Any stream of bytes will turn into a DOM. (Philosophical question: are they even errors anymore, if all implementations will produce the same output?) Perhaps that would be a good starting point.
And how exactly would one even put this genie back in the lamp?
In seriousness: Most Markdowns are 1) fairly similar and 2) sufficient for the vast majority of documents. If the goal is a stable, mature, and complete markup language, I'd be inclined to give LaTeX top billing. Markdown can of course generate LaTeX.
LaTeX can, whether through the old model of dvi, or modern tools such as xlatex and pandoc, directly produce numerous document formats or "endpoints" as I consider them, including HTML, ePub, plain ASCII (or UTF-8) text, or paginated formats including ps, PDF, and djvu. LaTeX is not itself fundamentally print-oriented. The fact that it can and does produce excellent print-formatted output is a feature, not a bug.
What it is, and pointedly in ways that HTML lacks, is capable of intrinsically handling document-centric (not merely "print") elements including footnotes, endnotes, and formulae, all of which still require kludges after over a quarter century on the Web.
Markdown itself does not address several typographic or document conventions, including formulae, but also odd omissions such as underline and coloured text. Whether those get shimmed into Markdown, or an alternate (light- or heavy-weight) markup language is adopted, isn't clear, but those are very annoying lapses.
For the vast majority of documents, this does not matter. Most online content, say news media, use little more than paragraph, italic, and anchor elements. Even bold and list are rarely used. Authoring in Markdown should be almost wholly sufficient, but it's (La)TeX which has sufficient richness of expression to serve as the common underlying document format language.
Late edit: It also occurs that another principle angle of attack on HTMK alternatives, raised elsewhere in this thread, is that these cannot guarantee pixel-perfect presentation. That results in rather a "damned if you do, damned if you don't" situation: propopsed markup alternatives either cannot guarantee layout or over-guarantee layout. These objections rather want for consistency.
Counter argument: then why do conditional comments behave differently in each browser engine?
I am not talking about trident, but about CSS hacks for presto, gecko, webkit and blink as well.
If every browser would render as specified, we wouldn't have that outcome.
As developers test on webkit/blink primarily, chances are very likely things will not behave the same in other engines, and if blink violates the spec then everybody will also have to violate the spec.
The internet is built on such bad standards that you cannot even rely on HTTP to work correctly. 206 partial content headers behave differently among all web servers and proxies, and even nginx violates the spec there when it comes to multiple ranges, let alone chunked transfer encoding support.
> Counter argument: then why do conditional comments behave differently in each browser engine?
They don't. IE5-9 sees conditional comments specially, others don't.
> I am not talking about trident, but about CSS hacks for presto, gecko, webkit and blink as well.
CSS isn't HTML5, and those hacks aren't conditional comments, and don't rely on parsing differences.
> If every browser would render as specified
The claim was about parsing HTML5 and generating a DOM, not rendering.
But the funny thing is: they forgot to specify display: table and everything in it.
If you're interested in all the values that are only buried down somewhere in the specs, I'm building a CSS parser [1] that probably will never be completed.
[1] https://github.com/tholian-network/stealth/blob/X0/stealth/s...
Everything else is to me a matter of compression. Netflix's success seemed to me 50% good marketing and content and 50% compression and data handling.
It is wrong to think that a webpage has some sort of canonical view on it. And FB, Twitter and even Forbes is all about generating the impression of group perspective being one thing as opposed to be views on one, perhaps elusive, thing.
So no flexbox and grid? Back to using tables and floats for layout? (And reintroducing framesets and font tags!)
Good luck getting web designers on board.
Every project that grows large suffers the same inevitable descent into complexity. Things become so complex that it becomes hard to try out new ideas, which leads to stagnation. Eventually a better and leaner successor upsets the incumbent and the cycle restarts.
The key to creating great ecosystems is speed up that cycle. Design a system that encourages rapid growth and failure.
The 'web' should become a minimal hardware abstraction layer that offers safe access to graphics, audio, filesystem, and basic networking. Everything else could be built on top of that.
If someone has a new great idea for HTML or CSS just build it on top of the abstractions and hope others become interested. If someone wants to build a new browser they only have to implement the more manageable core.
The WWW will become the world wide app server. Focusing heavily on an app like experience.
Then there will be a push for a text only implementation to bring back the good ol' days when people actually want to read something on the internet treating it more like a book.
There's nothing stopping anyone from publishing a primarily text-based site if they want, or an "app" site. The web isn't a zero-sum platform, there's room for everything, and no objective definition of what separates "documents" from "apps" to base such a division on to begin with.
No one wants the web to be forked except for people on HN who wish everything done with it since the 1990s could be sent into quarantine where they can't see it, but this isn't something the public wants, or that anyone is working towards.
The problem with adoption of the text only standard would probably be that the generic browser will support that use case just as well as the simple browser. In general it would be hard to choose between one or the other world.
Rather than that, how about offering a very simple CSS on top of RSS? So that feeds could be personalized a bit, should the clients choose to support this?
Simultaneously, blacklists of domains and browser extensions to scrub viewed pages of any references to sites not subscribing to particular philosophies.
Maybe we should go back to Gopher? (I almost mean this seriously--it was much more lightweight.)
With any sort of grand proposal like this, you need to think about all the different people in the ecosystem and why they're going to be interested in moving over to your system. I don't think AMP has really succeeded, but without having publishers on board it would have gone absolutely nowhere.
(Disclosure: I work on ads at Google, speaking only for myself)
No need for new standards, you just implement recent standards properly and don't pay attention to the real world (as in "what people thought was HTML at which time").
It might be more worthwhile to clean up some existing rendering engine, factoring out kludges (for the aforementioned "real world") into code that can be disabled at compile time so we are left with a FOSS "pure specs" implementation of current specs. I personally would be interested in seeing what breaks, betting on "not much".
Unfortunately for your purposes, The specifications are defined in a layered way, and you can't just implement the recent ones without everything underneath. And then HTML5 codifies a lot of "real world messiness": early browsers did all sorts of strange things, and then layered on even more strange things to try and be compatible with each other. HTML5 threw away the approach of specifying the way things would ideally work, and instead focused on specifying the way things actually do work. Which means to implement HTML5 fully you really need to do quite a lot of work.
To mirror userbinator's comment: why would it be necessary for the standard to be fast-moving, if the intention is to offer a radically simplified subset of the web stack?
If the aim is to make it much easier to implement a browser, stability should be a top priority.
I'm reminded of a recent HN discussion on whether it makes more sense to define a minimal subset of HTML, or to use an entirely different language, like Gopher and Gemini. [0] I see several others in the discussion here have already mentioned these two.
Or possibly a display renderer of some sort, like postscript.
As long as the rendering engines are distributed via CDNs, it would be extremely fast.
But 2 big issues:
1. You have to get the specs right from the beginning and for the long term
2. You have to get traction to move the whole web to the new standard
Hackers can do it, starting with a small user base, writing blogs on the new stack and improving it day after day, adding new features. Then more people start to use the new stack and Hackers start to build services on it and more people come because it's faster and better structured than the old web. Mission accomplished.
You lost me there. If you want any kind of adoption, you need to be backwards-compatible as much as possible. Otherwise you're just building a toy for geeks to play with, and you end up only attracting "spec perfectionists" to work on it (that is, people who care so much about the spec/implementation being beautiful and elegant that they never successfully ship something people can use).
> HTML would have to be written correctly (eg. balanced tags)
This is a common misconception, unless you're talking about XHTML (which was mostly a failure adoption-wise). HTML is a variant of SGML, which does not require balanced tags (though you can specify that certain tags must be balanced, of course). Certainly you'd prefer to enforce them in some cases where it makes sense (like <em>), but things like <br> do not need a closing tag (and do not need to be expressed as <br/>).
Anyway, I think the overall issue with the web today is that people want it to be a complete application development platform + document layout system. The goal seems to be to be able to build any kind of application as a web app, and allow them to do anything a native app could do (though hopefully with better security). Not saying this is a good or bad thing, but if that's the goal, complexity is inevitable.
This is literally how anything every has started :)
> The goal seems to be to be able to build any kind of application as a web app
Been doing this for several years... it's really unpleasant... and I love programming.
There are numerous "HTML page simplifiers" (most based on Readability's engine AFAIU), which might shim behaviour and compatibility for legacy pages.
And content itself is text, not code. Slavish backwards compatibility is not a strict requirement.
I think that's really the key to this that makes the "worse is better" argument miss the mark here. HTML succeeded because anyone could open up a text editor, learn a few simple rules, and have a web page in short order. It's fantastically more complicated now, but unlikely to be supplanted because we have two and a half decades of HTML+CSS+JS out in the wild. People work hard on cross-browser compatibility because it's not going away, not because it's fun.
And all that fragile, brittle content out there will eventually break. The question is when compatability is lost, and in the name of what.
Keep in mind that I'm specifically targeting text and textually-oriented document content. The modern Web can be considered generally as having four principle modes, three ofwhich I'd treat separately: documents, as described, commerce (probably hived into a dedicated application), media (likewise), and apps (which want a VM engine, e.g., Chromium).
A surprisingly large set of apps, and certainly many significant ones, are principally document-and-discussion engines, for which lack of an intrinsic model within the document markup and client presentation is the raison d'etre of those apps. Either having a paired discussion platform, or integrating discussion into the browser itself, would address much of this.
Other content elements which have become significant online include both advertising and DRM. These have been mistakes.
Web browsers have evolved to basically be an OS. You could essentially revert to the old days where it was simple, but why would you?
Users want more features in their web apps, and the standards/web browsers make it possible.
We don't need tons of web browsers, just like we don't need 100s of operating systems. We just need a few really good ones.
Well, more features in web apps isn't what I want; it is instead more and better features in the browser itself, such as:
- User stylesheets and user scripts.
- Ability to save and recall form data using local files.
- Ability to load animated GIF/PNG as videos.
- Request/response overriding (this can also be used to add the Do Not Track header).
- ARIA view (even for display on screen, not only for visually impaired).
- Better keyboard commands.
- Table of contents view (displaying the list of <h1>, <h2>, etc).
- Developer console (which I think newest versions of Chrome and Firefox already have, anyways).
While it sounds like it would make browsers more complex, I think it would actually reduce complexity, because the browser would not need even more programming capability and APIs just to enable web developers to create these kind of features themselves in a thousand variations of Javascript that adds bloat to every connection and slows down end user devices.
And, yes, it would reduce complexity in the ways you specified, in addition to improving efficiency and allowing the user more control, and these are good things to have.
Maybe someone will make a web browser program that can do these kind of things.
- Apply an animation (or other style) to any CSS styles that specify "text-decoration: blink".
- Specify what colour to use when a CSS rule specifies "background" as the colour name.
- Make all transitions (or animations) twice as fast or twice as slow.
- Prevent certain CSS commands from being used entirely, or change their meaning to a different command.
- Select elements by the CSS rules that the document applies to them (even if those CSS rules are disabled, and even if class names are unpredictable).
- Define exactly how big a "in" or "px" or whatever unit is.
As OSs browsers are really bad. You don't have access to the underlying computer, the security model is broken. Just recently Apple announced that Webkit will clear local storage every 7 days (and why? Because the security model is broken). That's not very OS-like.
> We just need a few really good ones.
There is literally only one really good one: Blink. And it's not even that good.
Do they? Or do web developers just chase after new, shiny things?
Choose an audience that is disenchanted with the modern web, choose a subset of HTML/CSS that reflects their needs, create a prototype that demonstrates the idea, then watch people adopt it.
This is more-or-less what is happening with Gemini. It is a bit different in that they modelled their ideas on Gopher then addressed the shortcomings of Gopher, but there appears to be some adoption now that a specification has been produced: multiple clients and servers have been created, while others are creating content. Since the community shares may common interests, growth will probably continue for a while even if popularity is forever beyond its reach.
Doing something similar with the web will certainly produce a different outcome. It may even exert enough pressure to create a "clean" subset of HTML/CSS for specialized applications that is easier to implement.
The core functionality would have a precise (as possible) and extensive definition with an agreed test suite encoding the expected behaviour (as much as possible).
This would allow development of a shared implementation of the peripheral layer, while browser innovation could continue on the core functionality (JS and rendering performance, battery usage etc), and on innovations in the UI.
That was the goal of web standards with xhtml cira 2000-2008. It ended up having the opposite effect of being "relatively fast moving" and really slowed development down.
At some point they realized that figuring out balancing tags wasn't really all that hard for browsers to implement. For old styling mechanisms, browsers can just warn against using them.
Only problem is how to deal with navigation to other parts of a website.
Something like this would be hostile to advertisers and bloat. Ideally it only has essays, papers, and other stuff that makes you smart.
They don't achieve adoption.
But if there would be place in the internet where every page would stick to the same limited feature set, the new browsers could focus on those features and there users would new a place where they would not encounter broken pages. In addition, users of the traditional browsers (probably the majority of users), would still be able to visit that place too.
i am pretty confident that, although i haven't tested it, it would work in both kosmonaut (if you download and save the files and submit content with something like curl, but use kosmonaut to display it)
i bet it would also work with that apple se / raspberry pi combo also in today's top page.
Let's keep HTTP for metadata and cache control (don't want to download big images unnecessarily), with a bunch of headers for negotiating preferred CPU architecture and other hardware stuff.
It's different enough from the web that it might actually work, for some value of "working".
Everyone wants simplicity but nobody agrees which parts are the superfluous ones. As long you pose the question vaguely enough people on HN will agree because any engineer knows "simplicity is good". But if you get more concrete about what to remove, watch the pushback:
- Lets remove https, http is much simpler. (The privacy and security people will protest: We wanted simplicity but not like that!)
- Lets remove all accommodations for accessibility - who cares about that stuff anyway? (Well at least the people who needs it does!)
- Lets remove flexbox and grid - table tags and spacer gifs were good enough for everyone when I was young! (The law of conservation of complexity: You move the complexity from the browser implementation to the design implementation. Since there are more web designers than browser developers these days, it is not a good tradeoff.)
- Lets remove colors and fonts and interactivity, the web is only intended for reading science papers! (Yeah just like the printing press was only intended to print the Bible, doesn't mean it it wrong to use it for other stuff.)
- Lets remove HTML - people can just download PDF's!
For a modern browser, the two hierarchies would need to be dynamically linked, but specifying the "view hierarchy" in terms of a (very limited) HTML/CSS subset should yield the advantage that the correctness of the transformation step could still be inspected with a browser?
Of course you can't have any form of dynamic HTML and accessibility would go out the windows.
Now we have AMP (Accelerated Mobile Pages). Why not build a web browser focused especially on this? Actually I made one: AMP Browser (https://ampbrowser.com)
tl;dr an attempt was made and failed. Turns out there's not enough incentive for websites to convert to your stricter html replacement.
But what if you didn't have to implement all of them?
Now, some people would suggest we jettison JavaScript and/or CSS entirely. Or at least all of the additions made to them over the past decade. I think the idea that a browser like this would gain any traction outside of hardcore enthusiast circles is pure delusion.
Instead, what if features were prioritized based on how much of the web uses them? I'd bet that 90% of the web only uses 50% of the web standards out there. Some things like Flexbox are used on practically every new site that gets built these days. But there are dozens of obscure CSS properties that most web developers probably don't even know about, much less use. And JavaScript APIs? There's a host of bespoke progressive-web-app APIs (USB access, anyone?) that hardly anybody uses.
Also, a huge part of the web's baggage is maintaining backwards-compatibility with the entire history of content. This is well and good, but not an ideal that an indie browser could afford to uphold. Frames, image area tags, etc. There's probably a long tail of features - many of them deprecated - that could be jettisoned without having much impact on the average user's experience. Even things like "float", which aren't deprecated, may have been instrumental at one point but are no longer very important.
Prioritizing the standards that matter and de-prioritizing the ones that don't could dramatically cut down on the effort necessary for an MVP.
Taking this further: how do we know which features to prioritize? Most front-end devs probably have a rough idea, but what if we got empirical with it? What if we automatically tested the top 10,000 websites or something and made note of which CSS properties they used, which JavaScript APIs they called out to, and ranked them by frequency (and by popularity of the site?). We could chart a clear, direct path toward "what does it take for a browser to be useful in 2020?"
It's possible this browser could even include existing JavaScript polyfills (https://developer.mozilla.org/en-US/docs/Glossary/Polyfill) to help bridge the gap for things that it hasn't yet implemented. Leaning on work that's already been done by the open-source community.
I like the idea, but the migration path needs some serious thinking.
Though for semi-enthusiast users (HN readers), who want things to mostly just work but are willing to put up with some minor discomfort for the sake of idealism, that second part may not be needed.
These aren't things where you can just scan the CSS of the top websites to find out if they're being used. These are things where you'd have to do visual comparisons to the output of at least two other browser engines to determine if you end up with the same result.
Building a browser engine from scratch is imho more doable now than it's ever been before (excepting EME), due to the insane effort by the WHATWG standards to truly describe what is actually happening in browsers (rather than coming up with some theoretically pure description of what is envisioned to happen), and the similar level of detail on the CSS side to the myriad interactions between properties, along with the huge set of testcases for all of that.
Yes, there's _a lot_ - but compared to how loosely specified it all was in the past, when the instruction for building a browser engine was: "reverse engineer the bugs the dominant browser engine of today made in reverse engineering the bugs of the dominant browser that came before, and emulate that to your best ability", anyone starting from scratch nowadays has a way better chance at succeeding.
I guess I was drawing a distinction between a certain subset of functionality that's definitely being used constantly everywhere, like the core box model, vs new features that have gotten layered-on over time and specifically designed not to interfere with or change what came before. For example, the CSS Grid standard has zero effect on any part of page layout unless it is explicitly invoked with "display: grid". These hard barriers were drawn to maintain backwards-compatibility, but they could be leveraged to carve out pieces of functionality to not support, or at least defer support for.
> Building a browser engine from scratch is imho more doable now than it's ever been before
I agree. And I would actually add Rust as a factor for that. Don't forget, Rust was literally purpose-built for building a web browser. With its focus on memory safety and safe concurrency, I'd bet it will act as a very real force-multiplier when it comes to a project like this. Devs will spend that much less time chasing down race conditions and memory errors, while at the same time getting something highly parallel and performant.
I wonder whether one could reuse testcases from other browsers. Might be easier than having humans translate those WHATWG descriptions, written for humans, into a form that computers running tests can use.
And nitpick: it isn’t easier than ever. It was a lot easier for Tim Berners-Lee and the first few other browser writers, before there was a lot of agreement on how a browser was supposed to behave. Certainly, before JavaScript and css, SVG, XML, etc. The scope was a lot smaller.
Even better: there is a shared set of test cases and infrastructure that the web standards and compatibility folks have built: https://wpt.fyi
https://manishearth.github.io/blog/2017/08/10/font-size-an-u...
-----------------
The syntax of the property is pretty straightforward. You can specify it as:
- A length (12px, 15pt, 13em, 4in, 8rem)
- A percentage (50%)
- A compound of the above, via a calc (calc(12px + 4em + 20%))
- An absolute keyword (medium, small, large, x-large, etc)
- A relative keyword (larger, smaller)
The first three are common amongst quite a few length-related properties. Nothing abnormal in the syntax.
The next two are interesting.
-----------------
I've been doing front-end web dev for nearly ten years, and I've never even heard of those last two, much less used them. That's the kind of thing a new browser could defer support for until after the MVP, while barely detracting from the average user's experience.
Though this does remind me that i18n is a thing, and how gnarly of a problem it must be for a piece of software so concerned with text flow/layout, and ideally it's not something that a theoretical upstart browser would punt on.
Leaving out rare features to build a browser more quickly only makes sense if those features let you remove a lot of complexity from your implementation.
> Alright, this is where it gets complicated.
I haven't implemented any of the above myself, but the author at least seems to think the last two are where the complexity is concentrated.
Huh, that's interesting to hear you say that. I hardly do any web development at all, but I was using both of those things for personal/toy web sites over a decade ago.
Just goes to show you that even rank amateurs can end up exposed to things that professionals haven't seen, for whatever reason.
- Absolute size keywords ('xx-small', 'x-small', 'small', 'medium', 'large', 'x-large', 'xx-large', 'xxx-large') may-or-may-not work — and the resulting size may-or-may-not have a relationship to the <canvas> elements surrounding environment.
- Relative size keywords ('larger', 'smaller') can be hit-and-miss too.
- Absolute length values, defined with px, pt, in, cm, mm, pc, will usually work as expected.
- Viewport lengths (vw, vh, vmax, vmin) will often work; note that these lengths are set on creation and don't automatically resize when the viewport dimensions change.
- For lengths defined by the font itself, rem will use the root element's font size for its reference; %, em, ch can be less helpful. Again these won't automatically resize in a responsive environment.
- Of the rest, Q is not supported by Safari browsers, while cap, ic, lh, rlh, vb, vi are not supported by any browser. Avoid!
In that case the browser would fail to render or even load some websites, which would convey the idea that the browser was a poor piece of software.
But if a CSS property is invoked that the browser doesn't know about, it simply ignores it and moves on. The same goes for HTML tags and attributes. This is less true for JavaScript features because accessing a field of an object or attempting to call a function that doesn't exist will throw an exception and cease execution. Though on sites whose JS is mostly peripheral to the content, this can still sometimes result in a mostly-functional site. You could also play a game where you stub out enough of the APIs to prevent exceptions being thrown, without actually fully implementing the features. i.e. make an API function callable, and just not do anything.
The idea isn't to write off parts of the web entirely, but to be smart about how things are prioritized and aim for graceful degradation of the overall experience, as a way of dramatically lowering the bar for what it takes to make a browser that could be reasonably used day-to-day.
ps: 10$ more on a 'this lowered my medical bills' outcome
but I'm still willing to bet on how a week of ultralight web would feel to them :)
- forget everything about quirksmode and all kinds of workarounds that browsers have today.
- only accept Javascript from a vetted repository that contains things like autocomplete and ajax reload.
- and here comes the smart part: embed it next to an ordinary engine, ideally in Firefox, add a meta tag or content type or something that will get the browser to try to render it in this engine.
1. The idea is to get it to run extremely fast, and
2. get a few websites to optimize for it (Wikipedia?)
3. once people recognize certain pages loads extremely much faster in that browser they'll flock to it
4. more sites will start optimizing
5. since Javascript is extremely limited we get back to a saner content web
Much easier to get adoption if you can demonstrate performance benefits and electron apps are more performance sensitive than webpages in general (who really cares about Wikipedia rendering speed - it renders fast enough)
If so it has some huge downsides that overshadowes it.
Another way to think about this is, people were already thinking along these lines and tried to build something, and that thing is AMP. If you want to build something that avoids the failings you see in AMP, you're going to need to think hard about how your plan is different.
- that everyone has to serve all their content from a single domain. I only suggest serving optional Javascript from a single vetted repo.
- that the distribution repo should be owned and controlled by one if the worlds largest advertising companies.
- that the solution only should cover mobile.
For your other points:
* The AMP project is now part of the OpenJS foundation, along with Node, Electron, and others: https://openjsf.org/blog/2020/06/23/openjs-world-day-one-hig...
* AMP is not specific to mobile, though it did start that way; there are sites that serve all of their pages in AMP format to both mobile and desktop users.
(Disclosure: I work for Google, speaking only for myself)
Meaning that right now it isn't that way, right?
> The AMP project is now part of the OpenJS foundation, along with Node, Electron, and others: https://openjsf.org/blog/2020/06/23/openjs-world-day-one-hig....
For some reason everyone still seems to associate amp with Google, and the only times I can remember finding AMP pages are when I search with Google.
If a site is technically AMP but served from a non Google domain, I admit I haven't noticed it.
Correct, the current spec doesn't allow that. But, as I said, I think that is something that could reasonably easily change if many sites wanted to publish with vanilla CSS and HTML.
> For some reason everyone still seems to associate amp with Google, and the only times I can remember finding AMP pages are when I search with Google
Google started the project, and is still by far the biggest contributor. But Bing also supports AMP, caching and serving AMP pages: https://www.bing.com/webmaster/help/bing-amp-cache-bc1c884c
So you start off with a small index that includes Richard Stallman's web site and a few thousand others, then add many more as things like flexbox or whatever get added.
That feeds in nicely to the development process. The implementation of each new feature has the potential to open up thousands more sites to the index. In fact you could list bounties not in dollars but in the number of new sites a given feature can bring to the index.
That way users look at the search engine to first discover the sites that work in the browser. You could go retro like the hand-crafted directory Yahoo used to use, or automate the process. Either way, it's a big improvement in UX. Compare: "While the supported sites do load fast and look great, their search doesn't cover enough sites for my browsing needs." To: "Wouldn't even load Reddit this thing looks hopelessly broken."
I bet that it wouldn't take too much effort to get such a project to a place where you get a sizable index with the core feature being the lack of inclusion of sites with dark patterns. Like, an hour spent in this browser is filled with 80% critical reading whereas you'd just be infinitely scrolling through memes 80% of the time in Chrome...
People will very much tend to prefer using browsers that are fully capable. If your browser only works on 90% of sites, that's not good enough to keep users, it's exhausting to keep switching back and forth.
To escape the modern web, you have to offer something that the modern web can't which people are willing to go out of their way to get.
Some ideas: privacy, anonymity, no tracking, no DRM, global identity (pubkey based). I don't know if any of these would actually be sufficient to drive a new market, but I think creating a new market is the only way.
Pubkey based is good, but a global identity is a recipe for disaster. Ideally, you derive a unique identity per domain, while still managing only a single (master) key pair at the user-level.
Even though many sites were built specifically for IE, it was very rarely bad enough that you couldn't manage with Firefox. Compatibility hadn't gotten that bad.
(If you were going to make a dramatically simplified browser today, however, I do think this would be an excellent route to go.)
These are strongly in conflict with each other: if you have global identity what keeps that being used for tracking? This is the controversy around advertising IDs in mobile apps.
The experience would be much better for the user if it was all strict, as I suspect things would be faster.
I don't think it would have any observable effect on speed. As far as I know, the bottleneck is not parsing the the html syntax, it is rendering.
The early authoring tools also generated pure garbage for markup. So if you weren’t forgiving, you lost users.
Pandering works.
I think this is the trap that non-Chromium MS Edge fell into. I don't doubt that they supported a large subset of websites very well, but the average experience was brought down a lot when it randomly broke or massively slowed down on random websites.
The MS Edge case also suggests that it's not enough to just support a standard, it must also be reasonably optimized, because websites can be intolerably slow otherwise. I think many websites, especially web apps, assume that the user's browser is quite fast and can chew through a lot of load.
The problem is the same one faced by people trying to build MS Office competitors back in the 90s and 00s: while that's likely absolutely true, they don't all use the same 50% of those standards/features, so you end up having to implement all of them, or your users will blame you when their favorite random niche website doesn't work, and ditch you for Chrome.
If implementing 100% of web standards is intractably large and complex, then:
Implementing 50% of web standards is intractably large and complex too.
Unfortunately, you can't turn a humungous problem into a friendly little one by dividing by 2.
I would think in terms of dividing by 10 or more. How much of the web only uses 10% of the web standards? My guess is most of it, so we have a chance.
> Taking this further: how do we know which features to prioritize? Most front-end devs probably have a rough idea, but what if we got empirical with it? What if we automatically tested the top 10,000 websites or something and made note of which CSS properties they used, which JavaScript APIs they called out to, and ranked them by frequency (and by popularity of the site?). We could chart a clear, direct path toward "what does it take for a browser to be useful in 2020?"
This would be great data. Something a bit like caniuse, but showing feature usage rather than browser usage.
Getting this data and maintaining it is a full-time job for a team. You can't just fetch the front page of sites to get this info. You need to login and use functionality. Perhaps existing browser telemetry would do a better job, letting users generate the data during normal activity.
However you do it, the cost of this idea is mounting up fast :-)
I just need background images, absolute positioning, <area> + image-map, and form submission to work as expected. No JS.
Classic Macs aside, I would be thrilled to find a no frills rendering engine that I could package up like an Electron app serving from localhost, but without all the performance expectations of electron apps. I'm imagining like what Ionic does for apps -- just wrap everything in an OS provided web viewer -- what's out there like that for desktop?
I have no idea whether it’s using electron under the hood or just a native webview (or something else?) but might be worth checking out.
Here it is: Sciter (https://sciter.com) and Sciter.Quark (https://quark.sciter.com) in particular.
As unlikely as it may seem, I can well imagine that a dedicated team produces an alternative browser that - feature-wise and functionally - is good enough for daily use for most people. For the life of me, I cannot imagine they will come up with a browser that is as secure as Chrome.
Let's face it the amount of work and money that has been put into Chrome's security is amazing. As much as I love Rust and how it helps us write more secure software, it only gets us so far when it comes to the multiple threats a web agent implementation has to face.
https://www.chromium.org/Home/chromium-security/memory-safet...
(Here’s a quick reference I found, I don’t know if pcwalton has more details https://news.ycombinator.com/item?id=12876603)
The overall trends tell me that in the absence of a proof assistant, however carefully you scour your code for bugs, you will miss some. And 70% of the ones you miss will be memory unsafety unless you are using a system that explicitly prevents this.
97% of users don't care about security issues that Rust can solve in principle.
Let's face it the amount of work and money that has been put into Chrome's security is amazing.
A big part of the browser mess that we are in comes down to just how much you have to do in order to support all modern web applications.
Remember the claims about Mac OS X security back in the early 2000s? Mac OS X wasn't secure because it had no security issues, it was secure because nobody bothered to attack it. As it became more popular (and it had to become very popular compared to what it used to be, which took several years by itself), it also attracted people attacking it.
That would be the same story with a new browser. Or anything new and obscure for that matter.
Designing these sorts of security features up front isn't fun, and makes it take a bit more time before you get to your first page render, so there's a lot of slogging to do before you get there. I can understand how someone might lose motivation that way.
Also: don't paint us all with such a broad brush. I'm pretty indifferent toward Safari. "Fuck Safari" would imply I care enough to have a strong opinion about it, which I don't.
There may be battery use differences on iOS too (the UI, networking and other pieces are still Chrome’s), but not of the magnitude described here.
My meaning was that Safari is heavily optimized for power usage because most people using it are on mobile devices, and the difference is dramatic, at least on macOS where you can compare it.
I wonder how Chrome's traffic compares across mobile, laptop and desktop (I don't think laptops can be detected in browser stats). They certainly seem to focus on maximum performance above all else.
Safari's tracking protection works very well; we know because Safari ad prices have dropped significantly: https://appleinsider.com/articles/19/12/09/apples-safari-ad-...
Hopefully this can be fixed some day. I’d gladly switch from Firefox.
We are all talking about something between Lynx and Safari.
EDIT: reply to c-smile below (HN won’t let me reply, sigh):
My “in theory” was referring to Kosmonaut. Then I pointed out Sciter as evidence that something similar has already been done.
[1]: https://github.com/sciter-sdk/rust-sciter [2]: https://github.com/sciter-sdk/rust-sciter/blob/master/exampl...
[0] https://azul.rs/
[0] Yes, I know there's more to it than that.
Browsers are a universal medium both for content and UI for app and that's great. But they are kind of the most wasteful creation ever. The most obscene apps of yesteryears would do a lot more with a lot less. An example of that is gmail taking 600MB memory (according to chrome) far more than a desktop client that didn't depend of the server doing all the heavy lifting would have taken. It would have all my mails locally, would actually be much faster changing pages (if done correctly).
But I digress. I think the complexity comes from (apart from over engineering syndrome) trying to deny that there's two very distinct use cases of web. One is nicely formatted semi static content and fairy dynamic stateful applications. I think designing a set of features (even modes in browsers that a page needs to declare for) can simplify things a lot.
The second thought I had was a brand new layout model/engine that does away with all the crafts and define some powerful primitive that works in a more well defined way that doesn't take a Google to properly implemented. Now I was thinking of two options of how to get that accepted.
1. A page can declare itself using the new primitives (now there can be two primitives for doc/app or this simpler one might handle both?) and the engine is small enough that it's worth having two in the browser. And the saving from some pages specially as it grows over time specially for well maintained/popular pages use the faster version the overall browser efficiency increases even if you can't remove the old engine.
2. Can there be a translation layer that can take a old layout page and rewrite the css/layout into the new primitive. It's perhaps slower than the current engine and perhaps on changes to content/viewport/scroll retranslate a lot but perhaps allow one to drop the old layout engine a lot faster.
Complete bonkers? I am almost certain it is but I don't know enough to tell and I have been meaning to ask to a crowd who can answer.
I agree it must be challenged, and I think the way to go is to create a simpler web spec with a mantra that is totally oriented around simplicity. The web seems to have died this week, and I'm not sure how else it can be reborn.
Edit: I see you work at Mozilla. IMO Firefox is the most important software project in the world (not hyperbole). Are you saying it will somehow remain an independent web rendering/execution platform given this past week?
EDIT: I know this may be too premature to ask but does it make sense to calculate a Acid Test result these days? I have no idea, hence the question.
awesomekling (who's on HN, shoutouts if you see this Andreas you're awesome!) used Acid 2 to help push the development of the SerenityOS browser in some coding streams.
There's still a lot of work to do on the CSS box model before the SerenityOS browser engine can render Acid1/Acid2 fully.
Then we have Acid3 which will require a lot more work on the JS engine and DOM API's. But it's all so much fun that it doesn't matter how much work it takes. :^)
Perhaps using something like OpenSSH's portability layer, or OPENSTEP's late-in-life Windows NT port?
It's mostly POSIX code so it's pretty portable.
Web Platform Tests are where it's at if you're developing a browser and want a test-suite.
A 2005-level browser is probably tractable. It gets much harder from there.
The time we pause, and re-architect and code existing constants from the ground up. To be grown up.
The elegance of this is superb.
You just never know.
It's super exciting to see how Rust will fare with building new iterations of existing tech.
It doesn't prevent leaks, but it does put you in the right frame of mind to not write them.
Currently the project fails to build with the following error:
> error[E0554]: `#![feature]` may not be used on the stable release channel
This might not be exactly due to Rust, but only a personal choice made by the project's authors. However, lack of stability does not bode well for the project's longevity and adoption rate.
We should be looking at "native web apps" as a stepping stone, a proof of concept for the architecture and design patterns of the web, but necessarily the platform itself. At the end of the day, it's just an XML document, stylesheet and escripting language running in a VM. There's no reason it has to use a browser engine and HTML.
Really cool to see someone trying to build a new web browser. It is certainly sad that the number of browser engines is shrinking rapidly.
Uncaught TypeError: msg is undefined
handle_response http://www.browser.engineering /signup.js:67
onerror http://www.browser.engineering/signup.js:49
submit http://www.browser.engineering/signup.js:48
SignupForm http://www.browser.engineering/signup.js:13
SignupForm http://www.browser.engineering/signup.js:13
<anonymous> http://www.browser.engineering/signup.js:82
EventListener.handleEvent* http://www.browser.engineering/signup.js:80When I browse the web, I know the browser puts me in control, and keeps applications contained. The only kind of app that I know will have comparable sandboxing is a PWA. Anything with a comparable amount of control will look like a web browser, and we already have the web.
If you want the world to change, you have to offer something better.
You speak of the web as an app platform - I'm not opposed to some platform like that existing (and they do exist, just look at your OS), I just think that we made a mistake when we turned the browser into one. Now we mix together hypertext and code and have so much weird legacy to maintain, not to mention the performance issues.
Sure if you have a nice application that is interactive, fine use a PWA, Electron or whatever you want but for showing plain text and iamges a subset of html and css is enough
Couple that with the idea I've been toying with for a while about a new html standard (html6?, core HTML?) that only accepts loading JS from a common repository of utility code (think useful stuff like autocomplete, partial page reload etc) and it could improve the web a lot if we got sites to use it.
it might if anybody would actually use it, but that seems unlikely if it doesn't have CSS or JS support. Chrome and Firefox are already really damn fast if you give them a simple site without much css or js. people just need to actually make sites like that.
This is the problem I see with initiatives like Gopher and Gemini.
The people causing the problems with the web are not the people who will listen to these initiatives.
They are banks, advertisers, FAANG, everyone who is fine making money off the standard Chrome-IE-Edge crowd and barely even care about Firefox support.
Both Gemini support and a sane subset of HTTP / HTML require the same level of dedication that I could bring, but no commercial site will. Well, to be blunt, minimal HTTP / HTML is a lot easier. I can keep my same hyper backend, Firefox client, Nginx for TLS termination, curl and libcurl and pycurl, lots of tools that will only work on HTTP.
Plus, minimal HTTP 1.1 is not that hard to implement, so I think they're mostly attacking the wrong part of the stack while also cutting out useful performance features like QUIC or pipelining or caching.
You want to write a custom stylesheet for every site you use?
I can understand this sentiment, and if there was a reliable way to implement it I would do it as well.
There are ‘readability’ plugins and services for browsers that attempt to provide this service for current sites. These days it’s a bit more complicated than just overriding a few styles to make a page ‘standardised’.
The plugins / services work for maybe 99% of pages I look at. Unfortunately I don’t know how to view the whole web through such a lens, without having to activate for each page.
It’s a requirement for a general purpose, modern browser, unfortunately, even one without a bunch of bells and whistles.
This is the case even for many municipal or government sites, to say nothing of business products/services/vendors. You can’t use the web as a private citizen for normal things like banking or civic participation without js.
If, hypothetically, browsers stopped offering powerful scripting capabilities, the app makers of the world would not suddenly say "I guess we'll make static webpages", they'll say "here's how to install our all-powerful unsandboxed application". Powerful scripting on the web means more applications running in safe sandboxes.
"...heavily inspired by Servo, sometimes taking code directly from it."
If you have ~5 tabs then tabs on the side is a waste of screen real estate. If you have 50 then on the top is unreadable.
A lot of people are on 13” laptop monitors, they’re not that wide.
rustup toolchain install nightly
rustup default nightly
Stylo is also a servo component that is ready for production.
I once took a stab at rewriting it in C99 using reference counting for memory management [2], so I recognised the screenshot in Kosmonaut immediately.
Unfortunately the article series stops before explaining inline layouts and I never got around to doing anything further with my implementation.
[1] https://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.h...
1) a replicable business model that doesn’t rely on advertising/surveillance revenue
2) search you can’t game with keywords or SEO
Until those are solved, we’re all trapped doing Google and Facebook‘s work for them. No amount of changes to the languages or browsers which parse them will have any noticeable effect on the majority of the web content or its users.
It's so sad. We're so trapped. Fortunately, Google (or any other) can't completely alienate a huge part of the web. So eventhough they control the browser, they don't control its content...
The way this will work will be similar to any project with the complexity and funds like the Linux Kernel Project: Recurring sponsorship funds in around $1M+ per month with 1,000 core developers and 10,000 external active developers at other companies also using this Rust browser.
This can also be turned into a Rust consultancy offering their services and expertise around security and Rust which also funds the development of this "Rust Browser" marketed as "more secure than Chrome".
That whole idea sounds almost unrealistic if starting from scratch, but it has worked for the Linux Kernel Project and Red Hat. It sounds more possible if it were spun out of an existing large company. But would it be open-source? I don't think so.
Here's hoping that never changes, and that they never add JS support. If a browser like this released a spec for which HTML and CSS it supported, I would gladly make my static sites compatible. There's no reason sites like Wikipedia couldn't do the same.
I used to look at Gopher (and more recently Gemini) as too stunted to be useful, but perhaps they are right to nip these things in the bud.
Indeed. Which also makes PDF's a dangerous file type to use.
You can't support one without supporting the other.
If you get your wish then the browser will remain largely unusable as a general-purpose browser.
I'm not sure who would benefit from this.