
Kosmonaut: web browser from scratch in Rust - adamnemecek
https://github.com/twilco/kosmonaut
======
dmitryminkovsky
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?

~~~
userbinator
_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.

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

~~~
userbinator
_and don 't care about "pixel-perfect" rendering or any sort of interesting
layout_

A common theme in all these "reinvent the web/browser" discussion is going
back to the web as a hyperlinked document library and not an application
platform, in which case pixel-perfect rendering is neither necesary nor even a
goal.

 _For example, implementing comment parsing per the letter of the HTML4 spec
is extremely not-web-compatible_

HTML5 parsing is completely specified and definitely compatible, even the
error cases. Any stream of bytes will turn into a DOM. (Philosophical
question: are they even errors anymore, if all implementations will produce
the same output?) Perhaps that would be a good starting point.

~~~
bobthepanda
> A common theme in all these "reinvent the web/browser" discussion is going
> back to the web as a hyperlinked document library and not an application
> platform, in which case pixel-perfect rendering is neither necesary nor even
> a goal.

And how exactly would one even put this genie back in the lamp?

~~~
taneq
Have HTML5 as an application platform and markdown or something as a
hyperlinked document format?

~~~
dredmorbius
Which Markdown? There are so many to choose from....

In seriousness: Most Markdowns are 1) fairly similar and 2) sufficient for the
vast majority of documents. If the goal is a stable, mature, and complete
markup language, I'd be inclined to give LaTeX top billing. Markdown can of
course generate LaTeX.

~~~
majewsky
(La)TeX is a bad fit because its document model is based on paginated
documents with a fixed page size, whereas HTML documents are intended for
variable viewport size. LaTeX is to HTML as PDF is to EPUB.

~~~
dredmorbius
No it is not.

LaTeX can, whether through the old model of dvi, or modern tools such as
xlatex and pandoc, directly produce numerous document formats or "endpoints"
as I consider them, including HTML, ePub, plain ASCII (or UTF-8) text, or
paginated formats including ps, PDF, and djvu. _LaTeX is not itself
fundamentally print-oriented._ The fact that it _can_ and _does_ produce
excellent print-formatted output is a feature, not a bug.

What it _is_ , and pointedly in ways that HTML lacks, is capable of
intrinsically handling document-centric ( _not_ merely "print") elements
including footnotes, endnotes, and formulae, all of which still require
kludges after over a quarter century on the Web.

Markdown itself does not address several typographic or document conventions,
including formulae, but also odd omissions such as underline and coloured
text. Whether those get shimmed into Markdown, or an alternate (light- or
heavy-weight) markup language is adopted, isn't clear, but those are very
annoying lapses.

For the vast majority of documents, this does not matter. Most online content,
say news media, use little more than paragraph, italic, and anchor elements.
Even bold and list are rarely used. _Authoring_ in Markdown should be almost
wholly sufficient, but it's (La)TeX which has sufficient richness of
expression to serve as the common underlying document format language.

Late edit: It also occurs that another principle angle of attack on HTMK
alternatives, raised elsewhere in this thread, is that these cannot guarantee
pixel-perfect presentation. That results in rather a "damned if you do, damned
if you don't" situation: propopsed markup alternatives either cannot guarantee
layout or over-guarantee layout. These objections rather want for consistency.

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

~~~
timvisee
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
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...](https://www.zdnet.com/article/mozilla-lays-
off-250-employees-while-it-refocuses-on-commercial-products/)

------
brundolf
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](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.

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

~~~
mrec
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...](https://manishearth.github.io/blog/2017/08/10/font-size-an-
unexpectedly-complex-css-property/)

~~~
brundolf
Yeah so this is exactly the kind of thing I'm talking about:

\-----------------

The syntax of the property is pretty straightforward. You can specify it as:

\- A length (12px, 15pt, 13em, 4in, 8rem)

\- A percentage (50%)

\- A compound of the above, via a calc (calc(12px + 4em + 20%))

\- An absolute keyword (medium, small, large, x-large, etc)

\- A relative keyword (larger, smaller)

The first three are common amongst quite a few length-related properties.
Nothing abnormal in the syntax.

The next two are interesting.

\-----------------

I've been doing front-end web dev for nearly ten years, and I've never even
_heard_ of those last two, much less used them. That's the kind of thing a new
browser could defer support for until after the MVP, while barely detracting
from the average user's experience.

