51–60 of 79 posts
Around a billion.
1% would mean 10 million websites are using each possible feature. Okay, it's not quite that even, and a lot of popular sites (like many news sites) stick to the most basic features, but all these browser features are there for the other various cases. Like aforementioned web apps. Various tech demos. Sites with very specific use cases.
In other words, it's because the internet is massive and varied.
There are web sites, and there are web apps. Most websites, think news sites, Wikipedia, etc.. just deliver static content and a whole bunch of ads, as someone noted here. Web applications are the ones that need all this functionality. Why don't we do the following for HTML6, and introduce one profile for sites, and one for apps. - Sites: HTML + CSS, Javascript if at all only for presentation purposes (like DHTML ove…
this was very interesting: "SVG, for example, has a problem however you look at it: on one hand more than 15 per cent of the sites use it, on the other hand, nearly 87 per cent of blockers block it, but it's had 14 security warnings (CVEs, Common Vulnerabilities and Exposures) in the last three years."
I am deeply suspicious of that number. I've never encountered a plugin or anything of the sort that provides for "blocking SVG", and it's fully supported in all recent browsers.
There are web sites, and there are web apps. Most websites, think news sites, Wikipedia, etc.. just deliver static content and a whole bunch of ads, as someone noted here. Web applications are the ones that need all this functionality. Why don't we do the following for HTML6, and introduce one profile for sites, and one for apps. - Sites: HTML + CSS, Javascript if at all only for presentation purposes (like DHTML ove…
Like Lynx?
In terms of sites versus apps, I think the browser vendors are responsible for making this happen. Adobe AIR was the closest effort I saw of marrying web technologies with apps.
Sadly AIR never took off and whilst I appreciate the intention, it left a huge looming question of what do we actually do with all this new web technology?.
One answer I came up with in recent years was what you suggested: of partitioning off the people who want to work with the technologies and keep them separate from the text+image+CSS based web we've all grown to love.
Similar to how the demo-scene was an offshoot of game development...
There are web sites, and there are web apps. Most websites, think news sites, Wikipedia, etc.. just deliver static content and a whole bunch of ads, as someone noted here. Web applications are the ones that need all this functionality. Why don't we do the following for HTML6, and introduce one profile for sites, and one for apps. - Sites: HTML + CSS, Javascript if at all only for presentation purposes (like DHTML ove…
One problem is that some interactive news articles can make very impressive use of WebGL, like the interactive climbing map that accompanied an article about the Dawn Wall freeclimbing record: http://www.nytimes.com/interactive/2015/01/09/sports/the-daw...
99% of the world doesn't use Calculus. Maybe we should stop teaching it in school.
Lame article.
Earlier quoted context omitted.
Sure, but presumably a browser and the codebase has to support all of the apis and the entire specification. Would it not be able to optimize a browser if say, as the article claims, olnly ~17% of the features/apis need to be supported? Or would this totally not matter.
There is no way to be certain without digging in to the particular code in question. But "optimization" isn't just some magic pixie dust that you sprinkle on to a project and it makes things faster. Some things can't be optimized because they are already optimal. Some things shouldn't be "optimized" (e.g. for speed) because it would make the code less optimal (e.g. for understanding, maintaining, etc.). The number of…
Correct, however periodically adding features by committee and backwardly processing and parsing tags and internal api implementations that are unused certainly must hamper performance. To some extent, I would assume the v8 or chakraCore engines are developed around interpreting javascript which includes languages pieces that have developed because of its close ties with the dom. So between the underlying interpreter engines, and all of the parse tooling for dom rendering and tag identification and css applications, I can only assume if it had 80% less overhead to expect, it could be faster.
So to the point > The number of APIs available should be orthogonal to the issue of system performance. If it is not in particular cases, it's via bad overall system design, not the existence of the API in general.
That was the question I was asking.
1) is it possible to design a better system with many less considerations.
2) is it a bad overall design?
Again, I have to assume that if we raieded the codebase and rewrote it minus 80% of the legacy shit, we could do a better job, but maybe not.
There are web sites, and there are web apps. Most websites, think news sites, Wikipedia, etc.. just deliver static content and a whole bunch of ads, as someone noted here. Web applications are the ones that need all this functionality. Why don't we do the following for HTML6, and introduce one profile for sites, and one for apps. - Sites: HTML + CSS, Javascript if at all only for presentation purposes (like DHTML ove…
So we're mostly lacking the site-only aspect. To some extent that can be achieved with addons that strip or block certain APIs.
There are web sites, and there are web apps. Most websites, think news sites, Wikipedia, etc.. just deliver static content and a whole bunch of ads, as someone noted here. Web applications are the ones that need all this functionality. Why don't we do the following for HTML6, and introduce one profile for sites, and one for apps. - Sites: HTML + CSS, Javascript if at all only for presentation purposes (like DHTML ove…
Whichever side you're on, browser vs. native, the sheer frequency of this discussion proves that at least a clear distinction IS needed. Continuing the status quo of web/browser/standards bloat cannot be good.
Somebody really needs to set down some global rules of thumb. I think that when your webpage starts needing sidebars and subwindows and popups and notifications (yes, looking at you, Facebook) then at that point it should just be a native app.
Let the web and its browsers focus on "sites" and "pages" and let the OS do "apps." After that it's up to the operating systems to make discovering and accessing apps as easy as typing in a website's address.
As a user, I want to sign in just once on each of my devices (iCloud/Apple ID lets me do that), and just type in an app's name (say Cmd+Space and "facebook") and then start using it right away as the OS begins downloading it incrementally, just as a browser does a website, except with full access to the OS's features, efficient use of my hardware and battery, and instant access to all my data without a separate login.
[1] https://news.ycombinator.com/item?id=11735770
Earlier quoted context omitted.
Brave software. This was created by Brendan Eich the x ceo of mozilla. Eich does seem to have some problems with equality[0] which may have contributed to his ouster at Mozilla, but Brave is a top shelf browser. Super great team, pretty security conscious and given the Eich developed JS, well, they have a pretty good working knowledge of it. Brian Bondy is a super awesome guy (thanks for adding duckduckgo BTW), Yan Z…
The ultimate goal for Brave (I don't know if it's doing this yet) is to replace blocked ads with ones sold by the Brave company. I cannot support this.