61–70 of 412 posts
Looking forward to the author's follow up: "A day without a CPU". I am sick of lazy, profligate coders assuming that my computer is a von Neumann machine. And that just because I run their software, I am happy with it spending billions of my CPU cycles. How did we, as an industry, get to this point!?
Having browsed nearly JS-free for the last two-ish years, aside from a bit of tweaking at the start, I have to say that it has made things a lot faster, more stable, and just much more of a pleasure to navigate. If anyone is interested, I have found that two tools make life a lot easier: - NoScript, which blocks execution of scripts save for those you whitelist. This means sites that reasonably require JS (e.g. YouTu…
Earlier quoted context omitted.
Re [0], note that Google Maps on the other hand seems to handle lack of JS very well. I guess it can be blamed on different teams in the same big company.
If by "seems to handle lack of JS very well" you mean "does not work at all", that makes sense. Not being sarcastic either, it seems they decided to take an all or nothing approach and force the user to enable JS to use Google Maps, or instead see this page: https://i.imgur.com/Qc156Ds.png Maybe the maps product wholly depends on JS for all functionality?
People should realise that most sites today aren't websites, they're web applications. HTML is just the template/output language. Without JS you would have to download an even crappier, probably Windows only desktop app since it wouldn't be possible to implement the logic.
No, most websites are still websites, and one of the biggest problem on the web is the plague of people who think their website should be an application instead. Actual web applications, like e.g. office suites, map applications, ect. are obviously extempt from "should work fine without JS" rule.
Obviously there are disadvantages as well, but it's a tradeoff, and if executed correctly it's one that, as fewer people turn off JS and browsers become better at running web apps, is increasingly becoming worth the complexity for certain use cases.
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.
Ah, so this is how front-end got the way it is.
It's 2017. All modern browsers support JS and it's no longer reasonable to expect all websites to work very well without it.
All modern browsers support JS While that's true it's not reasonable to assume the user has JS enabled. Ad-blocking plugins that also block JS are increasingly common. and it's no longer reasonable to expect all websites to work very well without it. The question should be "what does work very well" actually mean? For a closed application that requires the user to log in I don't really care. Users won't use the app i…
Why?
Instead of building for 0.5% of users that can just enable JavaScript, why shouldn't I invest the time into building a new feature, writing more unit tests, or writing an app for Windows Phone?
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…
> For me it’s a matter of elegance and simplicity over unnecessary complexity. Simplicity is having one place where the DOM is created and managed, and optimizing for the 99% use case. Complexity is splitting up DOM rendering over two networked systems for servicing a 1% use case. Browsers are JS runtimes now. Get over it.
> 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.
Having browsed nearly JS-free for the last two-ish years, aside from a bit of tweaking at the start, I have to say that it has made things a lot faster, more stable, and just much more of a pleasure to navigate. If anyone is interested, I have found that two tools make life a lot easier: - NoScript, which blocks execution of scripts save for those you whitelist. This means sites that reasonably require JS (e.g. YouTu…
Would you mind sharing that bookmarklet?
javascript:(function()%7Bvar%20loc%3Dwindow.location%3Bif%20(window.location.protocol%20!%3D%20%22https%3A%22)%7Bloc%3Dwindow.location.toString().replace(%2F%5Ehttp%3A%5C%2F%5C%2F%2F%2C'http%3A%2F%2Fwebcache.googleusercontent.com%2Fsearch%3Fq%3Dcache%3A')%3B%7Delse%7Bloc%3Dwindow.location.toString().replace(%2F%5Ehttps%3A%5C%2F%5C%2F%2F%2C'https%3A%2F%2Fwebcache.googleusercontent.com%2Fsearch%3Fq%3Dcache%3A')%3B%7Dwindow.location.replace(loc%20%2B%20'%26num%3D1%26strip%3D1%26vwsrc%3D0')%7D)()
Earlier quoted context omitted.
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.
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.