Earlier quoted context omitted.
those knowledgeable users might be installing JS blockers in their friends and family computers right now.
And then they get "since you played with my computer the internet doesn't work properly".
"you broke google!"
A day without JavaScript
231–240 of 412 posts
Re: A day without JavaScript
#232What benefit could Google possibly get out of making Google Maps work without JavaScript? The main takeaway I have here is that older applications are more likely to support a no-JS scenario, and I'd imagine that's because they can just fall back to older legacy code.
Re: A day without JavaScript
#233Earlier quoted context omitted.
Nonsense. This is definitively YAGNI. Good engineering is accommodating the greatest number of people with the resources you have in the least amount of time. Thinking about some abstract future scenario is categorically not good engineering.
You misspelled "good bean-counting". Good engineering requires you to cover for everything you can. Case in point: car seatbelts and airbags. Most people don't crash, right? But you aren't seeing the car manufacturers remove seatbelts and airbags.
what a ludicrous analogy. engineering is an applied science, not a purely theoretical one where you can remove the human impact of your decisions from the equation. comments like this are a prime example of why engineers need to take more liberal arts classes
Re: A day without JavaScript
#234One 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…
Yes, it's called "tree shaking"[1], modern Angular apps can be cut down to a around 50-100k (assuming nothing heavy feature set). Find build tools that can do it, like Webpack or Rollup.
[1] http://blog.mgechev.com/2016/06/26/tree-shaking-angular2-pro...
Re: A day without JavaScript
#235It'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…
> 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.
What percentage of users do you think block JavaScript? I'd be utterly shocked if it were more than one or two percent.
Re: A day without JavaScript
#236Earlier quoted context omitted.
> That's where work needs to be done. 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?
For the same reason we build features in websites that work for blind people (aria tags everywhere), disabled people (accessible buttons), people who speak different languages (i18n), VIM users (GMail keyboard shortcuts), etc. We choose who we build for. If you want to ignore 0.5% of your users then that's your choice, but don't complain when you submit something to HN and get a page of responses saying it doesn't wo…
Humoring people who want to turn off JS is not really on the same level as making the page work for people with disabilities.
Re: A day without JavaScript
#237Earlier quoted context omitted.
>Eventually the code will grow to be the size of jQuery anyway. Um what? jQuery is huge. You won't possibly use everything in it.
Well, define "huge." It's like 28KB that your user may already have cached if you use a CDN. https://mathiasbynens.be/demo/jquery-size
I meant huge in terms of functionality. It supports so many things that you can't possibly need everything.
Re: A day without JavaScript
#238Earlier quoted context omitted.
I use uMatrix as a substitute for NoScript + uBlock, and while it's a pain to get some sites working manually without bulk-enabling everything on them, I'm mostly happy about it, and the web looks better for me.
I tried using uBlock (EDIT: uMatrix) for a while, but I felt like it was a lot of hassle, and most of the time it still wasn't granular enough to actually block the things I wanted to without breaking sites. It seemed like usually all of the bullshit javascript making sites sluggish came from the same domain as the few bits I might actually want. (Or at least needed to make the site useful.)
> wasn't granular enough to actually block the things I wanted to without breaking sites
I don't understand the criticism: it's no less granular than NoScript. If considering only the dynamic filtering panel[1], it can be argued it's more granular given that one can block inline-script tags only, and also one can block/allow on a per-site basis.
Static and dynamic URL filtering of course allows you to filter on a per-URL basis.
[1] https://github.com/gorhill/uBlock/wiki/Blocking-mode:-medium...
Re: A day without JavaScript
#239Earlier quoted context omitted.
Well, define "huge." It's like 28KB that your user may already have cached if you use a CDN. https://mathiasbynens.be/demo/jquery-size
I meant huge in terms of functionality. It supports so many things that you can't possibly need everything.
Oh. Well that's true, but I think the point is more like you end up implementing some significant subset of that, except with homespun code that isn't tested as well.
Re: A day without JavaScript
#240Earlier quoted context omitted.
I find that it's at least (usually more) double the work to build the JS-free version of something for a fraction of the user experience. For example, imagine a forum where clicking the "edit post" button turns your post into a editor and saves with AJAX so that you can continue scrolling once you make your edit. To build the JS-free version, you typically need a separate endpoint, a new template, a redirect, and a l…
Non js users aren't expecting the website to work perfectly without scripts on. The bare minimum they ask for is that the site can be read without using scripts. Obviously it would be nice if all the moving components didn't need scripts either, but most people can accept that this is too much work.
Depending on the site, even just reading may be problematic. Imagine a webapp where all data is requested and sent as small JSON updates. This is faster and it's less data than full page copies, and can be more targeted to that user.
To build this feature for the tiny fraction of non-JS users, you're looking at duplicating all of this functionality on the server. This greatly increases dev time and complexity of the codebase. It means moving from an entirely API-driven platform to one where your server needs to understand the app logic as well.
Like it or hate it, Javascript is a web standard. You know that websites will break if you disable CSS -- the expectation should be the same for disabling Javascript.