Kosmonaut: web browser from scratch in Rust

by adamnemecek • 6 years ago

721 446 6 years ago

Given the current Cold War state of the Browser Wars I very much support any attempt to come up with something new that focus on speed and privacy, lots of good luck!

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.

john_alan2• 6 years ago

Nah, it’s too nascent for ACID.

zamadatix• 6 years ago

A browser won't fully pass all of the Acid tests if it follows a few modern changes but it can be a good way of seeing general improvements take shape and show how close you're getting to the fiddly compliance bits. It obviously won't cover all of the newer stuff but it still takes quite a bit to cover everything in the tests.

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.

akling2• 6 years ago

Indeed, the Acid tests are in fact immensely useful for bringing up new HTML and CSS implementations!

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. :^)

missblit• 6 years ago

Acid3 is 12 years old. Of course a lot of it still applies today, but I suspect it's more flashy than useful for browser developers.

Web Platform Tests are where it's at if you're developing a browser and want a test-suite.

jefftk13• 6 years ago

Specifically: https://wpt.fyi

ori_b2• 6 years ago

Acid test is basically baby's first step. JavaScript api coverage, canvas, wasm, webgl, and all the other stuff is becoming table stakes, too.

A 2005-level browser is probably tractable. It gets much harder from there.

anderspitman• 6 years ago

Only a very limited subset of CSS is currently supported

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.

adamnemecek5• 6 years ago

Alternatively figure out a better css and do that.

amiga-workbench3• 6 years ago

I'm actually concerned that CSS or any other control over styling that is foisted upon the client is where the slippery slope begins. Once you add styling, the photoshop driven developers arrive and demand pixel perfection, then the never ending demands of more bloat and complexity follow.

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.

untog7• 6 years ago

That would all but guarantee the browser never gets used by a sizeable number of people.

rumanator3• 6 years ago

Here's hoping that never changes, and that they never add JS support.

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.

cmrdporcupine• 6 years ago

Then you could just use links or elinks.

amiga-workbench3• 6 years ago

I already build my personal sites to work on IE5 and up. If a 486 can do a competent job of drawing a page with some text and a few images. What possible gains do I get by piling more complexity on top?

shaunrussell• 6 years ago

I feel like there is room for a FAST browser with very limited CSS and no JS support. It could spur a minimalist information driven trend.

IshKebab• 6 years ago

JS is too useful to ditch entirely. I think it would be interesting to design a language that deterministically uses compute resources, and then limit web pages to a certain amount of them.

emptyparadise5• 6 years ago

In a better world, JS used to implement convenient web page features like rendering LaTeX or syntax highlighting would be implemented inside the web browser, while JS used to implement web apps would not exist and web apps would just be apps.

eitland5• 6 years ago

This is a good idea.

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.

niutech8• 6 years ago

This is exactly what AMP does: limits JS to 150KB in total and runs it in Web Workers.

notatoad• 6 years ago

It could spur a minimalist information driven trend.

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.

ReactiveJelly• 6 years ago

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.

tokamak-teapot2• 6 years ago

I’ll use it. I don’t want CSS or JS. If I can do my own styling and have it consistent across many sites then the web will be much more accessible.

sneak• 6 years ago

Most webpages, even simple ones that do not strictly need to be designed to require js, will entirely fail to render (blank page) without js. The situation has become a lot worse in the last 2 years or so.

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.

JoshTriplett3• 6 years ago

CSS and JS are not in opposition to "information driven". Javascript is not used merely for content-free flashy pages, and it isn't going away anytime soon. If and when it does, it'll be because something better replaced it, not because a million web developers woke up one morning and said "why don't we stop using most of the capabilities of modern browsers".

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.

smolder• 6 years ago

Browsers enable websites to be very user hostile the way it is now. Of course developers wont opt for static over dynamic, unless they suspect users might want that, which could happen in at least some niches.

clairity• 6 years ago

and fittingly, you could even call it phoenix[0], rising from the ashes of servo...

[0] https://en.wikipedia.org/wiki/Phoenix_web_browser

The_Colonel• 6 years ago

Dillo does that since 1999 yet few people are interested.

stonogo• 6 years ago

Dillo and Netsurf both exist. Few use them.

https://www.dillo.org

https://www.netsurf-browser.org

darkhorse13• 6 years ago

If it is purely for speed, then there is no need for a new browser. Simply disabling JS makes websites crazy fast. I run a documentation site for my framework. It is already pretty lean, but disabling JS makes it super fast, even though my server is cheap. Unfortunately, most modern websites display a blank page without JS, so what we really need is a change in developer attitude, not a new browser (again, assuming that you are only concerned about speed).

john_alan2• 6 years ago

Super exiting stuff. This is the renaissance of software.

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.

prohobo2• 6 years ago

I wonder how Rust will influence the outcome of this project? Will the Rust paradigm prevent memory leaks or somehow improve on the architecture of the big hitter browsers like Firefox and Chrome?

It's super exciting to see how Rust will fare with building new iterations of existing tech.

steveklabnik6• 6 years ago

Rust doesn’t prevent leaks, by the way, though it doesn’t tend to produce them.

Filligree• 6 years ago

Rust forces you to think about ownership.

It doesn't prevent leaks, but it does put you in the right frame of mind to not write them.

untog7• 6 years ago

One thing that interests me about using Rust for a project like this is modularity. The Rust toolchain makes it so easy to work with separate crates that it feels very natural to split your work at logical points. C++ doesn’t have that kind of baked in toolchain and just the act of downloading and compiling the Chromium code is a pretty intimidating prospect. If I could easily download and test, say, a CSS parsing module that could be really useful outside of regular browser contexts.

rumanator3• 6 years ago

