19 ms·

Maybe we could tone down the JavaScript (2016)

• togaen 5y ago
  Yes. Please. Enough with the scripting. It’s only gotten worse since the article was written.
  • akkartik 5y ago
    These days Twitter can't even show the 280 characters of a tweet without JavaScript.
• superkuh 5y ago
  >here is a screenshot of a tweet, with all of the parts that do not work without JavaScript highlighted in red And this is when I realized this article was written a long time ago. Now if you attempt read a text post on twitter you get nothing at all unless you execute javascript first. The entire screenshot would be red in 2021.
  • btown 5y ago
    Article is from 2016 - should be in title!
• durnygbur 5y ago
  • nicoburns 5y ago
    Plenty of people still write JavaScript. TypeScript is rapidly gaining popularity, but I'd be surprised if it's reached even parity with plain JS usage yet. People using Angular are probably mostly using TypeScript, but there are still huge communities (React, Vue, Node.js) where TS is optional.
    • jetsetgo 5y ago
  • jimmaswell 5y ago
    Still using JavaScript with occasional jQuery over here.
  • holoduke 5y ago
    When quick prototyping i prefer plain JavaScript 100% over typescript. Lot less boiler plate than typescript. Faster, no compilation, can run it in a browser console. For larger project I might consider typescript.
  • nullandvoid 5y ago
    I'm sure you already know this (although I've had conversations with people that hate on TS in the past, that didn't, hence my post), but Typescript is JavaScript at runtime, there are no performance hits by using it in production (and negligible build times on save during development).
    • LarrySellers 5y ago
      Shame it's so easy to get comments flagged and killed on HN. The parent comment wasn't inflammatory and (as we can see) contributed to relevant conversation.
      • throwaway19937 5y ago
        I flagged it because it's a Well, Actually (https://tirania.org/blog/archive/2011/Feb-17.html https://tirania.org/blog/archive/2011/Feb-17.html) that makes an unsupported claim.
    • deleted 5y ago
      [deleted]
  • newshorts 5y ago
    Vanilla JS is more rare these days. I interview 2-3 devs per week and always ask basic vanilla JS questions since it’s vital for our workflow that you don’t rely on frameworks we may or may not be using. Knowing react/vue is a bonus, but knowing how to do basic tasks like adding event listeners and manipulating the DOM in vanilla JS is required. It’s anecdotal but I just wanted to say there are a few places that still haven’t fully committed to a framework. I’d say at least 1 dev per week can’t add an event listener or manipulate styles in plain JavaScript. It’s getting to the point where I’m going to need to stop asking and just test in whatever framework they know. Then retrain when they come on board.
    • exdsq 5y ago
      Not going to lie, I’d need to googled that nowadays if I wanted to do those things! Issue with polyglot development. Can’t you ask more fundamental questions like when to use an event listener instead, or best practices?
    • jenscow 5y ago
      And this is why we need technical tests during interviews. There are people who call themselves "web developers", apparently been writing websites for 5+ years, but don't know about addEventListener.
      • durnygbur 5y ago
        But they how how to connect the Angular injector into the service directive.
        • jenscow 5y ago
          An "Angular developer" would know that.
      • bdcravens 5y ago
        Even better, make their direct supervisor take the same test. If they outscore them, they get their job and the supervisor then is demoted to the job being hired for.
