Why isn't contributing to existing projects like Servo feasible? Do they reject the benefits of modularity?
What existing code is being leveraged, or is this entirely from scratch? Why was lifting code from Servo or elsewhere not sufficient?
Is this project intending to remain fully non-profit or is there some kind of vision for monetization to support the gargantuan amount of effort it would take?
It says writing a javascript engine is out of scope, but it still isn't clear definitively what is in-scope or out of scope.
Good points.. we will definitely set up a FAQ with these kind of questions. But to be honest, we might not have an answer for all of them. Why not use Servo's CSS system and create our own, but using v8 javascript engine is mostly a question answered by: "don't know"..
Obviously we cannot write everything by scratch, but we don't know yet where we draw the line.. We like to keep things modular as possible so we can easily swap out the systems we use in favor of better ones in the future.
We actually kind of have a javascript engine. It is a more personal project of mine, but it is also intended to be used and intigrated into gosub. In case someone is interested, here is the repo: https://github.com/Sharktheone/yavashark
I remember my Atari behaving awfully slow (whole atari basic environment, even after the program finished) because I did many GOSUBs without the amount of RETURNs necessary, and didn't understand why because I was only 9yo at that time...
Trivia: at least in some BASICs (QBasic, QuickBasic, FreeBASIC) it's not necessary for every GOSUB to be matched with a RETURN, since the GOSUB is a single 'call' instruction that pushes onto the stack (and RETURN is a single 'ret' instruction, hence GOSUB-RETURN is highly efficient!) so it gets removed when you exit the function if you didn't RETURN, like alloca(). I actually re-implemented GOSUB this way using macros and inline assembly. I called it GOSUB/RETRACE.
In Wang BASIC, there was the "RETURN CLEAR" statement which cleared the stack up to and including the most recent GOSUB call frame. This includes any FOR loop frames that were push on the stack in the subroutine before the GOSUB. This was intended to be used for handling error conditions.
Thanks for this! I didn't really use BASIC much back in the day, but I am from - ahem - an older time...and the name seemed so familiar, but quite couldn't place my finger on it. so, thanks for clarifying this! :-)
> In 1980, Stallman and some other hackers at the AI Lab were refused access to the source code for the software of a newly installed laser printer, the Xerox 9700. ..This experience convinced Stallman of people's need to be able to freely modify the software they use.
And Linux.
> Frustrated by the licensing of Minix, which at the time limited it to educational use only, he began to work on his operating system kernel, which eventually became the Linux kernel.
It's true that the complexity of these kinda projects are enormous, but considering chrome/webkit's monopoly in the browser space, I feel we should always welcome and appreciate alternative efforts...regardless of the project's outcome.
P.S. the website and the probably AI generated logo is giving a sketchy vibe about the project :)
Isn't this how generative models are supposed to be used?
Instead of generating a sub-par (no pun intended) logo myself, I get a model to build one for me.
It is the same as using any computer software to achieve the goal - human is providing the inputs and hardware and software are generating the output.
> Isn't this how generative models are supposed to be used?
Might be, or better just use the name as the logo. At this initial stage no one expects to see a good branding I guess.
I've recently seen lots of low effort, sketchy looking projects using "sub-par" quality AI generated assets...and in turn when I see these kinds of images used in some project it really just shows off "put least effort to get things done" mentality...I feel.
I love the logo and I love the name. Sounds like a polarizing logo; that's a good thing. I remember having similar thoughts to this other person when Google first launched their search engine with their "ugly rainbow" logo. You're good.
> I don't know if it is a compliment that my website design skills match the ones of AI or if it is more an insult
Neither, it has nothing to do with design. I just wanted to point out that putting an AI generated logo, and writing vague statements like "optimised search and unlimited browsing" seems unprofessional to me.
The "optimised search and unlimited browsing" isn't really a statement, it is the expanded form of the acronym gosub. As I said, I don't really like it, but this is what we have now... :/
But I can definitely see where you are coming from.
>P.S. the website and the probably AI generated logo is giving a sketchy vibe about the project :)
certainly some reasoning would be more constructive than a smiley face, because I looked at the website, I looked at the logo[0] - I didn't share the same feeling.
Certainly it could be AI generated, but why 'sketchy'? Is it something to do with your own personal feelings on AI use, or just the aesthetic in general?
I genuinely don't understand -- this isn't a criticism or witty comment lest it be taken that way.
Just a personal perspective… no problem with the logo but the headline
“The Gateway to Optimized Search and Unlimited Browsing”
Doesn’t really mean anything to me and does sound vaguely scammy. Anyone promising me the gateway to unlimited anything gets a raised eyebrow, two if it’s something I already have unlimited access to.
Why not spend this effort contributing to Servo, which is also written in Rust? It seems the two projects share similar goals but Servo has a massive headstart.
Because Servo is run by others with a different agenda that came from a billion dollar company that gets hundreds of millions from a trillion dollar company and they decided to dropped it. The political effort to get to a place where you can shape the project is a huge mountain to climb and unlikely.
Starting your own project you can set the agenda and pace and truly create your vision.
The people who want to do the first idea are very different from the group that want to do the second.
Why not fork it then? You don't need to be able to set the agenda for a project if you just fork it and rename it: you can now set the agenda for your fork and ignore the other project, while not having to spend time reinventing the wheel.
Me saying there's not a distinction between forking and writing your own project from the "why don't you just" perspective has nothing to do with a slippery slope.
Agreed. Honestly, wasn't the whole purpose of open source to be kinda free for all ( the followers, the inventors, the grinders... you name it ). Why does everything I read lately start with a 'should'. I am making a mental note to self.
The problem is that we all vastly differ on what constitutes a positive change. I can practically guarantee you that you are somewhat unlikely to see changes I would suggest as 'positive'. On the other hand, it is not unlikely I would see yours as positive either.
That is why, for all its flaws ( and current set of issues ), current attempt at self-organization is simply better in the long run even if it is a little messy.
no, it probably wouldn't. if people are doing it for fun, they don't want to sit in meetings with strong personalities telling them how to do it. they enjoy coding, they enjoy thinking through interesting things, they don't enjoy taking orders and doing things a certain unfulfilling way just because somebody else prefers it that way. usually you have to pay them for putting up with that kind of thing.
I've been writing an open source DAW for 25 or more years. Every time I see somebody else working on their own new open source DAW or DAW-adjacent project, I find myself wondering whether it would be a better or worse thing if they put their efforts into our already-existing project.
Yes, but I'm concerned about the number of existing browser engines that have fallen by the wayside, as the project founders have become exhausted. The scope of such a project is incredibly easy to underestimate, and it has only ever gotten larger.
Servo and Ladybird are more active than ever, each having fresh funding and ramping up focused development. Flow is a commercial project for embedded media devices (not just available on rpi, it actually came there later) and seems to be doing well? Sciter I don't know one way or the other about, it seems to have a few popular apps using it but I don't know if it died off since then or is just going strong. Netsurf has always been a bit by the wayside but it doesn't seem like founders getting exhausted has much to do with that.
There are plenty of browser engines that have fallen by the wayside, often for reasons unrelated to the founders, but that particular list actually paints a surprising amount of the opposite to me. For once since Chrome came out (it at least introduced v8 even if it started with webkit) I have the feeling there are browsers engines in development that can actually attempt to load the modern web and will actually have products for general use cases (instead of specialized ones) in the coming years.
I wouldn’t call Sciter a browser engine. The CSS syntax is similar and some properties behave the same, but it doesn’t implement web standards by design.
All I have to do is stumble upon a heated 100+ post discussion on the implementation details of an arcane feature of CSS to understand how mammoth an undertaking it must be to develop a fully compatible browser engine.
Do we need more "fully compatible" engines? I could imagine there are use cases for browser engines that work with just parts of the specification, particularly the most common ones used in the wild.
Just as a data point, the YouTube app on most TVs and devices is a stripped down browser only supporting exactly the HTML/CSS/JS needed to run the big picture client.
By tighter integration with the final product, the browser can provide specialized elements or APIs to simplify the actual application code.
That just means that specific subset of features wasn't lucky enough to make it compelling at that particular point in time for the markets it meant to address.
Change any of those variables and you may have a winning proposition.
The various web specifications are insanely complex (e.g. navigables) so I can see how people burn out from it. To add onto that, a browser operates in an extremely hostile space security wise; to be a serious competitor, you'll need to be on top of your game in that regard which maybe Rust will help with.
Something very silly has happened, where the thing that most non-technical people have which is most exposed to hackers is also incredibly complex and requires high performance for some reason.
Because the complexity and functionality of the modern (whatever the fuck this means) browser basically approaches one of the OS with all the consequences.
Yeah it's a real shame. The complex (and ever expanding) nature of the web is the real thing entrenching incumbents like Google. They have the existing codebase and resources to handle the complexity.
Yeah. I still hope at some stage we build something much simpler that maintains the same security boundary.
Like an application platform (forget documents) built entirely on wasm, and with capability based security. That would let you launch apps made within the platform just as easily as you currently open a website.
The platform would need some primitives for rendering, UI, accessibility and input handling. But hopefully a lot of those APIs could be much lower level than the web provides today. Move all the high level abstractions into library code that developers link into their wasm bundles. (For example, I’m thinking about most of what css does today.)
That would allow much faster innovation in layout engines and other things the web does today, and a smaller api surface area should lead to better security.
It’s quite possible to build something like this today. It’s just a lot of work.
Maybe when chatgpt is a bit smarter, it might be able to do the lion’s share of the work to make this happen.
>"Like an application platform (forget documents) built entirely on wasm, and with capability based security. That would let you launch apps made within the platform just as easily as you currently open a website."
In the end you will end up with the platform / OS which will lose to competitors because of performance and lack of features and do not expect it to be secure. Developers will manage to leave some holes and hackers will find their way.
Disagree. The web wouldn't be anywhere near as successful if you needed to trust & "install" websites before you could visit them. How does that work? Why don't you need to install / trust a website to use it? Well, because it has this kind of security model. Websites are sandboxed.
The web's sandboxed security model makes it better for users. And that in turn drives popularity.
I think the same could be true for a good application platform. The trick is using the sandboxing + capability based security model to enable "new" usability features that traditional applications can never deliver.
Sandboxing has to be the funniest bit of wordplay anyone has ever made in tech. Sand is, of course, notoriously impossible to contain and never stays in the box. And it is not nearly as clever as an attacker!
The term doesn't come from the idea of containing sand.
It comes from things built for children to play in that have an edge with contents inside it. You play "in a sandbox" without having to deal with anything outside of the sandbox.
The sand in a children's sandbox spills over and gets everywhere. The children playing inside it .. they don't have to care. They are playing inside the sandbox, and for now, the world outside it is not relevant.
My girlfriend has strong opinions about how we use the word "library" to describe a software package.
Surely the metaphor should be that one package is a "book" and the entire package repository is the library, right? Left pad is an entire library? Huh?
And then we have no collective noun for collections of libraries!
Honestly, I view projects like this as more of an intellectual curiosity than anything which seeks to become useful .
The Firefox engine is great if you don't want something controlled by Google. And it's going to be much easier to develop plugins or extensions for that versus trying to write your own browser from scratch, which to be honest will probably cost hundreds of millions of dollars. If not more.
I do imagine tools like this being useful for something like web scraping, but it's never going to be an end user product.
One can only hope we can get a browser the same way we got Linux, but as RMS was fond of pointing out, Linux’s success had a lot to do with the existence of a full suite of GNU software that could run on top of a new kernel. If only we had something like GNU with browser engines, I’d be more optimistic about the chances for success of many new entrants.
> Linux’s success had a lot to do with the existence of a full suite of GNU software that could run on top of a new kernel
I've heard this a number of times; but circa 1991 I'm not convinced. The critical GNU components to scaffold Linux adoption were:
- GCC + C runtime
- A shell (plus a bunch of small utilities)
You could make a reasonable argument that Linux was and remains a much bigger achievement, namely because GNU has never actually managed to make a usable kernel (Hurd still has no USB support, for example. I don't know if this is for technical or political reasons).
On the flip side, there were plenty of compilers and shells kicking around that Linux could have bundled.
RMS makes all sorts of wild claims about how much of a distro is "GNU software" (a criterion that is never clearly defined - is any non-kernel GPL software part of GNU?) by comparing lines of code; but at the time of these claims distros tended to bundle anything and everything that you might possibly want.
Contemporaneously to all this, 386BSD had created a full freely-distributable Unix with no GNU code; and its descendants might have captured the mindshare were it not for an extended copyright battle from AT&T.
For web scraping at scale you want to get lost in the crowd. This usually means being (or pretending to be) chromium on windows. Unusual browsers are suspicious, detected or have very distinct fingerprint.
Indeed. I heard about a browser called Zen a couple weeks ago and installed it. Just took it for a drive yesterday, and by the end of the day, Reddit had blocked me just based on my sporadic, normal use of the site for about two hours here and there while I did other things.
I switched back to Safari and it worked normal immediately.
I applaud the project espoused spirit, because, similarly to the author(s)' webpage, i don't think we should have a monopoly in this space ( especially given recent moves by Google ).
Small things to be noted ( in the small, but noticeable category):
- repeated paragraph ( https://gosub.io/learn-more/ )from 'Gosub started' to 'open and free'
- that is it for now:D.. I will be personally watching it with some interest
I was hoping for a small embeddable engine to finally replace Electron. The build on Windows ends up being 55MB, not too bad but still too large for simple apps.
Yes, we're working on that over at https://github.com/DioxusLabs/blitz (alpha release imminent). Our TodoMVC example is current ~20mb with a standard release builds, but comes down to 7.2mb with some compiler flags like -Oz and LTO enabled (these numbers of from macOS).
And we plan to allow fine grained configuration of the feature set, so if you don't need certain image formats or layout algorithms or networking support, then you can disable them and save on binary size.
Ohhhh...this is so awesome. Fits the most common app usecase for plain HTML+CSS rendering library and not a humongous browser for developing offline apps and its terrific that something like blitz exists.
blitz is cool piece of tech but it seems that it needs dioxus framework to do any sort of interactivity which in turn needs to be written in rust. Which is a lot slower than writing a electron app.
Well, the application is basically unoptimized. However, we also don't have many components yet that can eat up your memory. But we try to keep the memory usage as low as possible. We also thought about integrating it into something like Electron, and for something like that it is important to have a low memory usage.
Lateron, we might have some compile time flags to reduce memory usage in cost of a bit of speed. Most Electron apps don't require that big oomf performance on the startup, since everything is locally and can be cached in a better way.
Servo and Tauri still let the Application use JavaScript, which is just very wasteful. I was thinking about making it possible to write dynamic websites completely without JavaScript, by building up WASM support and making that even faster. But that's a not the goal for now. Indeed, we don't even have a JS API for websites yet...
I'm always disappointed when conversations here are full of "why don't you just contribute to <other project> instead?" Have you never simply desired to do something yourself?
Right? I don't think HN needs more obligatory "this is a big undertaking and likely to fail" comments. We can take those as implied. We should 1) engage more meaningfully with the project and 2) keep in mind that negativity hurts a lot more than positivity helps. If you're not up to the task, fine, and maybe they aren't either, but don't drag them down before they've tried.
> We’re looking for developers with or without experience in Rust. You just need to be interested in browser technologies.
Well, both that and the ability to work on a project that requires you to run a toolchain whose minimum barrier to entry wrt resource use and developer experience makes the C++ ecosystem that preceded it seem lean and inclusive.
Sounds very hard. For example, Rule 21.3 in MISRA C 2012 basically prohibits dynamic memory allocation (e.g. malloc, calloc, realloc, free). Implementing a browser with such restrictions would be quite misrable.
I would think the MISRA rules against dynamic memory allocation would present serious difficulty if not fundamental incompatibility when trying to implement web standards.
I'm confused. Why do you name it “go”-something when it is not implemented in Go... I have a more catchy name for you, Rub, which stands for route to unlimited browsing.
Thanks for the pointer. And it makes it doubly confusing. Doesn't a reference to an obsolete, pre-modern language tarnish the reputation of Rust? Doesn't the creator of this project fear lawsuits from the legal team at The Basic Foundation?
I would recommend to focus on a niche like browser automation/QA with puppeter specially after they released the webdriver bidi[0]. There is a market for this kind of product if it's lighter/faster than chrome.
Rust gives you the performance of C++ if not better sometimes, with code that won't go haywire at the 11th hour. There is value in that, particularly in an application that's sole purpose is to load arbitrary stuff from the internet.
Also if it was written in anything else, it probably wouldn't get the coverage it gets ;)
It's funny; I wish Rust was better suited for bare metal than it is now. But no matter how much people perceive Rust as a bare metal language like C, it was quite literally made for a level or two above that, in browser engines.
(Here's to hoping Rust for Linux continues to drive progress for bare metal Rust!)
There are long lasting bridges made of stone, concrete and in the right climates, even wood. Not to mention rope when it suits the purpose.
Each material has its own qualities, which means its own pros and cons in a given context.
This naive belief that there will be one language to rule them all (and is name is <fill-in-the-blank> ignores history and the world outside of programming in a rather silly way.
Rust is a risk-reduction strategy. It is not a risk-elimination strategy.
There are risk-reduction strategies one can follow with C++, which offer some fraction of the reduction that Rust does (opinions vary on the value of the fraction). Rust enforces risk-reduction strategies, which in some contexts may be of value all by itself.
Language choice does not eliminate risks in software.
They don't really. It's been shown by many studies that 2/3 of security bugs are memory safety errors. That's the minimum that Rust can eliminate.
It actually should eliminate more because it also has the strong type system and tree-ownership style that help reduce the chance of logic bugs unrelated to memory safety too (similar to Haskell and other very strongly typed languages).
Unfortunately they don't break out non-memory safety vulnerabilities, but they've almost eliminated memory safety vulnerabilities by writing new code in Rust.
Nobody is saying that. But to continue your analogy, do you not think that in a world where all the bridges are made of wood it would be notable to say that a new bridge is made of steel?
Of course there are impressive projects made with C. But we generally don't build large bridges out of wood anymore do we.
Try your best to ignore the rewrite-it-in-Rust people. They're just plain wrong for that. But yes, for a niche like browser engines, Rust is pretty darn well suited.
I highly doubt that. At least not in a native way. However, you could make an adapter from the native interface to wasm components. Would be interesting to look into!
The byte stream is one of the first components that was written. Probably It wouldn't be written nowadays. The browser is quite modular, so in the end you can completely out out of that system.
Yes, the HTML parser, probably the component that is the most spec compliant. I think the CSS parser also is. For the initial phase, I think it is more important to get something working. For a later implementation, the spec should dictate what we do and what not. But with a small team, it is just not feasible.
HTML5 parsing is relatively easy, because behavior for tag soup is 100% specified. That is, in theory, all conformant HTML5 parsers should output the same DOM for any arbitrary byte sequence.
Layout is much harder because the CSS spec is full of UB, so you will have to do some reverse engineering there.
You can only do so much, so success depends on which components you decide to reuse. I wouldn’t build a new database or filesystem abstraction from scratch, for example.
Rust has lots of bytestream abstractions already with a ton of work put into them. Maybe they have a valid reason for going their own way. I’d like to know.
There are people who write their own hash tables, and there are those who just use a library. What may seem like a bad idea to some is trivial to others. Hacker culture is way more fun when you are allowed to use recursion [1].
Needs an FAQ
Why isn't contributing to existing projects like Servo feasible? Do they reject the benefits of modularity?
What existing code is being leveraged, or is this entirely from scratch? Why was lifting code from Servo or elsewhere not sufficient?
Is this project intending to remain fully non-profit or is there some kind of vision for monetization to support the gargantuan amount of effort it would take?
It says writing a javascript engine is out of scope, but it still isn't clear definitively what is in-scope or out of scope.
Good points.. we will definitely set up a FAQ with these kind of questions. But to be honest, we might not have an answer for all of them. Why not use Servo's CSS system and create our own, but using v8 javascript engine is mostly a question answered by: "don't know"..
Obviously we cannot write everything by scratch, but we don't know yet where we draw the line.. We like to keep things modular as possible so we can easily swap out the systems we use in favor of better ones in the future.
We actually kind of have a javascript engine. It is a more personal project of mine, but it is also intended to be used and intigrated into gosub. In case someone is interested, here is the repo: https://github.com/Sharktheone/yavashark
As a BASIC programmer from the 1980s, thank you for that heart attack.
They say BASIC programmers never die, the just GOSUB and never RETURN.
I remember my Atari behaving awfully slow (whole atari basic environment, even after the program finished) because I did many GOSUBs without the amount of RETURNs necessary, and didn't understand why because I was only 9yo at that time...
Trivia: at least in some BASICs (QBasic, QuickBasic, FreeBASIC) it's not necessary for every GOSUB to be matched with a RETURN, since the GOSUB is a single 'call' instruction that pushes onto the stack (and RETURN is a single 'ret' instruction, hence GOSUB-RETURN is highly efficient!) so it gets removed when you exit the function if you didn't RETURN, like alloca(). I actually re-implemented GOSUB this way using macros and inline assembly. I called it GOSUB/RETRACE.
In Wang BASIC, there was the "RETURN CLEAR" statement which cleared the stack up to and including the most recent GOSUB call frame. This includes any FOR loop frames that were push on the stack in the subroutine before the GOSUB. This was intended to be used for handling error conditions.
https://www.wang2200.org/basic_comparison.html#retclear
Or we get lost in DATA.
Just PEEK every address.
Careful doing that, you could POKE your eye out
Think of what TRON would do with that.
I don't have a Clu
For some reason your comment made me think about computed gosubs - pretty sure I've managed to forget about those for ~40 years!
lol GOSUB as a BASIC command, yes I can see the reference. It actually referes to the BASIC command.
Thanks for this! I didn't really use BASIC much back in the day, but I am from - ahem - an older time...and the name seemed so familiar, but quite couldn't place my finger on it. so, thanks for clarifying this! :-)
Logo? Lisp? Punched cards?
It's a great name!
Related:
I'm fed up with it, so I'm writing a browser - https://news.ycombinator.com/item?id=37608580 - Sept 2023 (477 comments)
how to introduce progress into civilisation? Just make some devoted engineer angry
So true. It's how we got rms and the GNU project.
> In 1980, Stallman and some other hackers at the AI Lab were refused access to the source code for the software of a newly installed laser printer, the Xerox 9700. ..This experience convinced Stallman of people's need to be able to freely modify the software they use.
And Linux.
> Frustrated by the licensing of Minix, which at the time limited it to educational use only, he began to work on his operating system kernel, which eventually became the Linux kernel.
It's true that the complexity of these kinda projects are enormous, but considering chrome/webkit's monopoly in the browser space, I feel we should always welcome and appreciate alternative efforts...regardless of the project's outcome.
P.S. the website and the probably AI generated logo is giving a sketchy vibe about the project :)
Isn't this how generative models are supposed to be used? Instead of generating a sub-par (no pun intended) logo myself, I get a model to build one for me. It is the same as using any computer software to achieve the goal - human is providing the inputs and hardware and software are generating the output.
> Isn't this how generative models are supposed to be used?
Might be, or better just use the name as the logo. At this initial stage no one expects to see a good branding I guess.
I've recently seen lots of low effort, sketchy looking projects using "sub-par" quality AI generated assets...and in turn when I see these kinds of images used in some project it really just shows off "put least effort to get things done" mentality...I feel.
"put least effort to get things done"
Some would say that's the mark of a great engineer.
Instead of generating a sub-par (no pun intended) logo myself, you should PAY to someone to make a logo, instead of stealing work from other people.
Using AI to generate a logo is no more stealing than asking a designer to make a logo. A designer will pull ideas from prior art.
That said, can't AI iteratively edit a picture? Then it can accumulate lots of input and one couldn't say input was small.
I generally agree with that..for a for profit project.
Gosub, despite have 2.6k Github stars, has a grand total of 0 sponsors. They literally take in no money. This is someone's unpaid side project.
I expect a designer would be welcome to contribute a design, just like coders can contribute code.
I think, at this stage, logo is the least important piece in all this.
That's the point. And if the maintainers still want to consider this, I feel that should be done right.
It's open-source. Why don't you contribute a logo or open an issue if you feel so strongly about it?
It's a glossy 3D emblem which aren't drawn today, it's like stealing sand from a desert.
No, the website isn't AI generated. There might be some parts of it, though, like general structure of the website and structure of texts.
Yes, the initial logo design was generated by AI, however the current logo was made by a designer from the AI's draft.
I don't know if it is a compliment that my website design skills match the ones of AI or if it is more an insult
I love the logo and I love the name. Sounds like a polarizing logo; that's a good thing. I remember having similar thoughts to this other person when Google first launched their search engine with their "ugly rainbow" logo. You're good.
> I don't know if it is a compliment that my website design skills match the ones of AI or if it is more an insult
Neither, it has nothing to do with design. I just wanted to point out that putting an AI generated logo, and writing vague statements like "optimised search and unlimited browsing" seems unprofessional to me.
The "optimised search and unlimited browsing" isn't really a statement, it is the expanded form of the acronym gosub. As I said, I don't really like it, but this is what we have now... :/ But I can definitely see where you are coming from.
if you don't like it. And people are also telling you they don't like it, then why do you insist on having it be an acronym?
The acronym was basically there from Day 1, I am not the Person who came up with it and I also wasn't there at Day 1.
> P.S. the website and the probably AI generated logo is giving a sketchy vibe about the project :)
The first half of this post reeks of GPT-ness as well, that was the first thing I noticed.
>P.S. the website and the probably AI generated logo is giving a sketchy vibe about the project :)
certainly some reasoning would be more constructive than a smiley face, because I looked at the website, I looked at the logo[0] - I didn't share the same feeling.
Certainly it could be AI generated, but why 'sketchy'? Is it something to do with your own personal feelings on AI use, or just the aesthetic in general?
I genuinely don't understand -- this isn't a criticism or witty comment lest it be taken that way.
[0]: https://gosub.io/gosub-logo.svg
Just a personal perspective… no problem with the logo but the headline
“The Gateway to Optimized Search and Unlimited Browsing”
Doesn’t really mean anything to me and does sound vaguely scammy. Anyone promising me the gateway to unlimited anything gets a raised eyebrow, two if it’s something I already have unlimited access to.
Iirc that thing was also AI generated. I don't like it, but here we are and have this sentence. Imo ChatGPT is for name generation not the... best
I don't think that's meant to be taken seriously/literally - seems like a tongue-in-cheek acronym for "GOSUB".
> certainly some reasoning would be more constructive than a smiley face...
I already gave the reasons there.
> I didn't share the same feeling.
Just a personal opinion.
The viewport is very wide on mobile Safari
The blog post that prompted the author to start this project:
I'm fed up with it, so I'm writing a browser (September 2023): https://adayinthelifeof.nl/2023/09/22/browsers.html
HN discussion at the time: https://news.ycombinator.com/item?id=37608580
Why Gosub if it isn't written in Go? Should have been called Rustsub ;-)
Personally, it reminded me of BASIC, not go.
The name gosub reminds me of the BASIC command, and at first I was expecting it to be written in FreeBASIC or some other BASIC dialect.
Someone else should write a browser engine called “Godom”. Which honestly would be a great name. A good browser will handle sessions and DOM.
Would someone please fix this GODOM browser that keeps crashing... Lol
Ok, I'll see myself out now. ;-)
Gosub is kind of an acronym. I don't really like it, but yeah Gosub and go would be more similar than to Rust
Why not spend this effort contributing to Servo, which is also written in Rust? It seems the two projects share similar goals but Servo has a massive headstart.
Because Servo is run by others with a different agenda that came from a billion dollar company that gets hundreds of millions from a trillion dollar company and they decided to dropped it. The political effort to get to a place where you can shape the project is a huge mountain to climb and unlikely.
Starting your own project you can set the agenda and pace and truly create your vision.
The people who want to do the first idea are very different from the group that want to do the second.
Why not fork it then? You don't need to be able to set the agenda for a project if you just fork it and rename it: you can now set the agenda for your fork and ignore the other project, while not having to spend time reinventing the wheel.
As if that wouldn't end up with the same style of "why don't you just" comments?
This is a slippery slope argument.
Me saying there's not a distinction between forking and writing your own project from the "why don't you just" perspective has nothing to do with a slippery slope.
people really need to take a democratic vote on what they do in their free time, it's getting ridiculous, some of them are even having fun now!
Agreed. Honestly, wasn't the whole purpose of open source to be kinda free for all ( the followers, the inventors, the grinders... you name it ). Why does everything I read lately start with a 'should'. I am making a mental note to self.
Try replacing "should" with "wouldn't it make more of a positive change in the world if" and see how that leaves you feeling.
The problem is that we all vastly differ on what constitutes a positive change. I can practically guarantee you that you are somewhat unlikely to see changes I would suggest as 'positive'. On the other hand, it is not unlikely I would see yours as positive either.
That is why, for all its flaws ( and current set of issues ), current attempt at self-organization is simply better in the long run even if it is a little messy.
no, it probably wouldn't. if people are doing it for fun, they don't want to sit in meetings with strong personalities telling them how to do it. they enjoy coding, they enjoy thinking through interesting things, they don't enjoy taking orders and doing things a certain unfulfilling way just because somebody else prefers it that way. usually you have to pay them for putting up with that kind of thing.
Wouldn't it make more of a positive change in the world if you went and did something useful instead of posting snarky comments on Hacker News?
It isn't snark.
I've been writing an open source DAW for 25 or more years. Every time I see somebody else working on their own new open source DAW or DAW-adjacent project, I find myself wondering whether it would be a better or worse thing if they put their efforts into our already-existing project.
from your point of view, they're wasting their time and effort. from their point of view, they'd rather fail than do unpaid work for you.
Yes, but I'm concerned about the number of existing browser engines that have fallen by the wayside, as the project founders have become exhausted. The scope of such a project is incredibly easy to underestimate, and it has only ever gotten larger.
Some examples: https://www.reddit.com/r/browsers/comments/124kphe/what_do_y...
Servo and Ladybird are more active than ever, each having fresh funding and ramping up focused development. Flow is a commercial project for embedded media devices (not just available on rpi, it actually came there later) and seems to be doing well? Sciter I don't know one way or the other about, it seems to have a few popular apps using it but I don't know if it died off since then or is just going strong. Netsurf has always been a bit by the wayside but it doesn't seem like founders getting exhausted has much to do with that.
There are plenty of browser engines that have fallen by the wayside, often for reasons unrelated to the founders, but that particular list actually paints a surprising amount of the opposite to me. For once since Chrome came out (it at least introduced v8 even if it started with webkit) I have the feeling there are browsers engines in development that can actually attempt to load the modern web and will actually have products for general use cases (instead of specialized ones) in the coming years.
I wouldn’t call Sciter a browser engine. The CSS syntax is similar and some properties behave the same, but it doesn’t implement web standards by design.
All I have to do is stumble upon a heated 100+ post discussion on the implementation details of an arcane feature of CSS to understand how mammoth an undertaking it must be to develop a fully compatible browser engine.
> develop a fully compatible browser engine
Do we need more "fully compatible" engines? I could imagine there are use cases for browser engines that work with just parts of the specification, particularly the most common ones used in the wild.
Just as a data point, the YouTube app on most TVs and devices is a stripped down browser only supporting exactly the HTML/CSS/JS needed to run the big picture client.
By tighter integration with the final product, the browser can provide specialized elements or APIs to simplify the actual application code.
I think it's used a few other places as well.
Most smart tv apps are just web apps. YouTube isn’t particularly unique in that regard.
Even the old pre-tvOS Apple TV apps were kinda web apps - XML and JavaScript delivered over HTTP
I do agree TV apps are mostly web apps, but most of them did not run in a browser that was specifically designed for that single app.
Google tried a browser that only supported <div> and limited CSS for embedded purposes and it went nowhere
That just means that specific subset of features wasn't lucky enough to make it compelling at that particular point in time for the markets it meant to address.
Change any of those variables and you may have a winning proposition.
The various web specifications are insanely complex (e.g. navigables) so I can see how people burn out from it. To add onto that, a browser operates in an extremely hostile space security wise; to be a serious competitor, you'll need to be on top of your game in that regard which maybe Rust will help with.
Something very silly has happened, where the thing that most non-technical people have which is most exposed to hackers is also incredibly complex and requires high performance for some reason.
Because the complexity and functionality of the modern (whatever the fuck this means) browser basically approaches one of the OS with all the consequences.
Yeah it's a real shame. The complex (and ever expanding) nature of the web is the real thing entrenching incumbents like Google. They have the existing codebase and resources to handle the complexity.
Yeah. I still hope at some stage we build something much simpler that maintains the same security boundary.
Like an application platform (forget documents) built entirely on wasm, and with capability based security. That would let you launch apps made within the platform just as easily as you currently open a website.
The platform would need some primitives for rendering, UI, accessibility and input handling. But hopefully a lot of those APIs could be much lower level than the web provides today. Move all the high level abstractions into library code that developers link into their wasm bundles. (For example, I’m thinking about most of what css does today.)
That would allow much faster innovation in layout engines and other things the web does today, and a smaller api surface area should lead to better security.
It’s quite possible to build something like this today. It’s just a lot of work.
Maybe when chatgpt is a bit smarter, it might be able to do the lion’s share of the work to make this happen.
>"Like an application platform (forget documents) built entirely on wasm, and with capability based security. That would let you launch apps made within the platform just as easily as you currently open a website."
In the end you will end up with the platform / OS which will lose to competitors because of performance and lack of features and do not expect it to be secure. Developers will manage to leave some holes and hackers will find their way.
Disagree. The web wouldn't be anywhere near as successful if you needed to trust & "install" websites before you could visit them. How does that work? Why don't you need to install / trust a website to use it? Well, because it has this kind of security model. Websites are sandboxed.
The web's sandboxed security model makes it better for users. And that in turn drives popularity.
I think the same could be true for a good application platform. The trick is using the sandboxing + capability based security model to enable "new" usability features that traditional applications can never deliver.
Sandboxing has to be the funniest bit of wordplay anyone has ever made in tech. Sand is, of course, notoriously impossible to contain and never stays in the box. And it is not nearly as clever as an attacker!
The term doesn't come from the idea of containing sand.
It comes from things built for children to play in that have an edge with contents inside it. You play "in a sandbox" without having to deal with anything outside of the sandbox.
The sand in a children's sandbox spills over and gets everywhere. The children playing inside it .. they don't have to care. They are playing inside the sandbox, and for now, the world outside it is not relevant.
> You play "in a sandbox" without having to deal with anything outside of the sandbox
I mean, besides "gifts" from the neighbourhood cats. How do they fit into the metaphor?
Hah true!
My girlfriend has strong opinions about how we use the word "library" to describe a software package.
Surely the metaphor should be that one package is a "book" and the entire package repository is the library, right? Left pad is an entire library? Huh?
And then we have no collective noun for collections of libraries!
So then a function or subroutine or whatever could be a chapter? I’d be down for that I think.
Honestly, I view projects like this as more of an intellectual curiosity than anything which seeks to become useful .
The Firefox engine is great if you don't want something controlled by Google. And it's going to be much easier to develop plugins or extensions for that versus trying to write your own browser from scratch, which to be honest will probably cost hundreds of millions of dollars. If not more.
I do imagine tools like this being useful for something like web scraping, but it's never going to be an end user product.
> more of an intellectual curiosity than anything which seeks to become useful
I am reminded of this:
“I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.”
– Linus Torvalds, announcing the software that became what we now know as Linux
One can only hope we can get a browser the same way we got Linux, but as RMS was fond of pointing out, Linux’s success had a lot to do with the existence of a full suite of GNU software that could run on top of a new kernel. If only we had something like GNU with browser engines, I’d be more optimistic about the chances for success of many new entrants.
> Linux’s success had a lot to do with the existence of a full suite of GNU software that could run on top of a new kernel
I've heard this a number of times; but circa 1991 I'm not convinced. The critical GNU components to scaffold Linux adoption were:
- GCC + C runtime
- A shell (plus a bunch of small utilities)
You could make a reasonable argument that Linux was and remains a much bigger achievement, namely because GNU has never actually managed to make a usable kernel (Hurd still has no USB support, for example. I don't know if this is for technical or political reasons). On the flip side, there were plenty of compilers and shells kicking around that Linux could have bundled.
RMS makes all sorts of wild claims about how much of a distro is "GNU software" (a criterion that is never clearly defined - is any non-kernel GPL software part of GNU?) by comparing lines of code; but at the time of these claims distros tended to bundle anything and everything that you might possibly want.
Contemporaneously to all this, 386BSD had created a full freely-distributable Unix with no GNU code; and its descendants might have captured the mindshare were it not for an extended copyright battle from AT&T.
A browser written in HTML on top of a rendering engine?
Mozilla had one a while ago: https://github.com/browserhtml/browserhtml . I'm sure it could be updated.
Or khtml which became the basis of WebKit and later Blink.
He ended up only writing the kernel though.
For web scraping at scale you want to get lost in the crowd. This usually means being (or pretending to be) chromium on windows. Unusual browsers are suspicious, detected or have very distinct fingerprint.
Indeed. I heard about a browser called Zen a couple weeks ago and installed it. Just took it for a drive yesterday, and by the end of the day, Reddit had blocked me just based on my sporadic, normal use of the site for about two hours here and there while I did other things.
I switched back to Safari and it worked normal immediately.
I applaud the project espoused spirit, because, similarly to the author(s)' webpage, i don't think we should have a monopoly in this space ( especially given recent moves by Google ).
Small things to be noted ( in the small, but noticeable category):
- repeated paragraph ( https://gosub.io/learn-more/ )from 'Gosub started' to 'open and free' - that is it for now:D.. I will be personally watching it with some interest
edit: some grammar
I think I fixed this a while ago, but we didn't update the website deployment
I was hoping for a small embeddable engine to finally replace Electron. The build on Windows ends up being 55MB, not too bad but still too large for simple apps.
Is anyone working on something like that?
Yes, we're working on that over at https://github.com/DioxusLabs/blitz (alpha release imminent). Our TodoMVC example is current ~20mb with a standard release builds, but comes down to 7.2mb with some compiler flags like -Oz and LTO enabled (these numbers of from macOS).
And we plan to allow fine grained configuration of the feature set, so if you don't need certain image formats or layout algorithms or networking support, then you can disable them and save on binary size.
Ohhhh...this is so awesome. Fits the most common app usecase for plain HTML+CSS rendering library and not a humongous browser for developing offline apps and its terrific that something like blitz exists.
blitz is cool piece of tech but it seems that it needs dioxus framework to do any sort of interactivity which in turn needs to be written in rust. Which is a lot slower than writing a electron app.
Well, the application is basically unoptimized. However, we also don't have many components yet that can eat up your memory. But we try to keep the memory usage as low as possible. We also thought about integrating it into something like Electron, and for something like that it is important to have a low memory usage.
Lateron, we might have some compile time flags to reduce memory usage in cost of a bit of speed. Most Electron apps don't require that big oomf performance on the startup, since everything is locally and can be cached in a better way.
The smallest app built with Tauri is 500 KB.
[1]: https://tauri.app [2]: https://syntax.fm/show/821/is-tauri-the-electron-killer/tran...
There is Sciter: https://gitlab.com/sciter-engine/sciter-js-sdk
That's now one of the goal of Servo. Also, did you look at Tauri?
Servo and Tauri still let the Application use JavaScript, which is just very wasteful. I was thinking about making it possible to write dynamic websites completely without JavaScript, by building up WASM support and making that even faster. But that's a not the goal for now. Indeed, we don't even have a JS API for websites yet...
I'm always disappointed when conversations here are full of "why don't you just contribute to <other project> instead?" Have you never simply desired to do something yourself?
Right? I don't think HN needs more obligatory "this is a big undertaking and likely to fail" comments. We can take those as implied. We should 1) engage more meaningfully with the project and 2) keep in mind that negativity hurts a lot more than positivity helps. If you're not up to the task, fine, and maybe they aren't either, but don't drag them down before they've tried.
I suspect people who post these whys haven't actually tried that.
Contributor: Hey, can we add this? Maintainer: No.
Yes I have. But not this.
> We’re looking for developers with or without experience in Rust. You just need to be interested in browser technologies.
Well, both that and the ability to work on a project that requires you to run a toolchain whose minimum barrier to entry wrt resource use and developer experience makes the C++ ecosystem that preceded it seem lean and inclusive.
Would a fork of Chromium that was restricted to MISRA-C/C++ offer any real security advantages?
Would parts of Chromium be fundamentally incompatible with these standards?
https://en.wikipedia.org/wiki/MISRA_C
Sounds very hard. For example, Rule 21.3 in MISRA C 2012 basically prohibits dynamic memory allocation (e.g. malloc, calloc, realloc, free). Implementing a browser with such restrictions would be quite misrable.
I would think the MISRA rules against dynamic memory allocation would present serious difficulty if not fundamental incompatibility when trying to implement web standards.
It is against the rules to call malloc, yes.
However, it is not against the rules to launch another process with a static amount of declared memory, then access it over shmat().
This is cheating, but could it be safer?
No.
I'm confused. Why do you name it “go”-something when it is not implemented in Go... I have a more catchy name for you, Rub, which stands for route to unlimited browsing.
"GOSUB" is the syntax used to call subroutines (functions) in BASIC:
http://retro-basic.com/manual/GOSUB.html
Thanks for the pointer. And it makes it doubly confusing. Doesn't a reference to an obsolete, pre-modern language tarnish the reputation of Rust? Doesn't the creator of this project fear lawsuits from the legal team at The Basic Foundation?
1. No, unless you actively disable your brain's pleasure center
2. No, because GOSUB (the Basic keyword) is not a trademarked term owned by The Basic Foundation
> unless you actively disable your brain's pleasure center
Wait, you can toggle that thing on and off? I knew I've been doing something wrong!
Oh no! Don't tarnish the rust!
> obsolete, pre-modern language
but enough about Visual Basic (which still has gosub)
Then they'd have to use Ruby
There is always room for the go version as GoSub-go /s
I would recommend to focus on a niche like browser automation/QA with puppeter specially after they released the webdriver bidi[0]. There is a market for this kind of product if it's lighter/faster than chrome.
[0] https://developer.chrome.com/blog/webdriver-bidi
> there is a market
OP is not trying to find a market.
> having a diverse landscape of engines is the only way to defeat a monoculture
A project like this should be under GPL
Why does it matter if it’s written in Rust?
Rust gives you the performance of C++ if not better sometimes, with code that won't go haywire at the 11th hour. There is value in that, particularly in an application that's sole purpose is to load arbitrary stuff from the internet.
Also if it was written in anything else, it probably wouldn't get the coverage it gets ;)
Rust was invented to make it easier to write a secure, performant browser engine
It's funny; I wish Rust was better suited for bare metal than it is now. But no matter how much people perceive Rust as a bare metal language like C, it was quite literally made for a level or two above that, in browser engines.
(Here's to hoping Rust for Linux continues to drive progress for bare metal Rust!)
Projects written in Rust tend to be very fast - as fast as C++ or C code - but without the endless security issues.
You may as well ask "why does it matter if this bridge is made of iron".
There are long lasting bridges made of stone, concrete and in the right climates, even wood. Not to mention rope when it suits the purpose.
Each material has its own qualities, which means its own pros and cons in a given context.
This naive belief that there will be one language to rule them all (and is name is <fill-in-the-blank> ignores history and the world outside of programming in a rather silly way.
> There are long lasting bridges made of stone, concrete and in the right climates, even wood. Not to mention rope when it suits the purpose.
I'd be fine with someone building a new browser out of stone, concrete, wood, or even rope.
Just don't build it out of C/C++ because those languages aren't memory safe.
Rust is a risk-reduction strategy. It is not a risk-elimination strategy.
There are risk-reduction strategies one can follow with C++, which offer some fraction of the reduction that Rust does (opinions vary on the value of the fraction). Rust enforces risk-reduction strategies, which in some contexts may be of value all by itself.
Language choice does not eliminate risks in software.
> opinions vary on the value of the fraction
They don't really. It's been shown by many studies that 2/3 of security bugs are memory safety errors. That's the minimum that Rust can eliminate.
It actually should eliminate more because it also has the strong type system and tree-ownership style that help reduce the chance of logic bugs unrelated to memory safety too (similar to Haskell and other very strongly typed languages).
This is probably the biggest data set:
https://security.googleblog.com/2024/09/eliminating-memory-s...
Unfortunately they don't break out non-memory safety vulnerabilities, but they've almost eliminated memory safety vulnerabilities by writing new code in Rust.
Nobody is saying that. But to continue your analogy, do you not think that in a world where all the bridges are made of wood it would be notable to say that a new bridge is made of steel?
Of course there are impressive projects made with C. But we generally don't build large bridges out of wood anymore do we.
> do you not think that in a world where all the bridges are made of wood it would be notable to say that a new bridge is made of steel?
Notable, sure. But it could turn out to be Tacoma Narrows bridge.
We never did build large bridges out of wood, I think. For the right context, wood is still a preferred material for some bridges.
> We never did build large bridges out of wood, I think.
Yes we did. They just haven't survived. For example London Bridge was "various wooden bridges, AD 50 – 1176".
I guess "large" has a bit of wiggle room built in.
Try your best to ignore the rewrite-it-in-Rust people. They're just plain wrong for that. But yes, for a niche like browser engines, Rust is pretty darn well suited.
1) I suspect that it's important for potential contributors to know what language it's written in.
2) It mattered enough for you to complain about it for some reason, so look at that reason, then look at its reflection.
Huh, Complain??
A few thing from the top of my head:
- Might be interesting to integretors (FFI, dylib, Rust projects)
- Signals some characters: that it's probably safer than alternatives written in non memory safe languages in same class, has good performance
- Might attract contributors (ie I'm sure there's an intersection of people passionate abou the web and Rust)
- This is hacker news, so it might earn a few extra +1s :P
Edit: formatting
Since this compiles to web assembly and is modular I wonder if this will use the wasm component model in the future.
It would be interesting to be able to use pieces of this from other languages.
I highly doubt that. At least not in a native way. However, you could make an adapter from the native interface to wasm components. Would be interesting to look into!
Should have been written in BASIC.
Former Mozilla employee here.
The fact that they are writing their own bytestream abstraction does not bode well.
That said, I hope they succeed at shipping something, even if it’s not competitive with Chrome.
My previous thoughts on the topic: Why you can’t build a web browser and why you should anyway.
https://joshondesign.com/2022/12/14/browser_1000_loc
The byte stream is one of the first components that was written. Probably It wouldn't be written nowadays. The browser is quite modular, so in the end you can completely out out of that system.
That’s good to hear. I’m excited to see you’ve got a good html parser. That’s worth a lot just by itself.
Yes, the HTML parser, probably the component that is the most spec compliant. I think the CSS parser also is. For the initial phase, I think it is more important to get something working. For a later implementation, the spec should dictate what we do and what not. But with a small team, it is just not feasible.
Isn't one of the difficultlies of writing a browser that your parser must accept lots of invalid inputs and render it like other browsers would?
HTML5 parsing is relatively easy, because behavior for tag soup is 100% specified. That is, in theory, all conformant HTML5 parsers should output the same DOM for any arbitrary byte sequence.
Layout is much harder because the CSS spec is full of UB, so you will have to do some reverse engineering there.
> The fact that they are writing their own bytestream abstraction does not bode well.
You want to elaborate on why exactly? Seems like a kind of shallow dismissal, but then I'm no browser engine developer exactly, maybe it's obvious.
You can only do so much, so success depends on which components you decide to reuse. I wouldn’t build a new database or filesystem abstraction from scratch, for example.
Rust has lots of bytestream abstractions already with a ton of work put into them. Maybe they have a valid reason for going their own way. I’d like to know.
There are people who write their own hash tables, and there are those who just use a library. What may seem like a bad idea to some is trivial to others. Hacker culture is way more fun when you are allowed to use recursion [1].
[1] https://www.reddit.com/r/cscareerquestions/comments/ntvtzq/c...
For those wondering which blogpost i referred to: https://news.ycombinator.com/item?id=41835040
It looks like, this is the wrong link. I think you meant https://news.ycombinator.com/item?id=37608580
0 days since the last browser engine