I wonder how Rust will influence the outcome of this project?

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.

prohobo2• 6 years ago

From what I understand, that might just be a problem with the README. You might have to set your compiler to enable experimental feature flags (thus setup a different compilation channel).

jayflux• 6 years ago

One of the good things to come out of Servo was the modular design, which allows other projects to reuse components, such as the CSS parser and the HTML parser. I’m glad that has proven to be worthwhile. I just wonder if there’s enough people in the community to keep those crates up to date.

adamnemecek5• 6 years ago

This is partially thanks to rust and cargo.

timvisee• 6 years ago

Mozilla recently cut off 25% of their employees. I believe this will have a major effect on the Servo project, so we'll see where it goes.

rst• 6 years ago

By multiple reports, most of the Servo team was laid off (apparently sourced to former team members on twitter). See, e.g., https://www.zdnet.com/article/mozilla-lays-off-250-employees...

ChrisSD2• 6 years ago

One possible use case for even a minimal html/css renderer is for UI layouts outside of a browser. There's no need to bundle a JS engine to run some code if your team is already comfortable using another language.

krapp7• 6 years ago

For layouts outside of a browser, a specialized XML format other than HTML and CSS running in a VM would be more preferable. Everyone complains about how web tech is inadequate for UI design - it's a hack, not a solution.

ChrisSD2• 6 years ago

Sure but it's a hack that has a lot of popularity, even if only because of the web.

hombre_fatal• 6 years ago

Those people complain because they never built anything meaty on other stacks like Android or iOS which have all sorts of warts and offer nothing as good as Elm or React much less an open source solution.

niutech8• 6 years ago

Check out these projects: https://github.com/litehtml/litehtml, https://github.com/yue/yue, https://github.com/cztomsik/graffiti

brundolf11• 6 years ago

I just had an interesting train of thought. People have assumed for some time now that writing a browser engine from scratch is intractable because of how large and complex web standards have become.

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.

amelius• 6 years ago

You still need a fallback solution for cases where the website doesn't work with your version of the standard. Otherwise, users would be very disappointed, and they would switch browsers very quickly.

I like the idea, but the migration path needs some serious thinking.

brundolf11• 6 years ago

The idea is to make a "best effort" solution. Once it's good enough, it could be tolerable for regular users. The next step would be to offer something new, that Chrome doesn't offer, that's compelling enough for the average person to stick with it despite the occasional hiccup. I don't know what that would be. It could be a genuine privacy guarantee (due to the lack of profit-motive), it could be less bloat and therefore longer battery life on their devices. Or it could be a UX-level rethinking of how a web browser is structured.

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.

svl• 6 years ago

The complexity in supporting CSS does not come (primarily) from its individual properties, no matter how obscure. It comes from things like margin collapse, from correctly determining the stacking context, and about a gazillion other things like that.

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.

brundolf11• 6 years ago

These aren't things where you can just scan the CSS of the top websites to find out if they're being used.

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.

Someone• 6 years ago

“due to the insane effort by the WHATWG standards to truly describe what is actually happening in browsers”

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.

mrec• 6 years ago

My favourite example of the thousand-yard-stare horror of web specs is Manish's "Font-size: An Unexpectedly Complex CSS Property". It's awful and hilarious and just keeps getting worse and worse and worse.

https://manishearth.github.io/blog/2017/08/10/font-size-an-u...

ako• 6 years ago

Maybe it's time we create a new html rendering engine by training a ML model using w3c specs and tests as input.

rumanator3• 6 years ago

But what if you didn't have to implement all of them?

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.

brundolf11• 6 years ago

Usually when a feature - especially a CSS feature - is missing, a site degrades gracefully. This varies between features of course, which could be another factor in prioritizing them: how dramatically will the absence of this break something?

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.

frereubu2• 6 years ago

Initially I imagine anyone who downloaded this browser would know exactly what they were getting into. I'd download something like this if it was noticeably faster and leaner than other browsers, as long as I could do some kind of quick switch to another, like I do with bangs for Google on Duck Duck Go.

mponw• 6 years ago

I had a similar thought: Why not build a browser-generator? Some nice presets and checkboxes for options and a single shiny "Build" button. This can't be too difficult, am I right? It would give users the explicit responsibility for broken pieces and also some nice performance gains.

agumonkey2• 6 years ago

I'd pay money to see how would a bunch of mainstream users would react if they only had https://lite.cnn.com/en or https://text.npr.org/ and similar variant for online services (granted a few pics allowed for shopping)

ps: 10$ more on a 'this lowered my medical bills' outcome

brundolf11• 6 years ago

I enjoy the lightweight web too, but I want to stress that that's not what I'm advocating for here. You can't simply expect the population at large (or perhaps more importantly, the corporate community at large) to seismically shift the way they're doing things for the sake of web idealism. You have to meet them where they are. What I'm talking about is finding a pragmatic way to do that.

eitland5• 6 years ago

I've been wondering for a while if we could create an extremely simplified rendering engine that would only accept modern markup and css:

- 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

rubber_duck• 6 years ago

A better use case for this engine would be Electron replacement.

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)

csande17• 6 years ago

You may be interested in a project that's doing almost exactly that: a new content type that sits alongside the "classic" web, with a heavy focus on performance and only JavaScript from a vetted repository allowed.

https://amp.dev/

jancsika• 6 years ago

This could be coupled with a search engine that indexes the pages which such a browser has been tested to display correctly.

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...

Taek3• 6 years ago

But what if you didn't have to implement all of them?

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.

als0• 6 years ago

global identity (pubkey based)

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.

kristiandupont• 6 years ago

The way Firefox initially solved this was with a user-facing version of the Strangler pattern: IE Tab. You could simply tell FF that a given URL needed to be rendered by IE and that would be the case inside your otherwise strictly FF browser. It worked perfectly. That pattern could be reused in such a scenario I guess.

