Live data from Hacker News

A day without JavaScript

sonniesedge.co.uk

321–330 of 412 posts

Re: A day without JavaScript

#321
Mozilla is partly to blame here by taking away the "Disable Javascript" control, which effectively told websites they could go crazy with JS and ignore the "no-JS" users.

What might be helpful now is something like a MAX-JS-BYTES=n header that tells site owners that the useragent will ignore any JS beyond the first n bytes on the page, and will not request more once that limit is reached. (I know this is a terrible idea; hard byte limits could never work. But somehow site owners need to be made to feel more immediate pain when they screw their customers with too much JS bloat because they've hired lazy developers, or because their idiot VP of marketing is all about TEH BLING.)

Re: A day without JavaScript

#322
post #55

Earlier quoted context omitted.

Naw, I will keep running noscript and blocking script by default. If your site doesn't work, I don't care, I will go to a different one. I may be the minority now, and while there is some great use of js out there; most of it is bloated, slow, insecure, and often privacy destroying.

>I may be the minority now, You will also be in the minority later

Sure, but the he only has to wait for the cycle to swing around again. Browsers will officially turn into JS/WASM runtimes. Sites will balloon until instant delivery is no longer feasible. Browsers will respond by allowing sites to version themselves to aggressively cache client code. Eventually browsers will start offering site-specific-browser features to 'new-modern' sites to combat the extreme waste of Electron and the like.

Someone with political capital and influence in the developer world will realize that the web is still mostly text and design a browser optimized for that use case. It will be hailed as a revolution and people will start preferring it over the 'old-web' for accessing static content like news.

Then under pressure from developers pushing the limits of static content they will include a simple, limited scripting language that promises to facilitate basic interactive elements and start the cycle anew.

We should call it something trendy, maybe 'The River'?

Re: A day without JavaScript

#323

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…

Lol @ testers. How about getting rid of the project manager and testers, and hire 2 decent developers who have some experience with automated testing, continuous integration and continuous delivery instead? Productivity rises 300% I would presume.

Re: A day without JavaScript

#324
post #40

Earlier quoted context omitted.

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 ;-)

Wait what? CS students learn color about color blindness now? I really wasn't in the good classes!

I didn't learn anything graphics-related in my CS degree. Seems like more of a UX or software development topic than a CS topic.

Re: A day without JavaScript

#325

Earlier quoted context omitted.

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.

[deleted]

Re: A day without JavaScript

#326
I think it's pretty critical to note that, with only one exception, every website that works well without JS is what HTML was built for - static documents - and every website that doesn't, what HTML is famously bad at - apps.

Re: A day without JavaScript

#327

Earlier 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…

For me, yes. I should be able to see at least the main content of your blog without JS. I don't care if it's perfectly formatted or styled. Just put the text in a div. When I go to a blog post linked from HN and see a white empty page I will just move on.

Good. Please leave. I don't walk into a restaurant and demand that they cook my food without using a knife. Don't expect modern websites to bend over backwards for a (frankly rather juvenile) view of a modern web standard.

Code execution is part of the web, it's here to stay, the number of sites that support non-JS experiences will continue to dwindle.

You're not some special snowflake. Other people make real decisions based on cost/value models, and you cost way more than you're worth.

Re: A day without JavaScript

#328

Mozilla is partly to blame here by taking away the "Disable Javascript" control, which effectively told websites they could go crazy with JS and ignore the "no-JS" users. What might be helpful now is something like a MAX-JS-BYTES=n header that tells site owners that the useragent will ignore any JS beyond the first n bytes on the page, and will not request more once that limit is reached. (I know this is a terrible i…

> What might be helpful now is something like a MAX-JS-BYTES=n header that tells site owners that the useragent will ignore any JS beyond the first n bytes on the page, and will not request more once that limit is reached.

I love this idea. Web development seriously needs some discipline. Myself included.

Re: A day without JavaScript

#329
post #276

Earlier quoted context omitted.

> it may be enough to extend the HTMLElement prototype a bit You lost me here. Anybody extending standard objects cannot be taken seriously.

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.

Re: A day without JavaScript

#330

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

You also don't see car manufacturers change their designs so that they will accommodate drivers who've decided to remove their steering wheel, nor do car manufacturers design their cars for some possible future world without gasoline.
Post reply on HN