9 ms·

Maybe we could tone down the JavaScript (2016)

• 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
  • mdavis6890 5y ago
    I care! As in the article - I really appreciate the benefits of JS when it's used in useful, tactful ways. But re-implementing a LINK, or a TEXTBOX, or a SCROLLBAR? That's super-duper irritating, and a horrible UX. I hate it. And I hate loading 1GB of JS just so websites can monitor what I'm doing and serve me targeted ads. It really sucks.
  • frizlab 5y ago
    A very good and recent website for learning about Swift do not have a single line of JS :) https://www.swiftbysundell.com https://www.swiftbysundell.com Some people still do care! Admittedly not a lot though.
  • 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.
      • alphabet9000 5y ago
        10 other people upvoted my 'i care' comment; they are here on HN, lurking
      • 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.'
        • corobo 5y ago
          Calling it a cancer is a bit much. I'm just wondering where all the progressive enhancement types went. Also lol I've been Upton'd https://news.ycombinator.com/item?id=27771186 https://news.ycombinator.com/item?id=27771186
      • WesolyKubeczek 5y ago
        They kind of are hanging out on HN, given that a story in such a spirit is being upvoted into the front page once a week or two, but they also seem a bit bipolar in that they swing between wanting to use the internet ascetically and defending the "web is your new OS and TV and it's a good thing!" attitude because they do it for a living, and that 150k is a 150k after all.
        • corobo 5y ago
          Different people have different opinions, let's make 2022 the year we move away from grouping vaguely related people then calling the group inconsistent I've also not seen any recently aside from the one we're in (published 2016), what was the most recent one you recall seeing outside this? E: just realising this comes off a bit snarky after the group quip, apologies. Asking out of legitimate interest not as a gotcha or anything. At this point I've just given up worrying about it thinking it's an outdated opinion and I've not seen much recently to inform it in any direction other than towards JS support being expected
          • WesolyKubeczek 5y ago
            All those yearnings for "the old web", I can amend it to "once every couple weeks". Here's a recent one: https://news.ycombinator.com/item?id=29661935 https://news.ycombinator.com/item?id=29661935 (This page is designed to last, 5 days ago) HN is also my procrastination tool of choice, so it might be I can see articles and manifestos urging for the return to the glory of blogosphere and web 1.0 before they sink down into oblivion. It's like you may grow an impression that on HN, there are always endless debates about notetaking in software and paper. Sure they are there. There's good stuff, too, at least every other day.
  • innocentoldguy 5y ago
    We’ve been migrating our React front end code to Phoenix’s LiveView for any client-side code that requires server interactions, and use AlpineJS for client code that doesn’t. So far, we’ve been really happy with it.
• deleted 5y ago
  [deleted]
• efficax 5y ago
  These complaints are 20 years old now and in the meantime i keep building successful JavaScript heavy applications
  • 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.
  • 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.
  • 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.
• 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.
• 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.
• 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.
• 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.
• 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
  • jimmaswell 5y ago
    Still using JavaScript with occasional jQuery over here.
  • 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]
  • 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.
    • 5y ago
• 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.
    • coffeefirst 5y ago
      No, it’s because it’s stupid difficult to replicate the native functionality exactly, retain accessibility traits, and if you get it perfect, then you have to deal with the fact that different browsers and devices interpret these controls totally differently.
      • Spivak 5y ago
        We’re saying the same thing. The web right now today requires that you reimplement all that functionality from scratch when it should be just inheriting all the behavior from the native control in your custom thing and tweaking the styles or adding some additional functionality.
        • goatlover 5y ago
          This. You should be able to subclass the DOM creation functions to specify your customized version, and have it spit out the custom tag for it.
• 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".
  • throw10920 5y ago
    The author already addresses this in the article: > I think the Web is great, I think interactive dynamic stuff is great, and I think the progress we’ve made in the last decade is great. I also think it’s great that the Web is and always has been inherently customizable by users, and that I can use an extension that lets me decide ahead of time what an arbitrary site can run on my computer. > What’s less great is a team of highly-paid and highly-skilled people all using Chrome on a recent Mac Pro, developing in an office half a mile from almost every server they hit, then turning around and scoffing at people who don’t have exactly the same setup. And later on: > I’m not saying that genuine web apps like Google Maps shouldn’t exist — although even Google Maps had a script-free fallback for many years, until the current WebGL version! I’m saying that something has gone very wrong when basic features that already work in plain HTML suddenly no longer work without JavaScript. 40MB of JavaScript, in fact, according to about:memory
    • root_axis 5y ago
      Doesn't seem to be a JS specific criticism, testing application performance on typical user hardware is a key responsibility of QA regardless of the language or platform.
      • bcrosby95 5y ago
        What is this QA you speak of? This is a really common problem in tech. Smaller companies adopt large company strategies that require more resources than the small company has to do correctly.
• 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.
• 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
• 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!
• 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.
  • idrios 5y ago
    2mb of scripts actually seems impressively small. I'd say kudos to the author for practicing what she preaches.
    • alpaca128 5y ago
      This site here seems to have roughly 8kB of scripts, about 250kB for everything. I'd say that's more impressive than loading the counterpart of multiple novels for mostly the same functionality.
      • johnisgood 5y ago
        Both websites could easily be done without JavaScript. I have built a blog and a site similar (without voting) to this using PHP/HTML/CSS when I was young.
        • alpaca128 5y ago
          HN works nicely without JS. With JS enabled it doesn't need to reload the page when you vote, so it's not necessary but still useful. The problem are most other sites that often don't even load or show any content without JS support, or break in many creative ways. Although for weirdness you only need to disable custom fonts in the browser, and suddenly Reddit's notification button shows the Paypal logo and many websites have random chinese symbols scattered around the UI. And Google Translate looks like you need a translator to use it.
• 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?
  • 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.
  • 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.
  • 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
  • zild3d 5y ago
    this looks like a bug? [0] || domain.endsWith("hulu.com"); should be ".hulu.com", since anyone can register a <*>hulu.com [0] https://github.com/WebKit/WebKit/blob/ce237483d034e41eff8cc51d7f920f43659f3a76/Source/WebCore/page/Quirks.cpp#L189 https://github.com/WebKit/WebKit/blob/ce237483d034e41eff8cc5...
    • CSSer 5y ago
      That is odd. Yet a strict check against “hulu.com” is also included, and YouTube is checked for “.youtube.com” and “youtube.com”. Perhaps this fix was to prevent malicious behavior, so they included anyone who might be phishing or abusing the API in some way? I think someone would have to dig into the quirk itself to find out more.
    • chrismorgan 5y ago
      https://news.ycombinator.com/item?id=26166497 https://news.ycombinator.com/item?id=26166497
    • dleslie 5y ago
• 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.
  • 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.
  • deleted 5y ago
    [deleted]
  • oversocialized 5y ago
    That's because nu-internet isn't meant for us. It is meant for the consuming masses. The iphone really did kill the free (as in freedom) internet.
  • 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.
• 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.