• corobo 5y ago
  I honestly thought this attitude had died out with everything being Vue and React and all that I used Huel's site earlier and it even had a splash overlay saying what it was loading, it was one reticulating splines away from being The Sims Edit: ah it was posted in 2016, I don't think anyone (but do wish) cares about limiting their JS usage anymore
  • alphabet9000 5y ago
    i care, plenty of other people care.
    • corobo 5y ago
      Well then I dunno where they hang out cause it doesn't appear to be on HN anymore
      • Uranidiot 5y ago
      • bee_rider 5y ago
        Huh, I'd given up on disabling JS because reddit required it to reply to posts, and I'd assumed HN does too. Turns out HN doesn't. Thanks for providing the impetus to check (I'd expected to say something like "well the site doesn't work without JS, so I guess they didn't stick around" but wanted to check first), I deleted my reddit account a while ago and it turns out that was the only thing keeping me tied to JS. I really am not a fan of JS for all of the reasons that have been retread a million times over the years, but honestly the war is long lost and I don't really see the need to annoy people about it anymore.
      • eadmund 5y ago
        I think there are a fair number of JavaScript devs who really don't appreciate being told that they are on the same ethical plane as, e.g. cigarette designers, which is pretty understandable even if one does think that JavaScript is basically cancer (a position I would not take myself: I think it's more akin to sugar: good or at least neutral in very small amounts). No-one wants to be told that the way he earns a living is fundamentally wrong. Or, in the words of Upton Sinclair, 'It is difficult to get a man to understand something, when his salary depends on his not understanding it.'
• scelerat 5y ago
  It's been thus, nigh on two decades now. Product Designer: "No system controls; we want our users to have the Full Brand Experience, therefore, custom controls." Also Product Designer: "Why don't our custom controls work as well as system controls?"
  • smitty1e 5y ago
    "Assume infinite pipe and ludicrous client resources."
  • Spivak 5y ago
    I mean the product manager isn’t wrong, there is no good reason we shouldn’t be able to make custom components with the behavior of “native” widgets. The fact that the dev story is “build a widget from scratch out of divs” and not “extend the fully functional component with new styling and hooks and slight behavior modifications.” We created this problem ourselves by not having the tools to meet designer needs while doing it right. Pontificating about how they should just change their notion of right misses it completely.
    • dev-3892 5y ago
      well it's historically been because 'extend the native widget' isn't possible with css. WebComponents change that a little bit with well-scoped css, but that's still a very javascripty solution.
      • Spivak 5y ago
        Of course, I’m not at all advocating that the solution is to just do it but that web really hasn’t kept up with the needs of the kinda of apps people want to build with it. It’s easy to build something that works but annoying to impossible to build something robust so we’re left with every single website being functional enough to work but broken. I don’t think telling developers “just do it right” is a scalable solution, the platform has to make the least effort path the one that works best.
    • coffeefirst 5y ago
• deleted 5y ago
  [deleted]
• deleted 5y ago
  [deleted]
• danShumway 5y ago
  I think this has come up on HN enough that people probably already know about these alternatives, but I really recommend using a Nitter front-end to browse Twitter if you don't actively maintain a Twitter account. It doesn't help if like Eevee you do have an account and are actually tweeting, but if all you're doing is browsing then it runs completely Javascript-free. ---- In regards to the actual content of the article, it's an eye-opening experience to dig into how a lot of these pages are constructed and to realize that sites like Google search, Facebook, Twitter are not really designed around having the simplest most performant implementations. There is some dark eldritch magic that happens behind the scenes on a lot of these sites that keeps them working with accessibility readers and nothing else: trying to make it harder to find hrefs, trying to get rid of right-click open in new tab commands, trying to make it impossible for browser extensions to identify parts of the HTML. And I think it's really easy at first to say, "this is a complicated problem we don't understand, of course this must be a super-performant hyper-optimized way of doing everything." But it just becomes harder and harder to justify that over time. The link wrapping that Google search does really doesn't have anything to do with performance, it's designed to close holes around how people open links without sending pingbacks to Google servers. There is a real incentive battle between tracking/control and simplicity/performance/flexibility, and the performance side doesn't always win, it seems that big companies are actually willing to introduce a huge amount of engineering complexity for an outcome that's almost as good as a normal href but that allows them to accomplish other goals as well. The level of complexity in these sites sometimes gets used as an excuse to avoid criticism, but I think that sometimes the complexity is there purely because sites are actually fighting with browser technology; Google's setup for link wrapping is very complicated, Twitter's text entry is very complicated, because they're trying to take control of a process that they don't normally have control over. So they build very complicated houses of cards that fall over in weird situations, and the complexity of the house of cards becomes the defense against criticism that the house of cards keeps falling over. I look at projects like Nitter; Nitter is not a full Twitter replacement, but in regards to the parts of Twitter that it does replace, it's better engineered. It's less complicated, the engineering is less impressive, but impressive engineering is not the same thing as good engineering. For the features it's replicating, Nitter works better than the real thing, and I think the reason is that it's less complicated and that it's fighting less with the browser.