jefftk13• 6 years ago

Some ideas: privacy, anonymity, no tracking, no DRM, global identity (pubkey based).

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.

trollied• 6 years ago

It's a shame that the web/browsers have grown up to be so forgiving of shitty markup that isn't valid.

The experience would be much better for the user if it was all strict, as I suspect things would be faster.

ivanche• 6 years ago

Congrats, you just reinvented XHTML :)

krapp7• 6 years ago

Most HTML is generated by frameworks now, isn't it? Is there a lot of non-matching HTML in the wild anymore?

goto1112• 6 years ago

How would it be better for the user if half the web sites didn't work?

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.

hinkley3• 6 years ago

Mosaic tried to be strict. Netscape was more SGML-like and so it was a slow slide as people said, “well it works in Netscape, so it must be a bug”.

The early authoring tools also generated pure garbage for markup. So if you weren’t forgiving, you lost users.

Pandering works.

themacguffinman• 6 years ago

Even if most websites only relies on 50% of the web spec out there, it's likely that many of them rely on a slightly different 50%. That would mean the "common" area needed for a good average experience is significantly larger than 50%.

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.

kelnos8• 6 years ago

I'd bet that 90% of the web only uses 50% of the web standards out there

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.

millstone2• 6 years ago

I think there's a great case for a browser which defaults to Reader Mode. Reader Mode is always a better experience when it works. And then build up from there.

jlokier3• 6 years ago

I'd bet that 90% of the web only uses 50% of the web standards out there.

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 :-)

tekknik• 6 years ago

And here, dear reader, you have witnessed the birth of new Internet Explorer. Half the standards of a proper web browser with twice the opinions!

pkphilip2• 6 years ago

A browser engine which supports a subset of the features of Chrome, Firefox etc and can be used as a lightweight and fast alternative to Nodejs/Electron for cross-platform desktop app development could be a really useful product.

ori_b2• 6 years ago

Since you are ditching compatibility here, you can also ditch the browser engine.

est313• 6 years ago

You only ditch compatibility for existing content. You still keep some level of compatibility with developer knowledge and teaching material. Most websites and electron apps don't need a WebSQL implementation, yet all electron apps ship with one, bloating the downloads for all users.

kelnos8• 6 years ago

Isn't part of the draw of Electron that you can essentially stuff your (presumably already existing) web app in a box that runs as a standalone app[0]? If that's the case, removing compatibility would mean losing most of the draw.

[0] Yes, I know there's more to it than that.

pkphilip2• 6 years ago

Some level of compatibility will be good to have so that a lot of the Node modules can be used as is. However a lot of old standards etc can be thrown out.

niutech8• 6 years ago

There is already a lot of lightweight alternatives for Electron: electrino, neutralino, Quark, Deskgap, WebWindow, litehtml, tomsik.cz/graffiti, yue, nodegui, etc. No need for yet another one.

john3663663• 6 years ago

Given the recent layoffs at Mozilla the future of Rust seems bleak

Shared4043• 6 years ago

Both MS and AWS are interested in Rust. I doubt it's going anywhere.

john3663663• 6 years ago

Yes, as users. Not as someone willing to be a torch bearer of language designer.

adamnemecek5• 6 years ago

It really doesn't.

john3663663• 6 years ago

Why?

weinzierl• 6 years ago

Lots of good comments with good points but none about security so far. There is no lack of alternative browsers, really. Personally, I find projects that take a new approach highly interesting. More interesting than those that that clone what Chrome and Firefox do. I used surf, uzbl and luakit extensively, but what prevents me from adopting them as daily drivers is always the nagging concerns about security.

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.

est313• 6 years ago

A pure Rust browser is immensely more secure than any browser written in C++, at least against memory safety bugs. There is still the source of logic bugs, stuff like the same origin policy, but the worst that can happen is an XSS attack instead of RCE or similar. The browser would be ideal to access the 99% of websites you don't log in to (provided that the browser can actually render them correctly), and eliminate the main danger from them. For websites you log in to, you can still use Chrome.

jdashg• 6 years ago

You overestimate the number of issues that Rust would solve, versus the actual sec issues browsers have.

c-smile3• 6 years ago

but none about security so far.

97% of users don't care about security issues that Rust can solve in principle.

brundolf11• 6 years ago

I'd imagine the great majority of security work happens in the JS engine, because that's what executes foreign, turing-complete code from every site you visit (natively via JIT, even). So one option would be to simply use V8, and only build the other subsystems from scratch. Performant (and complete) JS interpretation is probably going to be the hardest thing to implement anyway, before you even get to the security concerns.

teejmya• 6 years ago

    Let's face it the amount of work and money that has been put into Chrome's security is amazing.

It comes down to knowing your attack surface. If you’re trying to secure your data from non-Google entities, then Chrome is probably fine.

Taek3• 6 years ago

Wouldn't it be better to have standards that weren't so complex or more readily lent themselves to security?

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.

badsectoracula• 6 years ago

I do not think this is really much of a concern in practice. Nobody would bother to attack a browser that isn't popular (unless it is used by someone who is a target themselves, but the attack wouldn't be for the browser but for the target and the chance of others being affected will be very very low) and by the time the browser becomes popular it will also have attracted a developer base and pairs of eyes large enough to have those bugs fixed.

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.

kelnos8• 6 years ago

Right, I feel like any new desktop browser that is aiming for wide adoption needs to be (for example) multi-process and privilege-separated from the start. Rust certainly makes some bugs impossible that this sort of sandboxing prevents, but not everything.

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.

baby4• 6 years ago

