331–340 of 412 posts
Earlier quoted context omitted.
Yes, and Firefox is the 3rd of 4th most used browser at less than 10% (which is bad). So the subset of actual Firefox users that use NoScript is absolutely not worth supporting.
Sure, but we're not talking extreme niche here or anything. It was downloaded by over two million users.
Earlier quoted context omitted.
Do you realize JavaScript is a prototype based programming language? It is a major and very useful feature of the language. There's no reason not to use it. There are some things to be careful about with interop if you need it, but that's it.
We've already learned from our past mistakes changing the prototype of the standard library - the Ruby community learned the same thing with monkey patching their standard lib too. The maintenance overhead far outweighs any immediate benefits.
Also, to be clear, I'm suggesting adding new methods to DOM object prototypes, not changing behavior of existing methods.
"An engineer is someone who can do with ten schillings what any fool could do with a pound."
By this definition one could argue Javascript developers are not engineers.
If the user can get the desired data from a website without having to run 4.5M of js in a large browser, but the developer "needs" 4.5M of js and a team of people to deliver the data, then who is the "engineer"?
Earlier quoted context omitted.
Dunno how well it will work after Mozilla drops support for XUL extensions...
NoScript definitely works without XUL support and is the fourth most popular extension listed on the compatibility page here: https://www.arewee10syet.com/ Tested and working, for a while now.
There is a famed quote that goes something like this: "An engineer is someone who can do with ten schillings what any fool could do with a pound." By this definition one could argue Javascript developers are not engineers. If the user can get the desired data from a website without having to run 4.5M of js in a large browser, but the developer "needs" 4.5M of js and a team of people to deliver the data, then who is t…
'Support the 0.1% of people without javascript' usually doesn't make it beyond the bottom of the backlog.
Earlier quoted context omitted.
Not really. They gave permission for the initial GET request for the HTML. The rest of the requests were inserted into the document by the programmer and executed by the browser. The browser assumed those links should be fetched automatically and executed. :)
The rest of the requests were triggered by the browser, not the programmer, because they were part of the initial HTML and the browser follows the HTML spec. The person complaining about it and is technical and knows this, they were under no misconception that they were viewing a document format that doesn't include code execution. Of which I'm having trouble of even thinking of an example, because even Word document…
But since you want to argue...
A request to an HTML document with no JavaScript src links, image links, or CSS links will not make multiple requests. I'm old enough to remember when I had to actively tell images to load.
The code for the page is written by programmers. Programmers cause browsers to make multiple requests. Often times without understanding "the spec".
There is a famed quote that goes something like this: "An engineer is someone who can do with ten schillings what any fool could do with a pound." By this definition one could argue Javascript developers are not engineers. If the user can get the desired data from a website without having to run 4.5M of js in a large browser, but the developer "needs" 4.5M of js and a team of people to deliver the data, then who is t…
Except the schillings usually are days. And it might take JS to build the requirements in 10 days. 'Support the 0.1% of people without javascript' usually doesn't make it beyond the bottom of the backlog.
It is the Javascript and website complexity, the embellishment of data with needless garbage, that necessitates "support" i.e. work for developers. It creates more work.
Serving text without embellishment requires less work, not more.
At some time or place in every website development project, data exists in plain text or some other raw form.
Some users might just want that data as it is, without embellishment, before web developers even start working.
This requires little if any "web development" work. Basic HTML can be autogenerated with ease.
Data
Description: blah, blah, blah
# usage: $0 section
# sections: world, etc.
curl -4o .$0 https://static01.nyt.com/services/json/sectionfronts/$1/index.jsonp
exec sed '/\"guid\" :/!d;s/\",//;s/.*\"//' .$0
Meanwhile we are having this discussion on a web site that does more or less exactly what I am suggesting. It can be easily autogenerated. The HTML could have been written in the 1990's. It is trivial to remove the tags and have plain text.
I guess we are the 0.1% that would ever access a website that did not need Javascript?
The fact that the popular browsers run all manner of javascripts and process all sorts of tags does not obligate anyone to use them. Whether it is web developers or users.
One of my clients loads a 4.5 Mb bower.js (including Angular with a lot of components and jQuery), they also include an extra jQuery script, a full jQuery UI and several other scripts on each pageload . Nothing is minimized. The bower file alone has 300k in comments. The CSS file is also nearly 1 Mb. It's just a simple website with some forms. They have 2 developers working on the site, a scrum master, a project mana…
I don't think more powerful tools are the solution here. The problems and solution are obvious. The root problem is that many "product" teams will take any 10x improvement from tooling and adapt by being 10x more inefficient. Because they can. Hardware (laptops, phones), and browsers js and rendering engines, are all 10x faster than they were 10 years ago, giving 100x to 1000x overall speedup. Think about that, it is…
Earlier quoted context omitted.
Also, vast majority of users will have a cached copy of jQuery from Google CDN already. Now bundling it with the rest of your JS, that's indeed a mistake.
CDNs are a lie. The privacy implications outweigh the performance benefits since there are many, many, many CDNs and many, many versions of jQuery. It's rare for users to benefit from caching.
If I may, it seems to me like there are several possible points of discussion: 1) Javascript is bad (vs. Javascript is good and variations thereof) 2) The use a lot of websites make of Javascript is overcomplex, gratuitious, uncalled for, intrusive, etc. 3) Sites should provide some (even minimal) functionality to people browsing them without Javascript #1 is largely a matter of personal opinions #2 is a known, unden…
I simply will not spend time tailoring a nascent or even mature product to 0.0001% or whatever minscule percentage of the population turns off JS. If you turn off JS, you get a blank screen. Why should I accommodate your cohort? Why write unit tests for someone who takes a standardish client with above 1% market share and does something completely unstandard with it?
This is reasonable logic and I think it is an important point in getting more people into a technology movement, whether it is removing JS or anything else. A similar example is getting encrytion: many users don't know or care to use it, so it is usually a side issue if mentioned at all in a company. But if the percentage of people who do use it increases, companies will have a greater interest in supporting it.
Currently, normal users just care that content loads when the click the link for a website, and perhaps don't understand or care that JS is running or what the consequences of that is. A more constructive way to get better experience without JS is to ask others to also block it to show companies that this is an issue, rather than just directly asking companies to add support.