29 ms·

Kosmonaut: web browser from scratch in Rust

• caiobegotti 6y 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_alan 6y ago
    Nah, it’s too nascent for ACID.
  • zamadatix 6y 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.
    • akling 6y 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. :^)
      • emptyparadise 6y ago
        Maybe the real goal all along was to have fun and not to take over the world.
      • mappu 6y ago
        Is it possible to run your SerenityOS browser (or rather the LibWeb renderer) outside of SerenityOS? Perhaps using something like OpenSSH's portability layer, or OPENSTEP's late-in-life Windows NT port?
        • akling 6y ago
          There's no actively maintained port right now, but jcs@ ported it to OpenBSD a while ago. His branch[1] is a couple months behind now, but it wouldn't be terribly difficult to get it working again. It's mostly POSIX code so it's pretty portable. [1] https://github.com/jcs/serenity https://github.com/jcs/serenity
  • missblit 6y 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.
    • jefftk 6y ago
      Specifically: https://wpt.fyi https://wpt.fyi
  • ori_b 6y 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 6y 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.
  • adamnemecek 6y ago
    Alternatively figure out a better css and do that.
    • amiga-workbench 6y 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.
      • emptyparadise 6y ago
        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.
        • Shared404 6y ago
          > the PDF standard includes a JavaScript library for some inexplicable reason. Indeed. Which also makes PDF's a dangerous file type to use.
        • amiga-workbench 6y ago
          In a similar vein I wish that email clients could support markdown message bodies instead of HTML.
• shaunrussell 6y 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 6y 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.
    • emptyparadise 6y 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.
      • JoshTriplett 6y ago
        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 6y ago
          Let's sandbox the apps!
          • JoshTriplett 6y ago
            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.
• john_alan 6y 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.
• prohobo 6y 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.
  • steveklabnik 6y ago
    Rust doesn’t prevent leaks, by the way, though it doesn’t tend to produce them.
    • Filligree 6y 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.
  • untog 6y 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.
  • rumanator 6y 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.
    • prohobo 6y 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 6y 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.
  • adamnemecek 6y ago
    This is partially thanks to rust and cargo.
  • timvisee 6y 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 6y 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-while-it-refocuses-on-commercial-products/ https://www.zdnet.com/article/mozilla-lays-off-250-employees...
• ChrisSD 6y 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.
  • krapp 6y 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.
    • ChrisSD 6y ago
      Sure but it's a hack that has a lot of popularity, even if only because of the web.
      • krapp 6y ago
        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.
    • hombre_fatal 6y 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.
  • niutech 6y ago
    Check out these projects: https://github.com/litehtml/litehtml https://github.com/litehtml/litehtml, https://github.com/yue/yue https://github.com/yue/yue, https://github.com/cztomsik/graffiti https://github.com/cztomsik/graffiti
• brundolf 6y 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 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 6y 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.
• pkphilip 6y 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_b 6y ago
    Since you are ditching compatibility here, you can also ditch the browser engine.
    • est31 6y 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.
      • solson4 6y ago
        Or maybe even have those sort of features be broken out as modules. Can have a flag that says you’re using this JavaScript library or that css layout module at compile time and not ship with anything else.
      • SahAssar 6y ago
        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 6y ago
          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.
• john366366 6y ago
  Given the recent layoffs at Mozilla the future of Rust seems bleak
  • Shared404 6y ago
    Both MS and AWS are interested in Rust. I doubt it's going anywhere.
    • john366366 6y ago
      Yes, as users. Not as someone willing to be a torch bearer of language designer.
      • steveklabnik 6y ago
        Both companies are contributing resources to the Rust project, not only using it.
  • adamnemecek 6y ago
    It really doesn't.
    • john366366 6y ago
      Why?
      • steveklabnik 6y ago
        https://news.ycombinator.com/item?id=24144938 https://news.ycombinator.com/item?id=24144938
        • adamnemecek 6y ago
          You guys should setup a rust donation site tho.
• weinzierl 6y 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.
  • est31 6y 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 6y ago
      You overestimate the number of issues that Rust would solve, versus the actual sec issues browsers have.
      • steveklabnik 6y ago
        When Mozilla analyzed this, it was found that half of security issues were memory safety issues.
        • atomicUpdate 6y ago
