1. Anymore I like to encourage people to stick with their default browsers (except ofcourse on elementary). That provides the most competition now.
2. It's actually quite easy to implement a functional browser, just embed WebKit, Chromium, or Gecko. What's difficult is adding all the features to make it good.
@Shamar @bob The concept I've heard suggested and quite like is that all HTTP requests should only ever be made onload or in response to informed and explicit user interaction. Basically AJAX should be nothing more than fancier links, rather than a full programming language.
And maybe there'd be a limited ability to move some of this processing client side. As long as that doesn't become remote code execution.
I'm saying I don't think we need Remote Code Execution as a Service. Fancier links can account for most Ajax. Fancier CSS can account for most interactive controls.
We should see how far that takes us, what else we need to preserve the best of the Web post-JS, and how we can design permission prompts to tie into human laziness.
IOW, we should think of the simplest tool which can be used to do most of the good stuff that requires JS right now, but is easier to implement, reason about, and sandbox, than JS.
If you've ever played Minecraft , you may've noticed, that many updates introduce only one new item, with fairly simple mechanics. However, that item, combined with all the items existing before, has so many uses, that it replaces 10s of items from different mods.
I think we need something like this.
>all interaction between the user and the network should happen out of conscious decisions of the users.
Oh, I overlooked this one.
Yeah, sounds like an interesting axiom.
Which gives me another idea:
maybe we need a more axiomatic approach?
Maybe we should first define a good (small but sufficient) set of axioms that the Web should satisfy, with a strong and well-described justification for each of them.
My thoughts are strongest at this highlevel, so I'll write them down now and seek your feedback and additions.
Don't get me wrong, I totally believe in your principle of locality. I just think it'd be good to iron out how it would relate to these standards. And I'm trying to figure out how it gels with avoiding clientside Turing-completeness.
@Wolf480pl @Shamar @bob As for my security principles, it suggests that there'd need to be some sort of communication that this is an infinite scrolling element before any scrolling happens. This would be easier on some devices than others.
As for maintaining the useful geoposition feature for map sites (and a few others), I'd argue it's best to move the activation into the browser chrome. That way users can be confident in what it does and a separate confirmation is unnecessary.
This comment made me realize that such a new browser, one that adds support for another client-side language, could work as a bridge from the current “web-as-application-platform” architecture (which I think is a mistake) to something better.
Sorry for the lack of context here, this just might solve a large problem I’ve been noodling on for a long time...🤔
I really think it would! Because
1) The standards require the HTML parser to be paused whilst each <script> element is being executed.
2) The DOM standards define potentially the slowest possible AST for HTML to construct.
This is commonly used to build custom layouts atop the browsers which can be useful for communication. But to be efficient any standard for that should be applied during or after CSS layout.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!