I wonder: who could even feasibly introduce another browser today? The task seems almost impossible.
Facebook already has far more cash and profit than they know what to do with. $38 billion currently, rapidly climbing. They'll add ~$20 billion to that in 2018. They could do a new browser just for kicks if they wanted to, and they have the vast global reach to generate some uptake.
Whether either could claw meaningful share away from Chrome is an entirely different question.
Samsung, Tencent and Alibaba all have the resources to launch entirely new browsers if it made sense.
- uc mobile on Android now uses the blink engine, it used to use Webkit. - uc mini ( I think that's the name) has server renderer but it's "uc engine" is a derivative of gecko (not checked recently)
The bottleneck is engineers who have the know how to build it.
Building your own browser could be a shitty business decision if you can't compete with Chrome for ad dollars.
A browser makes sense if you can bundle it with an OS.
Android : chrome, ios: safari and Windows: Edge
Facebook makes a shit ton of money from ads people click on chrome.
Quite similar to Chrome, but has support for ad blockers etc.
But yeah, from scratch is hard... Google didn't even do that, they started from webkit.
Also, I would try to make it as modular as possible. E.g. layout engine, css engine, js engine etc. as libraries, use the system codecs instead of bundling own codecs, and so on.
And it would help to have an extensive test suite, which you could take from other browsers.
The only way to ship a browser that doesn't render "web apps" would be to simply not support scripting of any kind. That would permanently break much of the web unless you offered a way to opt in to scripting the way current browser users who run script blockers can. But then you just have a regular browser with script blocking turned on by default.
Having different engines for "static" and "web app" documents, and defining a proprietary standard for the former as a restrictive subset of HTML would be unnecessarily complex and hostile to web developers.
You could autodetect a "lean html" site, or you could use a marker such as "<html lean>" like AMP does.
I don't think this is hostile to developers at all, unless AMP is already hostile. You would have a subset of the web platform, yes, but if you only use that you are likely to have a faster and leaner website - even without a new engine. I would view it as a guideline or a best practice, rather than a restiction.
Side note: I think the co-mingling of documents and apps is the source of a lot of problems today. Why can ads inject arbitrary javascript into my website?! On mobile, I am regularly redirected to annoying ads that proclaim my phone is infected, and make my phone vibrate and make noise. A news article shouldn't be able to do that!
That's a restriction. If site authors have to abide by that or else not have their content render in your browser, you're restricting their freedom to publish the content they want or make their own decisions about what code they choose to write.
But if you still have a "backup engine" that will run it anyway, then what's the point?
>I don't think this is hostile to developers at all, unless AMP is already hostile.
I would think Chrome was hostile if it gave preference to AMP over standard HTML. Those aren't decisions that browsers should make.
>Why can ads inject arbitrary javascript into my website?!
Because that's what the site authors decided to publish. Like it or not, that's the way the web is intended to work - you request a URL, you get back whatever the server decides that URL points to. Changing that dynamic would change the web at a fundamental level.
I further think, if you sell it right, you could get people running sites like blogs, documentation, wikis, to opt in to "strict" or "lite" or "document" mode, but that is an orthogonal issue.
> Because that's what the site authors decided to publish. Like it or not, that's the way the web is intended to work
I'd argue that the web wasn't intended to involve executing code, but rather it was originally envisioned to be a means of viewing documents.
That's fair - but it doesn't imply that it was intended to not execute code, so much as that it wasn't feasible to consider at the time. The web wasn't originally intended to display images either, but it evolved over time. Certainly, in either case, javascript was never intended to carry the burdens it's been made to, but people found it useful to have a Turing capable language as part of the web, and here we are for better or worse.
And the web in the near future when WebAssembly takes off is going to execute binaries compiled from arbitrary languages, of which javascript will be only one option. That's going to be awesome in both senses of the word. Not what the web was originally intended for, and certainly not the best of all possible worlds, but I would argue that it's still better than static documents alone, in terms of the possibilities it provides to publishers and users.
And maybe the pendulum will swing the other way at some point. Maybe people will choose to write lighter pages and not use unnecessary code. But if they don't, that's still their choice to make, not yours or a browsers to make on their behalf. And unlike with C, C++, Java, etc, you can turn javascript off if you want and still use some of the web.
I think the prevailing opinion on Hacker News is exactly that.
An extremely light and content-focused spec like Gopher would exclude a lot of websites that we would consider light. Terms used to describe light subsets of web capabilities, like “DHTML,” do not appear to be well defined.
My initial attempt would be to exclude XHR/fetch, dynamic URL/history manipulation (window.history), and loading resources from other domains. But the latter would probably exclude things I don’t oppose (like CDNs) and things I don’t necessarily support but which would surely drastically impede adoption (like third party ads/analytics services).
Can you propose a better and more viable spec?
If at the same time you could encourage widespread adoption of your HTML subset, then you may be onto something. This is essentially what Google did with AMP, their incentive being their caching network and apparent favoring in search results.