• vbo 5y ago
  I know this is likely to be controversial, but JS improves the user experience a lot, both in terms of interaction and speed, as well as making development more manageable (if used correctly), alas at the expense of annoying purists who would prefer to enagage in all sorts of CSS/HTML gymnastics just to avoid using JS (and other kinds that would prefer vanilla JS to frameworks). Do that in a large project and you'll quickly realise how unmanageable it is let alone, as the author says, "iffy".
  • eitland 5y ago
    > but JS improves the user experience a lot, both in terms of interaction and speed, Except for autocomplete, do you have any examples where user experience is increased a lot?
    • jenscow 5y ago
      ajax/async requests. On this site, for example, if up vote your comment.. the status will just be updated. Without JS, it causes the page to reload, and I will briefly lose my place.
    • tshaddox 5y ago
      The big one is seeing the results of data modifications instantly without a full page refresh.
    • MaxBarraclough 5y ago
      How about rich text editors in webmail?
      • Nextgrid 5y ago
        HTML mail is a mess that's impossible to get right; better to avoid it. Misleading users with a rich-text editor that looks like a word processor is bad because it'll pretty much never look as intended in anything but the same HTML editor that created it originally.
        • 5y ago
• booleandilemma 5y ago
  It's not really JavaScript that's the problem but the way it's used, right? No one says JS has to be used for weird and creepy tracking purposes.
  • mdavis6890 5y ago
    Correct. And the article doesn't say so either. It just says that using it in pointless, negative-value ways is bad - and there's all too much of that. If you need a link, use <A ...>, for example, not a custom JS handler.
  • deleted 5y ago
    [deleted]
• Rd6n6 5y ago
  Off topic, but eev.ve has some outstanding articles on game design and is the author of one of my favourite custom doom levels Specifically, the articles of how graphical fidelity is ruining video games and the ones about doom and doom mapping
• glacials 5y ago
  Now that it's 2021, most of the concessions the author makes are possible with CSS. You can change the styling of an element using hyperlinks with the `target` pseudo selector: <style> #dropdown { display: none; } #dropdown:target { display: block; } </style> <a href="#dropdown">Show dropdown</a> <div id="dropdown"> Dropped down! <a href="#">Close</a> </div> This works for dropdowns, tooltips, modals, even navigation if you're navigating to known places (or if you use JS to pre-insert the destination into the DOM). And of course, you can animate the changes with pure CSS.
  • deleted 5y ago
    [deleted]
  • ranger207 5y ago
    They've also got a blogpost (from 2020) about that, which provides an interesting counterpoint to the posted article https://eev.ee/blog/2020/02/01/old-css-new-css/ https://eev.ee/blog/2020/02/01/old-css-new-css/
  • draw_down 5y ago
    These sort of arrangements typically don't hold up when it comes to finer points of UX, like "clicking outside closes it" or "closes after x seconds", and so on. What if you wanted a keystroke shortcut to open the thing, or a keystroke shortcut to close it, the list goes on and on and on. Product managers and designers don't care about reducing JavaScript, so that really has no weight against the things I've mentioned plus more. They want it to work the way they want it to work.
  • chrismorgan 5y ago
    :target has been a possibility for many, many years, but is a poor choice for this sort of thing because it’s rather fragile (other things touch the fragment too) and messes with history. The better hack that has been long available is invisible checkboxes, :checked and a sibling selector. That’s almost certainly what “you could fake it with CSS too” was describing back then. But the proper solution now would be <details>. As an example of this, many dropdowns on GitHub work without JavaScript, by using <details>. I would note that with all of these alternatives, you tend to want a little JavaScript to enhance the functionality, e.g. manage ARIA states and focus.