If you prioritize tabs on the side (instead of up there) I will come and work for free on your project.

pikelet• 6 years ago

Why does it have to be one or the other?

baby4• 6 years ago

because one is objectively better than the other

DonCopal• 6 years ago

https://addons.opera.com/en/extensions/details/vertical-tabs...

catdawg• 6 years ago

Could something like this be used as the renderer for desktop applications? Instead of running a full fledged browser like electron, you basically just write all the logic in rust, and render the UI with css+html.

rapsey• 6 years ago

Depends on how dependent it is on the javascript engine. Servo unfortunately was inseperable from js.

throwaway8943452• 6 years ago

Can you give more information (link?) about why Servo was inseparable from JS?

untog7• 6 years ago

In theory. The Sciter engine is not far off that, though it uses its own scripting language:

https://sciter.com/

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.

UnnoTed• 6 years ago

The logic can be written in Rust with [1], it's exactly like he wants: rust[2] + css + html.

[1] https://github.com/sciter-sdk/rust-sciter [2]: https://github.com/sciter-sdk/rust-sciter/blob/master/exampl...

c-smile3• 6 years ago

Why "in theory"? Here are real life applications: https://sciter.com/#customers

hiccuphippo2• 6 years ago

Maybe Azul[0]? It uses the Mozilla web renderer but instead of HTML you write DOM in a react-style way.

[0] https://azul.rs/

guerrilla2• 6 years ago

Isn't that what GNOME is doing but in C (and whatever Gtk+ binds to)? [1]

[1]. https://wiki.gnome.org/Projects/GnomeShell/Development

nikki93• 6 years ago

Some UI rendering engines for games do something like this, eg. https://coherent-labs.com -- talk by one of the devs of that at https://www.youtube.com/watch?v=yy8jQgmhbAU

pavpanchekha2• 6 years ago

If you're interested in writing a browser from scratch, you may be interested in the book I'm writing on the topic: http://www.browser.engineering/

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.

jazzyjackson3• 6 years ago

Looks really interesting, I tried to sign up but got a 'something went wrong' with this stack trace in the console

  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:80

pavpanchekha2• 6 years ago

Huh, sorry about that. What browser are you using? Mobile or desktop? If you email me (author@browser.engineering) I can manually add you.

jazzyjackson3• 6 years ago

I'm writing my web publishing platform to work on HTML4 and CSS2 standard so I can brag about how it's still performant on Mac OS9.

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?

jfaat• 6 years ago

Looks like ionic supports desktop apps now: https://ionicframework.com/docs/deployment/desktop-app

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.

neurostimulant2• 6 years ago

Isn't Ionic using Cordova Uber the hood? Cordova uses native webview.

lukevp• 6 years ago

Ionic uses capacitor for native deployment. Capacitor is a thin cli wrapper and an api abstraction around each platform. In the desktop case, it’s a wrapper around Electron. For mobile, it’s Cordova.

c-smile3• 6 years ago

to find a no frills rendering engine that I could package up like an Electron

