You want Gimp for Windows running in Firefox for Linux running in Chrome for Mac? Yeah sure.
[0] https://www.destroyallsoftware.com/talks/the-birth-and-death...
Too bad makers of the original Minesweeper did not think to build touch input support.
I actually do. I want all code ever written and every environment it was ever written for to have a URL that will let me run it in the browser. Everyone else seems to want the web to go back to being whitepapers but I want actual cyberspace already!
We haven't had a new browser engine written from scratch since KHTML. Firefox is a descendant of Netscape, Chrome (and Safari) is a descendant of WebKit which is itself a descendant of KHTML, Edge is closed source, but I'm almost sure there's some old IE code in there.
Why?
It's simply too expensive to create a fast (and compatible) JS engine.
If WebAssembly takes off, I hope that one we'll have more than three browser engines around.
Check out the size of the latest edition of the book "CSS: The Definitive Guide":
https://twitter.com/meyerweb/status/929097712754098181
Until CSS is replaced by a sane layout system, there's not going to be another web browser engine created by an independent party.
Implementing an open standard shouldn't be like this. Even proprietary formats like PDF are much simpler to implement than CSS.
You could probably say the same thing about any complex open standard, like FTP etc.
'Open standard' has nothing about something being simple and straight forward. What CSS is trying to do is complicated because of a whole bunch of pragmatic reasons.
Last time a browser tried to 'move things forward', ngate aptly summed it up as
Google breaks shit instead of doing anything right, as usual.
Hackernews is instantly pissed off that it is even possible to
question their heroes, and calls for the public execution of
anyone who second-guesses the Chrome teamAt least some of the JS engines are used in non-browser projects (V8 and Microsofts), which at least superficially would suggest you could write a new browser engine and tie it to one of those existing JS interpreters. WebAssembly will gain interfaces to the DOM as well, so the complexity of that interaction will remain.
EdgeHTML is a fork of Trident, so yes. That said, I'm led to believe there's about as much commonality there as there is between KHTML and Blink: they've moved quite a long way away from where they were.
> It's simply too expensive to create a fast (and compatible) JS engine.
I don't think that's so clear cut: Carakan, albeit now years out of date, was ultimately done by a relatively small team (~6 people) in 18 months. Writing a new JS VM from scratch is doable, and I don't think that the bar has gone up that significantly in the past seven years.
It's the rest of the browser that's the hard part. We can point at Servo and say it's possible for a comparatively small team (v. other browser projects) to write most of this stuff (and break a lot of new ground doing so), but they still aren't there with feature-parity to major browsers.
That said, browsers have rewritten major components multiple times: Netscape/Mozilla most obviously with NGLayout; Blink having their layout rewrite underway, (confusingly, accidentally) called LayoutNG; IE having had major layout rewrites in multiple releases (IE8, IE9, the original Edge release, IIRC).
Notably, though, nobody's tried to rewrite their DOM implementation wholesale, partly because the pay off is much smaller and partly because there's a lot of fairly boring uninteresting code there.
Depending on your definition of "wholesale", the Edge team claims it took them 3 years to do exactly that:
https://blogs.windows.com/msedgedev/2017/04/19/modernizing-d...
In my opinion, the issue is the DOM. It's API is massive, there is decades of cruft and backwards compatibility to worry about, and it's codebase is significantly larger in all major open source browsers out there.
HTML is far larger than the DOM. Like comparing an ant to Jupiter.
Asking WebASM to be everything, including a rendering engine, is asking for problems at such an atrocious level.
There's a lot of "legacy" there, a lot of stuff that probably should be removed, or at least relegated to a "deprecated" status.
If an API makes it easy to make mistakes it's a bad API. Blaming "people" is a cop-out.
If people are misusing the DOM API at a fundamental level(to do non-DOM related things), that's not a fault of the API. It's as if everyone has forgotten that DOM means Document Object Model. The vast majority of websites and web apps are not very complicated on the client-side, so I'd say that the DOM API generally does its job well. Trying to do anything that's not about constructing a document or is doing heavy amounts of animation or node replacement using a document-building API is asking for a bad time. It's quite implicitly attempting to break fundamentals of computer science.
Making the API one uses to render pages in a browser a free-for-all doesn't solve the problem, and you end up losing many of the advantages of having actual standards. What would be better is for the browser to provide another set of APIs for things beyond the "expertise" of the DOM. This kind of the case right now in some regards, but there's a reason why React and Glimmer use things like virtual DOMs and compiled VMs. I'd argue that a standardization of such approaches could be a different API that probably shouldn't even be referred to as a DOM because they are meant to take a lot of shortcuts that aren't required when you are simply building a document. In a sense, WASM is intended to fulfill this purpose without replacing the DOM or JavaScript.
Object-oriented programming is quite often misued/misunderstood. Does that mean it's a "bad" concept? I wouldn't say so. Education tends to suck, and people are generally lazy and thus demand too much from the tools they use.
I'm not copping-out because I'm not putting the DOM on a pedestal. Calling it a bad API because it doesn't work well for a small minority of cases is a total mischaracterization. If it was an objectively bad API, it wouldn't have seen the astounding success it has.
EDIT: I'm not saying that programmers are stupid... but that their expectations are sometimes not congruent with reality.
WebAssembly is a replacement for Flash, Silverlight, and Java Applets.
They are adding native DOM access, which changes things.
It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access, even though it's planned[1]. There are even VDOMs[2] for WASM already. Future WASM implementations that include DOM access can absolutely, and for many folks will, replace Javascript.
[1]: https://github.com/WebAssembly/design/blob/master/FAQ.md
I am not going to say never. It does not now and will not for the foreseeable future though. I know DOM interop is a popular request, but nobody has started working on it and it isn't a priority.
Part of the problem in implementing DOM access to a unrestricted bytecode format is security. Nobody wants to relax security so that people who are JavaScript challenged can feel less insecure.
How would a browser know to restrict a web server compiled into bytecode specifically to violate same origin? The browser only knowns to restrict this from JavaScript because such capabilities are allowed only from APIs the browser provides to JavaScript.
I linked to the latest proposal downthread; people are absolutely working on this.
That's an arbitrary distinction that's driven by developer group politics, not a meaningful technical distinction. (Much like the old Rubyist, "It's an interpreter, not a VM.")
Machine languages were originally intended to be used by human beings, as were punch cards and assembly language. There's no reason why a person couldn't program in bytecode. In fact, to implement certain kinds of language runtime, you basically have to do something close to this. Also, writing Forth is kinda close to directly writing in Smalltalk bytecode. History also shows us that what the language was intended for is also pretty meaningless. x86, like a lot of CISC ISAs, was originally designed to be used by human beings. SGML/XML was intended to be human readable, and many would debate that it succeeded.
Not at all. JavaScript is a textual language defined by a specification. Modern JavaScript does have a bytecode, but it is completely proprietary to the respective JIT compiler interpreting the code and utterly unrelated to the language's specification.
> There's no reason why a person couldn't program in bytecode.
True, but that isn't this discussion.
That is this discussion, because the fact that people program directly in JavaScript does not prevent it from being in the same class of things as a bytecode.
Does it even matter when most people are using it as a compiler target (even just from newer versions of the language)?
Servo is not meant to be a real browser. That's not a bad thing, but I don't think you can use it as an example of a browser built quickly by a small team.
Edit: Looking at the project it seems like it uses SpiderMonkey, but is otherwise new code
And while yes, Mozilla's Spidermonkey comes from the Netscape days, and Chakra in Edge descends from JScript in IE, plus aforementioned JavaScriptCore, each of those engines still evolved massively: most went from interpreted to LLVM-backed JITs over the years. I suspect that no more than interface bindings remain unchanged from their origins, if even. ;-)
(1) I can't currently find the primary sources from when Chrome released on my phone, but here's a contemporary secondary one: https://www.ft.com/content/03775904-177c-11de-8c9d-0000779fd...)
[1] Such as V8, Chakra, JavaScriptCore, SpiderMonkey, Rhino, Nashorn, there is a variety to choose from, also experimental models such as Tamarin, they are almost certainly not the critical blocker for developing a browser.
Netscape navigator on DOS in Firefox via WebAssembly.
I think it's a great idea, though many disagree. It's basically ChromeOS but to the next level.
It died pretty unceremoniously though.