• pmarreck 5y ago
  I agree with this guy. I generally try to do as much as I possibly can using pure CSS because half the time I regret using JS for things unless it is absolutely necessary
• efficax 5y ago
  These complaints are 20 years old now and in the meantime i keep building successful JavaScript heavy applications
  • ozim 5y ago
    You see - applications. I am also developing heavy JavaScript applications where people manipulate or edit / collaborate on the content in many ways. For me problem is with pages/documents where I simply want to read stuff, maybe have some basic filtering options and that does not require loads of JS. Like webshops where I am customer probably don't need 80% of JS that they drop in there for browsing just products. I understand they need JS heavy content editor side where people add/remove/modify products.
  • AlotOfReading 5y ago
    Heavy JS is a bit like junk food. It's fine to have a bit at the county fair and the fact that you can build a successful commercial business selling it isn't terribly surprising, but there are pretty obvious social reasons we shouldn't load it up in every meal consumers eat. That's what articles like this are pointing out: this well-intentioned thing we're doing has negative consequences. Let's do it more moderately and deliberately to mitigate the side effects.
  • throw_m239339 5y ago
    Is it you that built Epic Games store homepage, that has appealing performances on mobile because it can't be bothered to display a list of games without heavy use of Javascript? That's what "successful JavaScript heavy applications" also leads to, developers never testing these on $50 android handsets and not caring about performance the slightest.
• Arthanos 5y ago
  Surprised to see the top comments here so doom-and-gloom: "ah it was posted in 2016, I don't think anyone (but do wish) cares about limiting their JS usage anymore " The tools we have available today to optimize JS and build for progressive enhancement are light years ahead of 2016 because the smartest minds in the industry have optimized for it. The rise of batteries-included server-side-rendered React apps like Remix and Next massively cut down on time-to-first-paint and React 18 makes it easier than ever to defer rendering of async or interactive portions of the page (e.g. the Like count, the reply form) in favor of getting static content on the screen as fast as possible.
  • nfRfqX5n 5y ago
    it’s always doom and gloom on here regarding web dev, unfortunately
• germandiago 5y ago
  I am not sure what Javascript buys you, but from a point of view of doing a server-side app and having to do the frontend... uh, it adds a lot of complexity. I am taking a look into htmx. It looks way closer to what html is and it is more than enough for my purpose at least.
  • germandiago 5y ago
    Htmx is what I will use in my next website. More than enough for me as well and the learning curve seems pretty low compared to alternatives.
  • newsbinator 5y ago
    > I am not sure what Javascript buys you https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
    • germandiago 5y ago
      lol. I learnt something new today. Thanks for that!
• adreamingsoul 5y ago
  Lately I’ve been limiting my JS usage only been use vanilla JavaScript for tertiary functionality and server-side rendering for everything else.
  • bob1029 5y ago
    Server-side rendering is something that has been tragically overlooked by a lot of teams. With no amount of client-side javascript could you ever hope to build something that brings fresh business data to a customer's eyeballs faster than if the server simply delivers the final DOM on the initial page request. Our Blazor web apps are running in server-side mode, and they are some of the fastest web applications that we use on any given day. Server-side doesnt necessarily always mean full page reloads upon interaction. Websockets are pretty cool. Hackernews is the only other website that feels approximately as fast to me.
    • marcos100 5y ago
      Is it scaling well? Do you have a lot of concurrent users? I'm thinking o using blazor server in a production app, but the latency and higher costs may be a problem. Wasm is not ideal for me because of the high initial payload.
  • adreamingsoul 5y ago
    Apologies for the typos.