Here it is: Sciter (https://sciter.com) and Sciter.Quark (https://quark.sciter.com) in particular.

leeoniya• 6 years ago

not quite the same but certainly addresses the Electron bloat criticisms:

https://neutralino.js.org/

jazzyjackson3• 6 years ago

definitely going to try this out, thank you!

niutech8• 6 years ago

Have a look at NetSurf or litehtml (https://github.com/litehtml/litehtml)

guerrilla2• 6 years ago

Building seems to require nightly, not just beta due to use of the `or_patterns` feature.

    rustup toolchain install nightly
    rustup default nightly

All tests passed for me. Check out main.rs to get an idea of where it's at. Not as fun without text though :)

tmd833• 6 years ago

These are perhaps since the whole complexity of css and dom and box models etc. is beyond me specially how the complexity actually multiplies. But I have always found the complexity of modern web not just unsustainable or risky but frustratingly wasteful.

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.

dmitryminkovsky14• 6 years ago

The complexity of the web is not just unsustainable—as of this past week and the demise of Firefox it has officially become "unsustained".

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.

dblohm7• 6 years ago

“Demise” is nothing less than hyperbole.

dmitryminkovsky14• 6 years ago

Does anyone think it would make sense to create a drastically simpler set of web standards, so that making web browsers would become much simpler?

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?

jonny_eh• 6 years ago

Just don’t implement JS. Simpler!

ghayes3• 6 years ago

I mean, you might be able to get away with implementing a WASM VM and a small subset of JavaScript APIs, which might be significantly simpler than implementing all of JavaScript itself.

kortilla• 6 years ago

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.

A huge issue. Nobody is going to use a browser that doesn’t work with 99% of websites.

dmitryminkovsky14• 6 years ago

Right, it's a huge issue. Some really cool exclusive content would have to be found on this Web.

But, what's the alternative? Giving up the Web and giving it away to Google?

ghayes3• 6 years ago

What if you had a legacy or emulation mode where it ran Chromium or WebKit for non-compliant pages?

Touche• 6 years ago

Isn't epub kind of this?

dmitryminkovsky14• 6 years ago

I think so? But I can't decide whether this hypothetical simpler web should strictly be document-oriented. I don't think the issue is that the web is now half application, half document oriented. It can still be both?

Taek3• 6 years ago

The challenge with standards is feature creep. Example: amd64

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.

dvt2• 6 years ago

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.

dmitryminkovsky14• 6 years ago

I think feature creep is the #2 issue after adoption, and I think the solution is to adhere to a strong set of priorities, namely: simplicity.

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.

aleksjess2• 6 years ago

That's sadly the thing - you can't. Not until you have community-owned companies providing services being directly competing against tech giants.

Which might not happen, ever. Sadly.

hiccuphippo2• 6 years ago

When I read about AMP for the first time I thought that's what it was going to be.

om23• 6 years ago

The limiting factor on making a new browser isn’t specs, it’s existing websites. Very few people want to use a browser that doesn’t work with existing websites, which actually use all the existing complexity.

kybernetikos3• 6 years ago

This is true for my daily website driver, however there are a lot of situations we might want to use browsers or browser like things where this doesn't have to be the case.

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.

klyrs2• 6 years ago

old styling mechanisms would be removed

But... my beloved <marquee>!

dmitryminkovsky14• 6 years ago

No joke I was visualizing a marquee scrolling by as I was typing those words.

zzo38computer11• 6 years ago

I don't really like <marquee>, and believe it should be user configuration to just display static or to manually scroll it; the user should also control the blink rate for the <blink> command too (including zero if they do not want it to blink)

tmd833• 6 years ago

I talked about something like this in my comment. One solution I was thinking is that even if it's a parallel engine don't you still save on resources if some of the most popular sites use the simpler/faster layout because the memory/cpu overhead is significantly lighter on the new layout? And the bigger/popular website has a motivation to update if it's actually faster and more responsive.

hinkley3• 6 years ago

But you’d have to have both in one browser, and have it be popular, before something like that would catch on.

fspeech2• 6 years ago

I can imagine this being used for a desktop app with limited web access: pages using only html and css will be correctly displayed; pages requiring js would be degraded. This way you can safely extend desktop app with access to web resources.

hinkley3• 6 years ago

The last browser I worked on was xhtml-basic, meant for cellphones.

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.

dependenttypes2• 6 years ago

HTML would have to be written correctly (eg. balanced tags)

This is an opinion regarding style. Adding support for unbalanced tags is one of the easiest things.

dmitryminkovsky14• 6 years ago

I'm speaking strictly from the perspective of complexity. It's significantly more difficult to parse unbalanced tags.

qwerty4561274• 6 years ago

Does anyone think it would make sense to create a drastically simpler set of web standards, so that making web browsers would become much simpler?

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.

SyneRyder2• 6 years ago

And those Gopher browsers can be really tiny. I think both Jaruzel's Gopher Browser For Windows [1] and Phetch [2] are under a megabyte.

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...

[2] https://github.com/xvxx/phetch

[3] http://links.twibright.com/

hliyan2• 6 years ago

Gopher would have been great with a facelift.

Another thought: what if browsers develop the ability to render markdown natively (in addition to HTML)?

graiz3• 6 years ago

I had a very similar idea and started to prototype a layout engine, tokenizer and parser. I was able to render things about 1000x faster in the basic case (rendering styled text, boxes and images). The problem I can't crack is mass adoption. If you have ideas on that, call me. :)

kybernetikos3• 6 years ago

What level of capability did you get to? Is it just for consumption of document like things, or could it be used for applications too?

qppo2• 6 years ago

I'd backdoor it into a app framework. Don't have to call it native, just a framework for making apps that happens to have a way to serve them to a user over TCP.

mvn9• 6 years ago

There is no need to aim for mass adoption. Make it a standard for whoever wants a simple html environment. It could be situated between gopher and the full html spec.

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.

htmlproplus• 6 years ago

I believe this would open the playing field for many people to create browsers

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.

Lerc• 6 years ago

I think the adoption issue could be managed by the fact that Current browsers are sufficiently monolithic that you could implement a version of the simple standard as a WASM host module. It makes the huge things a little more huge but the light weight things more light weight.

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.

goto1112• 6 years ago

Ask web developers if they would like to loose flexbox and grid again.

The thing about balancing tags is a red herring. The HTML parsing logic is not the complex and slow part in a web browser.

dmitryminkovsky14• 6 years ago

I'm thinking the opposite: lose floats. I definitely want to keep flex and grid.

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.

Razengan• 6 years ago

Being able to develop web pages with something like SwiftUI would be heaven.

nixpulvis• 6 years ago

Remove JS, reclaim the back button!

wfdctrl• 6 years ago

Yes! I like the original idea of HTML, where the client chooses the styling not the website. That way the web cloud be completely consistent, just pure information.

alicemaz• 6 years ago

definitely worth doing. would be a massive undertaking. I'm not webdev enough to comment intelligently on _how_ to do it, but I think the general _what_ to do is something like... a system that is simple and internally coherent, designed specifically to a) court devs to build on it instead, and b) enable all the optimizations that have eluded browser vendors so far because the existing standards are so absurdly complicated. "parallel layout engine" and "a tab doesn't use multiple gigs of ram" are good for starters

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

kodablah• 6 years ago

This is something that I had envisioned [0][1]. I haven't really worked on it lately, but one thing quickly became apparent: were it not for the Google-ification of AMP (e.g. how it's used, tags for ads, etc) they had the right idea. I think you can go a long way with a backwards compatible subset of HTML and CSS only taking the latest/best of both, disallowing JS, and having an explicit goal of ease of implementation.

0 - https://github.com/cretz/software-ideas/issues/92

1 - https://github.com/cretz/narrow

elcritch• 6 years ago

Exactly, just a subset of only the modern elements of HTML & CSS with perhaps a simplified layout could go a long way. For example, if you're building a electron type application you don't need the whole gamut of HTML/CSS, but only a fast well supported subset, especially a subset that works well on GPU's. I've wondered if Servo could be useful for something like that.

goto1112• 6 years ago

I note you want to support table markup in HTML but you don't want to support table layout in CSS. How are tables supposed to be rendered then?

pjc50• 6 years ago

I'm reminded of WAP: https://www.wapforum.org/what/technical_1_0.htm (no, not the Cardi B version)

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.

Brakenshire• 6 years ago

The obvious target is apps, develop a simplified layout/styling model for properties which can be scoped within a component, and build a layout engine which can calculate the layout within those components independently, and then you could radically improve the performance of web UI.

ufmace• 6 years ago

It seems sort of cool, but I don't see how anyone would ever agree on what should and shouldn't be included in the "simplified" standards. Instead, you'd have Andy's custom browser implementing 15% of the web, and also Beth's custom browser that implemented a different 15% and so on. Then Chris tries to build a website. If he uses only the stuff that Andy's browser supports, then it'll work there, but probably not in anybody else's custom browser, so what's the point? Just build to the real full web and let everyone use conventional full browsers. Each custom browser implementer would then be incentivized to implement more and more stuff to try and gain a bit more adoption. They'd either just give up, or try to match the real browsers, fail, and then give up.

gix122• 6 years ago

It would be lovely if the whole firefox's html/css/js engine was compilable into webassembly. A new browser could implement webassembly compiler and use firefox rendering engine as a fallback for when their novel rendering engine doesn't support some feature on a website.

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.

1vuio0pswjnm7• 6 years ago

Many times I have suggested this idea on HN. Always gets shot down. Perhaps the problem is that such a move toward simplicity is perceieved as benefitting users more than web developers.

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.

allover• 6 years ago

The problem is that such a browser wouldn't be any use to users in the short-term, because most of the web simply wouldn't "work" in it.

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.

specialist• 6 years ago

Agree and would go further.

#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.

rini172• 6 years ago

"Just render..." Clearly you have never looked under Facebook's or Twitter's hood.

jefftk13• 6 years ago

Twitter, Reddit, and most other popular websites already look terrible.

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.

johannes1234321• 6 years ago

If one does a simple version in my opinion it shouldn't move fast, but be extremely reluctant to move in order to enable creating archivable documents.

juststeve• 6 years ago

Yep, super basic and reliable for decades.

xook• 6 years ago

Something like Gemini is what comes to mind https://gemini.circumlunar.space/

" [...] which explores the space inbetween gopher and the web, striving to address (perceived) limitations of one while avoiding the (undeniable) pitfalls of the other."

forgotmyp772• 6 years ago

I'm doing it the other way, by testing with all browsers and only using subset of HTML which works in all.

zzo38computer11• 6 years ago

Did you test with Lynx?

zzo38computer11• 6 years ago

I had another idea. It is its own file format (independent of the transport protocol; HTTP works just as well, or you could use DVDs just as well, too), which is a Hamster archive containing several lumps. There is its own document format, which lacks support for styles and a lot of other stuff, but does include some commands (e.g. footnotes, data tables, emphasis, headings, hyperlinks, lists, fix-pitch), and there may also be lumps containing executable code (which is optional, as are the document lumps). The executable code is sandboxed and can do no I/O at all (including random numbers and date/time) without an extension. There are standard extensions, and the user is required to be able to configure the extensions, to enable/disable them, substitute their own implementation, or add a proxy to them. If there is network communications, a PROTOCOL.DOC lump (which is meant to describe the protocol in use, but may be blank) is mandatory, in order that the user can reimplement the protocol by themself. Extensions must be open source and fully documented (in order to be listed in the main documentation, and listed in the installation menu of the main distribution). (Some standard extensions would include the document view, a command-line interface, a terminal-based text interface, date/time, random number generation, network communication, and files.) Documents may also be stand-alone. Extensions are identified by a sequence of UUIDs.

Impossible• 6 years ago

This would be great. I also think there is the issue of HTTP being a good protocol and the web being a good distribution platform, and as a result browsers have to be complex because they are everything to everyone. It'd be cool to have a really optimized browser/game engine with WebGPU, WebXR, Gamepad API, audio and Wasm, and no or minimal HTML support as an application platform, for example. Or a browser that has a unified fixed UI for streaming video. I understand these aren't perfect examples and can be nitpicked and might not work in practice, but I strongly agree with this idea in a general sense.

userbinator3• 6 years ago

a drastically simpler set of web standards, so that making web browsers would become much simpler

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.

p4bl0• 6 years ago

What you say makes me think of the gemini project :).