Though this does remind me that i18n is a thing, and how gnarly of a problem
it must be for a piece of software so concerned with text flow/layout, and
ideally it's not something that a theoretical upstart browser would punt on.

~~~
jefftk
While I think you're right that the last two are very uncommon, they are not a
large contributor to the complexity of handling font sizing. Once you've done
all the rest, I suspect you could add them with <5% more work.

Leaving out rare features to build a browser more quickly only makes sense if
those features let you remove a lot of complexity from your implementation.

~~~
brundolf
When it gets to the point of diving into the last two, the article literally
says:

> Alright, this is where it gets complicated.

I haven't implemented any of the above myself, but the author at least seems
to think the last two are where the complexity is concentrated.

~~~
jefftk
Sorry, you're right. I've gone back and read the article and there was
complexity in those two that I had completely forgotten about.

------
jazzyjackson
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?

~~~
c-smile
> to find a no frills rendering engine that I could package up like an
> Electron

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

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

[https://neutralino.js.org/](https://neutralino.js.org/)

~~~
voglerr
Interesting, but should be clearer about what this entails. What are the
native browser components currently using? Windows: some old IE,
EdgeHTML+Chakra, Blink+V8? Linux/macOS: WebKit?

~~~
niutech
They are using
[https://github.com/webview/webview](https://github.com/webview/webview) under
the hood, which is using Cocoa/WebKit on macOS, gtk-webkit2 on Linux and Edge
on Windows 10.

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

~~~
est31
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
You overestimate the number of issues that Rust would solve, versus the actual
sec issues browsers have.

~~~
Jweb_Guru
Something like 70% of all CVEs in C++ applications (including browsers--the
actual type of application doesn't seem to matter much) are memory safety
issues. Yet the myth persists that memory safety isn't an important bug class
for stuff written in modern C++. I think the converse is true: most C++
programmers tend to significantly underestimate the number of remaining bugs
in their code that are memory safety bugs.

~~~
edflsafoiewq
How many memory safety issues are in the JIT? Because Rust won't help you
there.

~~~
Jweb_Guru
Bugs related to the JIT are normally counted separately, AFAIK. The 70% figure
tends to hold even in systems with no JIT. However, it would not surprise me
if about 70% of JIT CVEs are memory safety bugs. The trend for unsafe Rust so
far seems to be very similar BTW (about 70% of unsafe Rust CVEs are memory
unsafety--contrasted with virtually no non-unsafe Rust CVEs that are memory
unsafety, and all that were are due to compiler bugs).

The overall trends tell me that in the absence of a proof assistant, however
carefully you scour your code for bugs, you will miss some. And 70% of the
ones you miss will be memory unsafety unless you are using a system that
explicitly prevents this.

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

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

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

~~~
dahfizz
That's pretty surprising, considering chrome on iOS is basically just a safari
skin. Is there a more in depth look at this anywhere?

~~~
wtmt
I’m pretty sure the GP is referring to battery usage comparisons on Mac and
not iOS.

There may be battery use differences on iOS too (the UI, networking and other
pieces are still Chrome’s), but not of the magnitude described here.

~~~
andai
Since Chrome on iOS is mostly safari (as far as the heavy lifting goes), I
expect Chrome on iOS is easier on battery than it is on Android.

My meaning was that Safari is heavily optimized for power usage because most
people using it are on mobile devices, and the difference is dramatic, at
least on macOS where you can compare it.

I wonder how Chrome's traffic compares across mobile, laptop and desktop (I
don't think laptops can be detected in browser stats). They certainly seem to
focus on maximum performance above all else.

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

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

[https://sciter.com/](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.

~~~
c-smile
Why "in theory"? Here are real life applications:
[https://sciter.com/#customers](https://sciter.com/#customers)

~~~
untog
My “in theory” was referring to Kosmonaut. Then I pointed out Sciter as
evidence that something similar has already been done.

------
pkphilip
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_b
Since you are ditching compatibility here, you can also ditch the browser
engine.

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

~~~
SahAssar
I don't think WebSQL is the best example. Chromium uses SQLite for other
things (bookmarks, history, etc.) and WebSQL is mostly a JS API for
interfacing with SQLite so I'm guessing the overhead isn't huge (and SQLite is
pretty small to begin with).

~~~
est31
Good point, and while the average Electron app probably doesn't need history
or bookmarks, there are probably use cases it would still need WebSQL for.
Another example would be the ffmpeg copy it ships to play back videos of
various formats, even though the electron app only plays back a few hardcoded
animations that all are in a single format.

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

~~~
dmitryminkovsky
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
“Demise” is nothing less than hyperbole.

~~~
dmitryminkovsky
They stopped developing Servo and their dev tools. How does that not signal
the end of Firefox as a non-Blink, non-Webkit browser?

Edit: I see you work at Mozilla. IMO Firefox is the most important software
project in the world (not hyperbole). Are you saying it will somehow remain an
independent web rendering/execution platform given this past week?

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

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

~~~
jefftk
Specifically: [https://wpt.fyi](https://wpt.fyi)

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

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

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

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

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

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

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

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

~~~
krapp
Being the most popular thing doesn't necessarily make it the best thing.

We should be looking at "native web apps" as a stepping stone, a proof of
concept for the architecture and design patterns of the web, but necessarily
the platform itself. At the end of the day, it's just an XML document,
stylesheet and escripting language running in a VM. There's no reason it _has_
to use a browser engine and HTML.

------
pavpanchekha
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/](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.

~~~
jazzyjackson
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

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

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

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

~~~
JoshTriplett
I like my apps to run in a sandbox, and the web is the best sandbox we have.
My standard reaction to "would you like to download our app" is "no, stay in
your box".

~~~
emptyparadise
Let's sandbox the apps!

~~~
JoshTriplett
We have. They run on the web, in tabs. Or, with PWAs, they look a lot more
like native applications, and still run in a safe sandbox. (There are also
Android and iOS apps, which are less ideal and less portable.) Why reinvent it
in a less portable, less sandboxed, historically insecure manner? People have
tried, and the result never ends up as useful, functional, or secure as the
existing web sandbox.

When I browse the web, I know the browser puts me in control, and keeps
applications contained. The only kind of app that I know will have comparable
sandboxing is a PWA. Anything with a comparable amount of control will look
like a web browser, and we already have the web.

If you want the world to change, you have to offer something better.

~~~
emptyparadise
There is great technology out there for app sandboxing. Recent Windows
versions let you instantly spin up a virtual machine to run unknown apps in -
I'd say that's safer than a browser and there is no reason why it can't be as
convenient.

You speak of the web as an app platform - I'm not opposed to some platform
like that existing (and they do exist, just look at your OS), I just think
that we made a mistake when we turned the browser into one. Now we mix
together hypertext and code and have so much weird legacy to maintain, not to
mention the performance issues.

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

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

------
fspeech
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?

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

~~~
pikelet
Why does it have to be one or the other?

~~~
baby
because one is objectively better than the other

~~~
untog
Surely not. They are simply each better for different use cases.

If you have ~5 tabs then tabs on the side is a waste of screen real estate. If
you have 50 then on the top is unreadable.

~~~
baby
Do you ever have websites that use the full width length of your page? I’ve
never seen that except for horizontal scroll webpages or if you are on a tiny
screen.

~~~
untog
I definitely have. Gmail is one that comes to mind: it scales to let you see
more of a message.

A lot of people are on 13” laptop monitors, they’re not _that_ wide.

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

------
LockAndLol
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?

------
AbuAssar
Use stylo for css rendering.

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

------
Datsundere
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
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...](https://limpet.net/mbrubeck/2014/08/08/toy-layout-
engine-1.html)

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

------
aleksjess
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
There is no project where you can be 100% sure about the success.

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

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

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

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

------
rocky1138
How does this compare to Dillo?

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

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

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

~~~
steveklabnik
Both companies are contributing resources to the Rust project, not only using
it.

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

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

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

~~~
adamnemecek
Alternatively figure out a better css and do that.

~~~
amiga-workbench
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.

~~~
emptyparadise
I'd say something about just wanting PDFs with text reflow and hyperlinks, but
apparently the PDF standard includes a JavaScript library for some
inexplicable reason.

~~~
amiga-workbench
In a similar vein I wish that email clients could support markdown message
bodies instead of HTML.

~~~
krapp
Markdown _is_ HTML. Its purpose is to be converted into HTML. It includes the
entirety of HTML in its spec.

You can't support one without supporting the other.

~~~
zzo38computer
A subset should be invented which lacks HTML.