• root_axis 5y ago
  This blog loads 2mb of scripts, and if you disable JS you can't leave a comment or even read any comments. Personally, I don't have a problem with this, but I'd have expected a blog hosting an anti-js essay to be less dependent on JS. The author notes in the noscript block that using disqus is part of hosting a static blog, but that definition of "static" is an implementation detail - i.e. a convenience for the developer - but from a user's perspective the result is identical to rolling your own js comment system, the site doesn't work if you disable JS, thus calling into question the value of building a "static" website, especially in the context of an anti-js essay. The author could have instead supported non-js comments, but when the rubber hits the road they appeal to the same developer convenience and UX benefits that typical js developers espouse.
  • duxup 5y ago
    I feel like I sympathize with a lot of the various JavaScript rants in a way … but I’m not convinced that many of the blogs about it (that now feel like years old spam) are actually practicing what they preach or have ever waved the magic wand they want to exist. I’ve yet to see a real guide from someone building an even moderately complex site and moving away from these terrible frameworks and “unnecessary JS”. In the end most of these boil down to “I wish other people would build their sites the way I want them to” without much consideration of how / why a site is the way it is in the first place.
    • deltarholamda 5y ago
      Way back, Conventional Wisdom was "build the site so that people with JS turned off could still use it." This was great advice in 2001, but it's pretty hard to do now. You have to choose what is, and what is not, convenient and/or appropriate for the end user. And that's pretty hard to determine, as there are more varieties of "end users" than atoms in the universe. Plus, even if you're really careful and make something that is judicious with JS, phone users come in and blow everything up. For example, leaving a review could be done JS free buy opening a dedicated review view, and if the end user needs to refer back to the product, they can open a new tab. It's not so easy with a phone, unless they have really strong phone browser kung fu. I would have thought that by now we would have settled on broad conventions for most things so nobody would be inventing all new ways of doing the basics. Instead is seems like things are proliferating. If there are any standards, they're top-down things from Big Corporations like Twitter or Google, because they have the muscle to force everybody to use their conventions and like it.
• bern4444 5y ago
  This is a big reason I’m really enjoying using Remix. They by default aim to make building JS less apps super easy through their framework. And of course you can progressively enhance your app with JS if available.
• Devasta 5y ago
  No one asks if Excel or Hearthstone or Git or other desktop applications have progressive enhancement, it's unfortunate but these days no one should be asking it about web pages either. The web is an application platform, it stopped being about documents years ago. Whatever you may feel about Xforms, its spec was published nearly 20 years ago and even now HTML forms still cannot do something as basic as a PUT request without JS or workarounds. It's clear that browser vendors expect you to use JS for basic functionality, and for document distribution you'll be using PDF anyway so why try to pigeonhole the web onto something it is not? What's to be gained by pretending otherwise?
  • crabmusket 5y ago
    > for document distribution you'll be using PDF anyway This is true and it makes me really sad. HTML in particular, and the web broadly, is really good at document presentation and distribution. I see PDFs every single workday that should have been a tiny, readable, mobile-friendly-by-default HTML file.
  • bo1024 5y ago
    > The web is an application platform, it stopped being about documents years ago. No, it's both. The problem is people not knowing which type of site they're creating and making an app when all they need is a page.
  • goatlover 5y ago
    Weird, because I still look at plenty of regular websites that aren’t applications. And reading on the web is much better than a PDF.
  • wackget 5y ago
    > No one asks if Excel or Hearthstone or Git or other desktop applications have progressive enhancement I do. I stopped "upgrading" most applications years ago because they only became worse with each version. Excel probably peaked in 2003, arguably 2010. Anything beyond that is frustrating ribbon-UI garbage IMO.
  • danShumway 5y ago
• cookiengineer 5y ago
  I recently started to fork webkit to make it a Webview with a reduced attack surface. [2] The most interesting part was the Quirks.cpp file [1] that contains literally randomized css classnames inside the web browser code because a major website was so shitty and spec violating in their implementations. I mean, fixing a website in a browser source code...this shit got out of hand real quick yo. The problem with all those drafts is that Google keeps doing their own thing, and others are forced to try to catch-up or implement the same bugs/quirks that chromium does. Everything is rushed so QUICly that even Microsoft gave up at some point. And at some point in the past google realized that they can own the web if they own the Browser. And that's what they effectively do now, because the competition isn't really a competition at all anymore. [1] https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Quirks.cpp https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa... [2] https://github.com/tholian-network/retrokit https://github.com/tholian-network/retrokit
  • MarkSweep 5y ago
    Microsoft took a somewhat similar approach with their “ Super Duper Secure Mode” in Edge. It disables the JIT in the V8 JavaScript engine to reduce the attack area of the browser: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
  • riskneutral 5y ago
    You would think that they would have at least have made it into a configuration file, instead of literally hard coding rules for specific website domains directly in the browser rendering engine C++ code?
    • tom_ 5y ago
      But why would they make it a config file, when they can just add it to the code? Config files are like code, but even more shit. You never get the full set of functionality that you get with code, the compiler doesn't check your work, code navigation can't help you, and there's no debugger.