https://gemini.circumlunar.space/

Aeolun3• 6 years ago

There is no chance in hell that you’d get the general web to move back to floating divs to manage layout.

kybernetikos3• 6 years ago

That's the key problem - everyone who thinks the web is broken thinks it's broken in different ways.

dathinab3• 6 years ago

ASCII has been

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.

inopinatus4• 6 years ago

Bring back DSSSL. After all, what language has a better ratio of fundamental simplicity to expressive power than Scheme? Much of the emergent complexity of styles is due to CSS selectors being intentionally non-Turing-complete.

om23• 6 years ago

HTML4 and CSS2 are drastically underspecified. Even for sites where that's a sufficient feature set, you need to reverse-engineer browsers to figure out error handling and such.

efojs• 6 years ago

Maybe something like Pipfile.lock for a site and browser knows what standards to use?

bzbarsky• 6 years ago

Unfortunately, HTML4 and CSS2 are severely underspecified, so actually implementing them interoperably without reverse-engineering is impossible. Oh, and some places where they _are_ clearly specified that specification is more or less broken. For example, implementing comment parsing per the letter of the HTML4 spec is extremely not-web-compatible, and I doubt that either Dillo or NetSurf do it...

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.

mikorym• 6 years ago

Wouldn't the first stable release of HTML count as "a drastically simpler set of web standards" together with the fact that any browser should support it?

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.

goto1112• 6 years ago

HTML4 and CSS2

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.

kettlecorn• 6 years ago

I think it's a worthwhile endevour. But the key is to look at how systems like the web stagnate and to design a system that can avoid the same fate.

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.

tamrix• 6 years ago