• The_rationalist 6y ago
  This work would be less pointless if it were allocated to servo. If this guy just want to have fun, fine; but it doesn't deserve to be seen on HN
  • zelly 6y ago
    Rust web browser gets axed in an incomplete state, most likely never to be completed. "I know, I'll start another Rust web browser"
• baby 6y ago
  If you prioritize tabs on the side (instead of up there) I will come and work for free on your project.
  • pikelet 6y ago
    Why does it have to be one or the other?
    • baby 6y ago
      because one is objectively better than the other
      • untog 6y ago
        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 6y ago
          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 6y ago
            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.
          • jfax 6y ago
            4chan
      • dnautics 6y ago
        some of us prefer to live relatively statelessly and don't need to seek counseling for tab-hoarderism
• catdawg 6y 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 6y ago
    Depends on how dependent it is on the javascript engine. Servo unfortunately was inseperable from js.
    • throwaway894345 6y ago
      Can you give more information (link?) about why Servo was inseparable from JS?
      • chc4 6y ago
        Servo has JavaScript own and collect the DOM nodes. At least, it did in 2014. https://research.mozilla.org/2014/08/26/javascript-servos-only-garbage-collector/ https://research.mozilla.org/2014/08/26/javascript-servos-on...
        • throwaway894345 6y ago
          That was very early in the project, but moreover, I would expect that simply means that Servo can allow someone else to own DOM nodes; not that it depends on a JS implementation specifically, no?
  • untog 6y ago
    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.
    • 6y ago
• pavpanchekha 6y 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/ 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 6y 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
    • pavpanchekha 6y 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.
• jazzyjackson 6y 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?
  • niutech 6y ago
    Have a look at NetSurf or litehtml (https://github.com/litehtml/litehtml https://github.com/litehtml/litehtml)
  • jfaat 6y ago
    Looks like ionic supports desktop apps now: https://ionicframework.com/docs/deployment/desktop-app 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.
    • neurostimulant 6y ago
      Isn't Ionic using Cordova Uber the hood? Cordova uses native webview.
    • lukevp 6y 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-smile 6y ago
    > 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.
• guerrilla 6y 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 :)
• tmd83 6y 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.
  • dmitryminkovsky 6y 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.
• dmitryminkovsky 6y 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 6y ago
    Just don’t implement JS. Simpler!
    • ghayes 6y 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 6y 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.
    • dmitryminkovsky 6y 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?
• fspeech 6y 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 6y 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.
  • krapp 6y 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 6y 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 6y 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 6y 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.
• jasonhansel 6y ago
  Question: what's the advantage of Kosmonaut over just forking Servo and continuing to maintain it?
  • zucker42 6y 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 6y ago
  How does this compare to Dillo?
• vikiomega9 6y ago
  As a tangent, is there a Firefox focus equivalent for the desktop?
• Communitivity 6y 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.
  • adamnemecek 6y ago
    It's not related.
  • ezekiel68 6y 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 6y 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 6y ago
    I, for one, love Safari! I will use Safari on MacOS and Firefox on Linux, but only Chrome for frontend development and testing...
  • kelnos 6y 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 6y ago
    How is safari focusing on performance and privacy? AFAIK its the worst performing browser and easiest one to fingerprint.
    • andai 6y 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.
      • deleted 6y ago
        [deleted]
      • dahfizz 6y ago
        That's pretty surprising, considering chrome on iOS is basically just a safari skin. Is there a more in depth look at this anywhere?
• mrmonkeyman 6y ago
  Browsers are non-issues and they will come and they will go. The web is IP, HTTP, TCP, DNS etc.
• AbuAssar 6y ago
  Use stylo for css rendering. Stylo is also a servo component that is ready for production.
• the_other 6y 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.
• ezekiel68 6y 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.
• aleksjess 6y 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 6y ago
    There is no project where you can be 100% sure about the success.
• LockAndLol 6y 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 6y 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 6y 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.html https://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.h... [2] https://github.com/wernsey/robinson-c https://github.com/wernsey/robinson-c