• wackget 5y ago
  Finally. I am so happy someone else noticed how much of a garbage fire Twitter is when you limit (not even block) JavaScript. I use uMatrix and a hardened Firefox profile so I notice pretty quickly if websites are poorly made. Spoiler: the vast majority are, and the big players like Twitter, Facebook, Google, etc. are absolutely the worst offenders. But Twitter is so frustrating because of exactly what the article's author says: they re-invent everything, including the text in the Tweet box. As soon as you start typing a tweet it gets converted into some horrific swamp of HTML elements which starts to break really fast if you limit JS as I do. At some point the concept of "graceful degradation", which used to be taught as an essential part of high-quality web development, was totally abandoned. I feel like I'm transitioning into "old man yells at cloud" more and more every day, but the web's going down the shitter real fast.
  • deleted 5y ago
    [deleted]
  • kevin_thibedeau 5y ago
    The new YouTube redesign is the best. It now randomly decides you're offline and doesn't bother fetching anything when you click on links.
  • iratewizard 5y ago
    Imagine going into a board meeting with the senior leadership of any one of these companies and saying "we need a major initiative to make our site more accessible to 20 people who block all Javascript and probably have contempt for us." Then tell them how much it will cost.
    • beaconstudios 5y ago
      This is exactly it - by limiting javascript you are choosing to be in a minority of users and then demanding to be catered to. You're just setting yourself up for disappointment. These are businesses - they write code to generate profit. Their support of limited javascript has no impact on profit, so they won't do it.
• Findecanor 5y ago
  > Someone is trying to download a copy of your site to read while away from an Internet connection. This is why I "print" web pages to PDF these days instead of saving as HTML.
• alanh 5y ago
  Similarly, I wrote to urge people who make websites to simulate slower connections: https://alanhogan.com/slow-it-down-gain-empathy https://alanhogan.com/slow-it-down-gain-empathy
• throwaway984393 5y ago
  I tried a bunch of different browsers today on a lark, because Firefox has become the monstrosity it was once created to replace, and new Linux distros just keep getting slower and slower on this aging Core i7-6500U laptop. The browsers included Edge, Epiphany, Vivaldi, Opera, Otter, Palemoon, Netsurf, Dillo. Let me tell you, it was a gas. So many broken pages. Such a wide range of performance and "user experience". Browsing with Dillo was like looking at the internet through an abstract art painting, which was even more striking because I still remember when I could actually browse most websites with Dillo, and now links2 -g (remember how Links has graphics mode?) is literally more usable for browsing the web. Turns out Epiphany is extremely minimal, fast, and renders pages well (and even supports Firefox Sync? that's cool), so I'm gonna try that as a daily driver.
• throw_m239339 5y ago
  Maybe developers need to start testing their javascript heavy webpages on low end phones and computers to realize the terrible impact of javascript heavy webpages and how it's not very "inclusive" since it discriminates against the people who can't afford high end phones or PC? Especially when most administrative tasks now rely on filling forms on the internet, mobile or desktop.
• dehrmann 5y ago
  > I can almost hear the Hacker News comments now, about what a luddite I am for not thinking five paragraphs of static text need to be infested with a thousand lines of script. HN usually hates on misuse of JS pretty hard.
• ronenlh 5y ago
  I believe it’s because programmers write websites, and when you have a hammer everything looks like a nail. With webassembly we might start seeing compiled websites and we’ll miss the good old days of simple JavaScript.