Live data from Hacker News

A day without JavaScript

sonniesedge.co.uk

261–270 of 412 posts

Re: A day without JavaScript

#261

I surfed without JS on for a long time. I found that it made the web very very pleasant! What totally breaks is when you do a complicated bank transfer or work on some older site. They often transfer you across multiple domains, so whitelisting doesn't work, as you can't anticipate what site to whitelist (when you check your points, bank.com redirects you to bankrewards.com, things like that). What's really needed is…

My credit union's web site hilariously misinterprets my browser's portrait-mode aspect ratio and lack of Javascript as evidence that I must be using a phone, and serves me up a "mobile" site which is lighter, simpler, faster, and generally more pleasant to use than the normal one. Yes, there are a couple of extra pages to click through when transferring money from one account to another, but the pages load so quickly that it's still actually faster than the Javascript-based menus in the desktop site.

Every time I set up a new browser, NoScript is the second plugin I install, after uBlock Origin. Between the two, the web is far less annoying than it used to be.

Re: A day without JavaScript

#262
post #200
post #174

Earlier quoted context omitted.

As big as jQuery? Gzipped it's 27k, a ridiculously small size.

Ridiculously small? That could take 10 s to download on a 2G network.

Yeah, sure, most sites today are totally browsable in 2G.

Event the damn native APP for hackernews, using only JSON, is not usable in 2G.

Re: A day without JavaScript

#263

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.

I am so sick and tired of this argument. Having done it several times, no, you do not end up with something as big as jQuery, not by a long shot.

Sure, if all you do is some onclick() and a few appendChild().

Plus for the time you spend chasing compat issues, writting wrappers, choosing small libs and packing it all together, you could have done your site. For less than 40ko.

People are not blinking at including react ecosysteme, which is huge. But attack jQuery ? Seriously ?

Re: A day without JavaScript

#264
post #120

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?

Supporting a JS-disabled experience should not be your first priority. But, reducing needless reliance on javascript will improve your site for every user - making the page load / respond faster, use less CPU and memory, etc. It will also improve the development experience for you - faster to test, less crazy codebase to work in. It's really just architecting the site better.

Some people are so scared of "premature optimization" and "catering to a tiny number of geeks" that they trick themselves into making a huge JS mess. Most websites these days seem to be examples of this.

Re: A day without JavaScript

#265
Are there any JS frameworks that make it easy to build SPAs that degrade gracefully when JS isn't available?

I know there's a lot of work done on making server-side rendering work with React / Vue / whatever, but I'm wondering if there's a framework available that asks for some tradeoffs in how your SPA is structured in order to maximize the amount of functionality available when scripting is off (similar to how Redux asks you to make state-management tradeoffs in order to get hot-reloading, dev tools, etc.).

For example, you'd probably want, at a minimum:

* By default, all code related to fetching or subscribing to data from a server is tied to URL routing.

* By default, all code related to sending data to a server works with standard webforms.

The closest analogue to what I'm thinking about is Turbolinks and Ruby on Rails, but I'm curious if there's some equivalent in JS-land because you'd get less context-switching when adding extra JS-only SPA interactions on top of the core JS-optional form-based interaction.

Re: A day without JavaScript

#266

Earlier quoted context omitted.

I am so sick and tired of this argument. Having done it several times, no, you do not end up with something as big as jQuery, not by a long shot.

Sure, if all you do is some onclick() and a few appendChild(). Plus for the time you spend chasing compat issues, writting wrappers, choosing small libs and packing it all together, you could have done your site. For less than 40ko. People are not blinking at including react ecosysteme, which is huge. But attack jQuery ? Seriously ?

> chasing compat issues, writting wrappers, choosing small libs and packing it all together, you could have done your site.

I don't know about you, but usually my projects last longer than a week, so those sorts of savings don't represent a significant chunk of my overall development time. Also, I'm not a shit programmer, so I can actually write a for loop that does what I want on the first try. I've spent more time trying to figure out jQuery's goofy syntax and what the hell it's doing with AJAX queries than it has ever saved me in development.

Re: A day without JavaScript

#267
I guess I should expect that an article about not using JavaScript is written on a page with standard Google Analytics tracking and a JS bundle of... partially-minified code that is primarily used to apply styling.

Re: A day without JavaScript

#268
post #38

> 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.

If what you say is true, Gopher needs to make a resurgence, its immune to the kind of cancers riddling the modern web.

Re: A day without JavaScript

#269

Earlier quoted context omitted.

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?

Supporting a JS-disabled experience should not be your first priority. But, reducing needless reliance on javascript will improve your site for every user - making the page load / respond faster, use less CPU and memory, etc. It will also improve the development experience for you - faster to test, less crazy codebase to work in. It's really just architecting the site better. Some people are so scared of "premature o…

It really depends on your pages.

If you are building a blog or a news site (a classic "content" site), it should absolutely work without javascript.

If you are building an admin interface for said news site, where articles are edited and published, it is okay to require javascript.

Re: A day without JavaScript

#270

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…

Chrome 59 has a coverage tool built-in: https://developers.google.com/web/updates/2017/04/devtools-r...

Off-topic, but:

> Full-page screenshots. Take a screenshot of the entire page, from the top of the viewport to the bottom.

I'm surprised to see the Chrome developers not know what 'viewport' means.

Post reply on HN