Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A day without JavaScript

sonniesedge.co.uk

Post reply on HN
Print view View original

201–210 of 412 posts

Re: A day without JavaScript

#201

Post by mabbo »

FLUX-YOU wrote: post #36

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

While I agree with you, I still want to give them points for admitting their failure. It's a cute image, with a cute line that tells you exactly what the problem is.

Compare that to sites where you just get a blank page.

Re: A day without JavaScript

#202

Post by neurotrace »

gpderetta wrote: post #116
madsbuch wrote: post #78

Earlier quoted context omitted.

All google products. But it is ridiculous to disregard JavaScript because some people can't write it properly. It is the same as saying that I wouldn't use a browser because I once went to a website that displayed a popup.

It is not ridiculous, machine crippling JS malware is a click a way and you will never know until you click. The safe strategy is JS off by default plus whitelisting. > wouldn't use a browser because I once went to a website that displayed a popup you would use a popup blocker though.

> machine crippling JS malware is a click a way

I have been using the internet nearly daily for about 20 years now. I can't recall a single time I clicked on something that gave me "machine crippling JS malware".

Barring some serious security gaps, JS isn't even capable of doing anything more than lock up the browser and maybe send some extremely minimal information about you back to someone elses server.

Re: A day without JavaScript

#203

Post by devrandomguy »

linkmotif wrote: post #123
jaclaz wrote: 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?

In my experience, optimizing for perceived latency (time between user request sent and site becoming usable) inevitably leads to server side rendering, in geographically distributed availability zones. If you know this in advance, then you can choose to use tools that support code reuse across the client/server divide. This way, SSR is mostly a one time cost, and it can be implemented at the very beginning of the project, while everything is still nice and simple. It does impose additional constraints during UI development, but many of those are good practices anyway (proper use of HTML elements, prefer native form elements to fully custom inputs, use URL and history to manage state, etc).

It has been somewhat humbling to watch users on low speed connections use the app before the JS finishes loading; it shows everyone the true value (or lack thereof, for the passive content consumers who make up ~98% of the visitors) of the JS portion of the app, since they see it with and without JS. Sure, they can't drag a box on my fancy visualization, but they can see a snapshot of it, and use the peripheral controls as links to navigate to the desired application state. Then, as they are reading something that is useful to them, the ~2mb JS blob slips in and quietly brings the application to life.

Also, I love the way the 3rd party JS blobs that management mandated, are so obviously slower than the rest of the page. This gives me good ammunition for the arguments where I demand an HTTP API, not a JS blob, from our partners. They hate that, because then they can't stuff their own trackers into our clients. Fork 'em.

Re: A day without JavaScript

#204

Post by moron4hire »

Udik wrote: post #174
moron4hire wrote: post #130

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.

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

Network bandwidth usage is also not the only metric of size we care about. After it's ungzipped, it needs to be parsed by the JS engine, and more code = slower execution.

Re: A day without JavaScript

#205

Post by gpderetta »

awiesenhofer wrote: post #134
sevensor wrote: post #118

I negotiate the javascript issue by using two web browsers -- w3m for reading hypertext and Firefox when I want javascript. I'm fine with my bank or an online store expecting to use my browser as a thin client, but if you require javascript to present your blog, I'm going to find a different blog to read. This policy makes it pretty much impossible to use social media, because social media is basically blogs-that-req…

http://mbasic.facebook.com if you ever do miss social media this gets you a javascript-free, minimalist version of facebook. I use it all the time on mobile and get hours more battery compared to their app or standard mobile site.

I switched to mbasic the first time the FB application crashed on me on android.

Re: A day without JavaScript

#206

Post by forgottenpass »

megous wrote: post #108
sametmax wrote: post #75

Earlier quoted context omitted.

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.

Programming is mostly creating functions and interfaces to decompose problems into reusable parts where reuse makes sense. Nothing wrong with creating a simple function for making XMLHttpRequests or for fetch API. Most of the time there's no need for the level of generality of jQuery interfaces. Just by making a function you're not creating a library. Sometimes I find DOM API verbose too. Nevertheless the fix does no…

Just by making a function you're not creating a library.

Have you seen what passes for a library on npm?

Re: A day without JavaScript

#207

Post by adtac »

sametmax wrote: post #21
JepZ wrote: post #11

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.

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

Re: A day without JavaScript

#208

Post by atriix »

WorkLobster wrote: post #31

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…

uMatrix [0] "Point and click matrix to filter net requests according to source, destination and type" is also nice.

0: https://github.com/gorhill/uMatrix

Re: A day without JavaScript

#209

Post by drdaeman »

scottmf wrote: post #20

It's 2017. All modern browsers support JS and it's no longer reasonable to expect all websites to work very well without it.

  
  
    import ReactDOM;
  
    const HowQuestion = (text) => {
        return (
How {text}?
);
    }
    const Comment = () => {
      const text = \
        "the year justifies using Turing-complete programs" 
        "to express what could be a simple static text document";
      return ;
    };

    const el = document.querySelector("#14507550 .comment");
    ReactDOM.render(, el);

Re: A day without JavaScript

#210

Post by BaronSamedi »

thinkxl wrote: post #148

It's funny how devs feel threatened by a non-JS trend. Even when their favorite frameworks are providing tools to accomplish minimal functionality when JavaScript is off. Server side rendering has been a big priority in React, Vue, Redux, ReactRouter, etc.

As a rule, people tend to support the status quo--even when the status quo is problematic. I would argue that there are good reasons for thinking that the current widespread use of JS is problematic. How, for example, is allowing the execution of arbitrary code in your browser not a major security flaw? Didn't we learn anything from Java applets and Flash?

Usability is also a problem. JS heavy sites often break standard web expectations such as the back button. They are often overly complicated, favor design cleverness over usability, and don't work on mobile devices.

Sure JS is great for web applications but is really needed for every single site? Whatever your view it is at least worth discussing whether or not the status quo is misguided.

Post reply on HN