The Web will fork at some point in the near future.

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.

krapp7• 6 years ago

But there's no reason for that to happen.

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.

yoz-y2• 6 years ago

Who will make this push?

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?

limomium• 6 years ago

More likely, an emergence of curated and policed search/indexes [sic] of sites voluntarily subscribing to a particular web philosophy.

Simultaneously, blacklists of domains and browser extensions to scrub viewed pages of any references to sites not subscribing to particular philosophies.

jasonhansel2• 6 years ago

I feel like AMP was a missed opportunity to create something like this. Unfortunately, Google was more focused on profitability...

Maybe we should go back to Gopher? (I almost mean this seriously--it was much more lightweight.)

jefftk13• 6 years ago

If Google had not focused on making it possible for publishers to earn money from their AMP pages, why would any of them have been willing to put in the effort to rewrite their pages?

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)

jlg23• 6 years ago

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.

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".

jefftk13• 6 years ago

No need for new standards, you just implement recent standards properly and don't pay attention to the real world

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.

ForHackernews• 6 years ago

If you're not already aware, check out the Gemini protocol: https://news.ycombinator.com/item?id=23730408

tingletech• 6 years ago

Like XHTML 4?

MaxBarraclough• 6 years ago

Such a simpler web spec would be relatively fast moving, not focused on backwards compatibility, but instead on simplicity of implementation.

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.

[0] https://news.ycombinator.com/item?id=23165029

blodorn• 6 years ago

xhtml?

toper-centage• 6 years ago

I think you've just described Google's AMP

jbritton• 6 years ago

I sometimes wonder if the browser client should just be a video player. It wouldn’t be suitable for everything.

Or possibly a display renderer of some sort, like postscript.

gwbas1c• 6 years ago

IMO, it makes more sense to allow a web site to specify its rendering engine in one of the HTTP response headers. The rendering engine would be WASM, and the actual site could be HTML or whatever.

As long as the rendering engines are distributed via CDNs, it would be extremely fast.

y04nn• 6 years ago

A new web stack would be awesome. Using latest technologies available and suppressing backward compatibility. Replacing everything from HTTP to HTML, CSS and JavaScript.

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.

kelnos8• 6 years ago

not focused on backwards compatibility

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.

kadoban• 6 years ago

Balanced tags aren't really important, but _some_ sort of format that is understandaple and enforced is a good idea. The whole browsers guessing what the page actually meant thing isn't a great game to play.

dmitryminkovsky14• 6 years ago

Otherwise you're just building a toy for geeks to play with,

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.

dredmorbius4• 6 years ago

"Worse is better" suggests otherwise. HTML conquered numerous existing markup languages (notably SGML). Though it had relatively little content compatability to worry about in 1990.

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.

m00x• 6 years ago

No it doesn't.

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.

zzo38computer11• 6 years ago

Users want more features in their web apps, and the standards/web browsers make it possible.

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).

dmitryminkovsky14• 6 years ago

I didn't mean to suggest we should revert to old days. My vision would be a significant paring down of modern standards, updating relatively quickly even.

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.

dahfizz2• 6 years ago

Users want more features in their web apps

Do they? Or do web developers just chase after new, shiny things?

II2II• 6 years ago

Of course adoption would be a big issue, but that's always a big issue.

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.

jeeeeb• 6 years ago

I cannot imagine it will ever happen but I'd like to see the spec precisely defined in terms of core "axiomatic" functionality (JS, layout engine, core CSS rules), and peripheral functionality built on the core functionality.

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.

ummonk• 6 years ago

Would this include an implementation of JavaScript or alternative to it? Or just be a standard for static sites? What about media playback, rtc, etc.?

collinmanderson• 6 years ago

"create a drastically simpler set of web standards, so that making web browsers would become much simpler"

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.

bradgessler• 6 years ago

I’d love to have an Internet that’s a bunch of markdown files that link to a bunch of other markdown files (or a format that simple). No JavaScript, minimal CSS, and support for various image types.

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.

arendtio2• 6 years ago

Adoption wouldn't be a problem, if you use just a subset of the current standards.

jlokier3• 6 years ago

There are already numerous niche browsers implementing a subset of the current standards.

They don't achieve adoption.

forgotmypw17• 6 years ago

i'm approaching this issue from the other end: using a subset of html (and careful progressive enhancement) to build a site which works in every browser since the earliest days of the web.

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.

kryptiskt• 6 years ago

I was thinking about breaking it down to just make a fun sandbox VM with some APIs for network, local storage and interacting with the user. No document format or anything, you get a screen to draw on and get events. And then I thought: "hmmm, everybody's going to be disappointed that the VM isn't for their pet language", so I came up with the idea of just using QEMU. Literally just give every site a bare machine it can load any image on. Make a virtual IO device for the system services (like exposing the path and query part of the URL, clipboard and linking to other machines). UI, storage and network get normal VirtIO devices.

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".

goto1112• 6 years ago

Does anyone think it would make sense to create a drastically simpler set of web standards, so that making web browsers would become much simpler?

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!

dukoid2• 6 years ago

I wonder if it would be possible to distill the "rendering essence" of HTML+CSS, i.e. have a pre-processor that transforms a lot of redundancies / complexities out to just a hierarchy of spans+divs with style attributes.

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?

goto1112• 6 years ago

This was the idea behind XSL (and DSSSL before that). You transform semantic markup into a pure presentation format. By moving the transformation to the server you can have all the complexity of selectors, rules, inheritance, cascade etc resolved on the server and have the browser just receive low-level rendering instructions.

Of course you can't have any form of dynamic HTML and accessibility would go out the windows.

niutech8• 6 years ago

This subset of web standards was proposed long ago: WML (WAP Markup Language). Do you remember WAP browsers?

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)

