121–130 of 412 posts
Earlier quoted context omitted.
Chrome 59 has a coverage tool built-in: https://developers.google.com/web/updates/2017/04/devtools-r...
Note: The color-coding is likely to change in future Chrome releases. I am a little surprised to find such an issue in Google software as it is a topic for first semester CS undergraduates ;-)
Earlier quoted context omitted.
> Browsers are JS runtimes now. Get over it. Sure, dude, ignore anyone without a machine that can run MBs of JS within a reasonable time.
Why are you trying to browse the modern Web on your Windows 98 potato from last century?
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…
>Verdict: Cartography catastrophe. As much as I hate JavaScript, Google Maps gets a pass. I'm pretty sure the code behind it is thoroughly tested. We can just suck it up and turn JavaScript on for one of the most useful tools from the internet -- how hard is it to find something that whitelists domains to run JS anyway?
There should be something as a fallback, though, surely? Take out all the functionality, by all means, but at least give me a map image. If you can't even get link-to-zoom working to display different images, just give me a map image based on my IP location; give me anything rather than nothing.
>Verdict: Cartography catastrophe. As much as I hate JavaScript, Google Maps gets a pass. I'm pretty sure the code behind it is thoroughly tested. We can just suck it up and turn JavaScript on for one of the most useful tools from the internet -- how hard is it to find something that whitelists domains to run JS anyway?
There should be something as a fallback, though, surely? Take out all the functionality, by all means, but at least give me a map image. If you can't even get link-to-zoom working to display different images, just give me a map image based on my IP location; give me anything rather than nothing.
One thing to consider is that at larger companies, we already have a difficult enough time testing all of our site with JavaScript enabled. Netflix building a version that works without JavaScript is like asking them to build a second website, especially from a QA perspective. When you look at your users and find that .5% of them are not running JavaScript, how do you justify spending the money for that few of people…
I often read in subway, where I need to load the page in 3-4 seconds or I'm in the tunnel again without the signal. In some stations I only get 50kbit/s or so.
Most websites don't cut it so I don't even bother. Those who cut it though, I get engaged with more, because I can't go anywhere else without a signal.
In a nice world I would write a scrapper + alternate website that hosts only the content and some simple navigation over plain HTML, preferably with as little CSS as possible. There's the annoyance of copyright though, so no way of making this public.
What is the motivation behind this mentality? Sure there are still webpages on the web, but there are also web apps. Why or even how would you expect a web app to work without JS? Why would you expect developers to spend time writing a non JS version of their app? Before taking on this endeavor, I would prioritize native apps, optimizations of all sorts, adding features, etc. Unless your app is gmail, why would you e…
Earlier quoted context omitted.
> Yeah. Except you need to do Ajax and fetch doesn't cut it. So new lib. Why doesn't fetch and its polyfill cut it?
Polyfill. So new lib. And even then. You need to encode params manually. And of course no middleware, so for special decoding or repeating headers, you end up writting a wrapper.
So, you don't like the polyfill, created to the specification. Fine, but depending who you target, you might not need it. Plenty of modern browsers have good support.
> And even then. You need to encode params manually.
Or use the Request constructor.
> And of course no middleware, so for special decoding or repeating headers, you end up writing a wrapper.
Request constructor will let you handle the headers quite nicely.
Earlier quoted context omitted.
Because of those 1% the large majority don’t choose to turn it off but don’t have it available for a multitude of reasons outside of their control.
Such as... ? If you're referring to screen readers, I was under the impression that pretty much all of them execute JS these days. Am I wrong?
- script hasn’t finished loading, or has stalled and failed to load completely
- application route is up, but the route to the Content Delivery Network is broken
- user has chosen to install a plugin that interferes with the DOM
- user has been infected with a plugin that interferes with the DOM
- user’s company has a proxy that blocks some or all JavaScript
- user’s hotel is intercepting the connection and injecting broken JavaScript
- user’s telecoms provider is intercepting the connection and injecting broken JavaScript
- user’s country is intercepting the connection and injecting broken JavaScript
- JavaScript code has functions not implemented by your user’s browser (older browsers, proxy browsers)
[1] https://gdstechnology.blog.gov.uk/2016/09/19/why-we-use-prog...
Earlier quoted context omitted.
Not really an answer to your question, but this might be useful: http://youmightnotneedjquery.com
Yeah. Except you need to do Ajax and fetch doesn't cut it. So new lib. And manipulate the dom with something better then the browser API or you loose your mind. So new lib. Then normalize browser events. Oh wait, you can do that manually. But you are writing a new lib. Eventually the code will grow to be the size of jQuery anyway. Only not as well tested, documented and cached.