Chris2048• 6 years ago

The movers-and-shakers of web-tech are the large corporate (esp the two that control the browsers) and what are their incentives to simplify web tech, thereby lowering the bar for competitors.

ninjapenguin54• 6 years ago

Might be insightful to look at the history of xhtml.

tl;dr an attempt was made and failed. Turns out there's not enough incentive for websites to convert to your stricter html replacement.

scalatronn• 6 years ago

funny fact, that's how Google started experimenting with Flutter

fspeech2• 6 years ago

What does it take to hook up something like this with nodejs? This just renders the dom while you manipulate dom with js. Would this be a lot smaller and more customizable than electron?

haecceity• 6 years ago

I think HN wants something like this to succeed and compete with firefox and chrome but I can't help but think that's never going to happen.

krapp7• 6 years ago

HN wants the rest of the world to be as angry and frustrated at the modern web as they are, but the rest of the world, for the most part does not care.

lordnaikon• 6 years ago

The main problem is the mess that is called html/css. You can't "just" build a simple browser with limited resources anymore. And by limited i mean thousands of man-years of work backed by a multi million organization. I don't know if it is a calculated taktic from google to rapidly expanding and driving the web forward (i still hope the intention – at least at the beginning – was in good faith) so that nobody starting today from scratch could ever catch up. But i guess everybody that started to build a simple hobby web browser knows how unachievable this task is. If we ever want competition in this field again and don't want to handover the web to google, we need to start from scratch or at least start to massively deprecate stuff. And by the grave of Alan Turing start by making a website fail to render if the html is not correct.

wiz21c• 6 years ago

> And by limited i mean thousands of man-years of work backed by a multi million organization.

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...

rvz• 6 years ago

That's the harsh fact as it stands. No amount of GitHub stars, blog-posts, retweets or news coverage would help it further in its goal. I mean, the author is the only commiter, which is already a high risk of failure.

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.

jasonhansel2• 6 years ago

Question: what's the advantage of Kosmonaut over just forking Servo and continuing to maintain it?

zucker42• 6 years ago

It looks like it's an independent toy project right now that happens to use some pieces of Servo. So probably no particular advantage as of now.

rocky1138• 6 years ago

How does this compare to Dillo?

vikiomega92• 6 years ago

As a tangent, is there a Firefox focus equivalent for the desktop?

Communitivity• 6 years ago

Is this related to Servo,and if so how? Servo is the Mozilla team's creation of a browser engine in Rust The team recently got laid off by Mozilla but the development is apparently continuing as an Open Source project.

adamnemecek5• 6 years ago

It's not related.

ezekiel682• 6 years ago

In a strict sense of the word "related", yes. From the bottom of the post (README.md):

"...heavily inspired by Servo, sometimes taking code directly from it."

fay59• 6 years ago

Hacker News: implementing an incomplete subset of Web standards to focus on things that matter to everyone, like performance and privacy, is a great idea. Also Hacker News: fuck Safari.

rmdashrfstar• 6 years ago

I, for one, love Safari! I will use Safari on MacOS and Firefox on Linux, but only Chrome for frontend development and testing...

kelnos8• 6 years ago

Safari isn't that useful for people not using a Mac or iPhone/iPad, which is most people.

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.

kabacha• 6 years ago

How is safari focusing on performance and privacy? AFAIK its the worst performing browser and easiest one to fingerprint.

andai2• 6 years ago

Tangential to performance, but last I used it (2018ish) Safari had by far the best power efficiency, which is important when running on battery power (iOS and MacBooks are Apple's most popular devices). It was like a 2-3X difference, doubling the battery life. I thought that was really interesting, how much they optimized for that, and how Chrome seemingly did not at all.

millstone2• 6 years ago

Safari is very fast, not sure where you got the idea that it's slow?

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-...

avasthe• 6 years ago

Also Hacker News: fuck Safari.

We are all talking about something between Lynx and Safari.

zelphirkalt• 6 years ago

Although afaik Safari is the only one which has TCO for JavaScript? (Correct me if I am wrong!) So while I do not like Safari, it seems to have done that right.

Vinnl• 6 years ago

These kinds of comments always puzzle me. They basically come down to: "Some people on this website have one opinion, and other people on this website have another. People on this website are inconsistent."

BoDlulu• 6 years ago

Sometimes it's the same people - yes, people have contradictions, what a surprise!

AbuAssar• 6 years ago

Use stylo for css rendering.

Stylo is also a servo component that is ready for production.

the_other• 6 years ago

I’m sure this is fun and all, but the only things which will fix the web are:

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.

ezekiel682• 6 years ago

To those pointing out that dillo, netsurf, and phoenix didn't get anywhere... You're not wrong. But, on the other hand, the last thing anyone thought we needed was "yet another" search engine in 1997 when google dot com was registered.

You just never know.

aleksjess2• 6 years ago

Ok, so it might be the best new thing, and hype can be enormous, however at the end of the day there's only one question - will people use it?

EugeneOZ• 6 years ago

There is no project where you can be 100% sure about the success.

LockAndLol• 6 years ago

Can this be embedded into other apps or is this "just another browser"? The page says it's a browser engine, but it mentions using opengl and glut, so I'm not sure. Seeing as it only has a `src/main.rs` I assume it's an app, not a lib?

Datsundere• 6 years ago

How does one get started with building a rendering engine? I would love to get some guides on this. I agree that there are inherent problems with css with how complex it is now

wernsey• 6 years ago

Let's build a browser engine! [1] by Matt Brubeck is a good place to start. I see Kosmonaut cites it in its README

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...

[2] https://github.com/wernsey/robinson-c

Kosmonaut: web browser from scratch in Rust

Related Stories