[HN Gopher] Maybe we could tone down the JavaScript (2016)
___________________________________________________________________
Maybe we could tone down the JavaScript (2016)
Author : aluxian
Score : 168 points
Date : 2021-12-27 16:00 UTC (6 hours ago)
(HTM) web link (eev.ee)
(TXT) w3m dump (eev.ee)
| glacials wrote:
| 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]
| ranger207 wrote:
| 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/
| cookiengineer wrote:
| 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/pa...
|
| [2] https://github.com/tholian-network/retrokit
| booleandilemma wrote:
| 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 wrote:
| 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]
| [deleted]
| durnygbur wrote:
| newshorts wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bdcravens wrote:
| 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.
| durnygbur wrote:
| But they how how to connect the Angular injector into the
| service directive.
| jenscow wrote:
| An "Angular developer" would know that.
| jimmaswell wrote:
| Still using JavaScript with occasional jQuery over here.
| holoduke wrote:
| 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.
| nicoburns wrote:
| 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 wrote:
| nullandvoid wrote:
| 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 wrote:
| 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 wrote:
| I flagged it because it's a Well, Actually
| (https://tirania.org/blog/archive/2011/Feb-17.html) that
| makes an unsupported claim.
| [deleted]
| bern4444 wrote:
| 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.
| danShumway wrote:
| 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 wrote:
| 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".
| danShumway wrote:
| Sure it can, but is that the way these companies are using it?
| Are they using Javascript to improve experience and development
| speed? If a Twitter textbox is lagging while someone types,
| then that's a degradation in user experience, and a pretty
| fundamental one. I like autocomplete too, but I also like my
| text box not to lag, and maybe there's a middle ground?
|
| I wouldn't say I'm a "purist" about this stuff, but I do feel
| like at least scripting should make the site feel better, not
| worse. A lot of these sites are really unpleasant to use,
| Youtube swapped over to this single-page model that I'm sure
| was very difficult to build, but sometimes it just breaks
| navigation for me. What fixes it is I reload the page. So it
| feels like, to me, even as someone who has Javascript enabled
| on Youtube, we have gone from an experience where navigation
| never broke for me on Youtube, to a situation where sometimes
| Youtube loses track of the fact I'm online and I need to
| refresh the page, or I hit the back button and it reloads the
| same video. That's a lot of extra Javascript for an experience
| that feels like a step backwards. The old Youtube designs all
| used Javascript, but they also had working back buttons and
| felt just generally snappier.
|
| I went on Google maps recently and tried to quickly copy a
| number of website links for businesses into a text file: right-
| click copy link doesn't work. I can't copy a link for an
| _external_ website, Google Maps is no longer using hrefs for
| literally the primary thing they were designed for.
|
| And for what? It's not faster for me to open the external
| websites, they don't load quicker. I don't get URL previews or
| some crud. It's a link that doesn't work as well, all that's
| happened is there's a click handler that has fewer features
| than the link used to have, and maybe it's easier for Google to
| get a pingback? This isn't an improvement.
| johnisgood wrote:
| YouTube is super slow for me because of all the JavaScript.
| Plus I have to refresh because whenever I click on a link, it
| just takes too long to load, so I click refresh, at which
| point YouTube says I lost my Internet connection, which I did
| not. Sometimes I ended up having with some video with
| comments from the previous one. That, and I hate the "more
| space, less content" trend.
| vbo wrote:
| > Are they using Javascript to improve experience and
| development speed?
|
| Some, yes. This was in the spec sheet for a large ecommerce
| website I helped rebuild with modern(er) technologies.
|
| > If a Twitter textbox is lagging while someone types
|
| That's an implementation issue.
|
| re Youtube, I haven't had the experience you describe, but
| having had to develop the framework side of SPA navigation
| into something robust and useable, keeping the current page
| on screen after the a new url was history.push'ed while
| preloading the data necessary for the next render and
| managing the scroll position, I can confirm it is a pain. I
| expect Youtube has the right kind of resources for the task
| but it happens, probably at a higher rate of bug incidence
| than regular frontend button-broke-the-site issues.
|
| Implementation issues are going to happen whether you use JS
| or not, but I find building with JS and with modern
| frameworks a joy (although a lot of things can be improved)
| compared to server side alternatives. As with everything
| though, this is a matter of preference.
| kaba0 wrote:
| But what's the whole point of rewriting the URL and
| rerendering in JS the whole page? I'm fairly sure that
| browsers are really great at caching, so no additional
| HTML, JS should be downloaded and the change might very
| well be faster with better history and UX if we drop SPAs.
| vbo wrote:
| The overall experience feels (and is) faster as you only
| need to update the DOM, not recreate it from scratch, so
| you're not rerendering the whole page. There's also less
| processing required on the server as you're only
| requesting the piece of data you know will change and the
| response comes back faster. The history API makes going
| back and forth seamless, as if you were browsing the
| "classical" way. But this comes with additional
| complexity which is sometimes not dealt with correctly.
| tommek4077 wrote:
| Only if you use 8k$ Macs. Not for normal people.
| johnisgood wrote:
| Perhaps it is just poorly written, or maybe it is the
| animations that are making it look like it is slower than
| it should be. I created a simple website where I update
| parts of the DOM, and it is super fast. I have the
| opposite experience on known websites.
| nawgz wrote:
| > is that the way these companies are using it?
|
| Since when do large companies do anything that isn't user-
| hostile and abusive? Of course FAANGs are trying to keep
| their walled garden more walled by reducing outgoing links,
| and Twitter's incompetence is legendary
|
| The real question should be if this type of thing is
| improving the web at large or the capabilities we can develop
| "efficiently" on it, and while I would be willing to hear
| arguments either way, I can tell you I use JS/HTML/CSS in
| combination to introduce capabilities that would not be
| palatable without the JS component of that, putting aside
| whether I would be able to develop them as a bunch of
| standalone capabilities. Model editors, graph layouts, plugin
| architectures; we can leverage client machines to do more and
| more, and in a business setting delivering internal tools
| this is a great method of reducing costs across the stack -
| the laptops were already going to be purchased.
| KaiserPro wrote:
| yes, and no.
|
| You could have used the same argument with flash. It looked and
| ran the same everywhere, offered features totally unavailable
| with HTML/CSS and Js.
|
| The point being is that it might work fine on your machine, but
| its not fine for the rest of us. I am lucky that I have a 2013
| retina with a GPU, but even still, there are more and more
| websites that are slow as shit, for no real reason.
|
| when I'm out and about, small website mean faster loading. this
| means that more people can use them without tearing their hair
| out.
| vbo wrote:
| I've seen server-side rendered websites that took several
| seconds to return a page, while not being under any
| particular load. How is that different?
|
| Of course a static html file will load instantly and likely
| not cause any issues, but apples to apples would mean
| comparing dynamic server side rendered websites to dynamic
| client (or hybrid) websites. In both cases, inexperienced
| developers can make a mess of it, including by picking the
| wrong kind of tools to do the job.
|
| I think JS gets part of its bad reputation because of the ads
| (and ad networks) it empowered and the bad practices they
| turned into status quo (reflows, cpu usage, to say nothing of
| in-your-face overlays and that kind of stuff).
| bdcravens wrote:
| Slow loading server rendered would also be a slow loading
| API. At least with a slow server rendered app I as a user
| (not a developer) knows something is happening. A fully
| formed client with a slow backend can give the wrong
| impression that the app is working (unless the developer
| reimplements "loading" feedback that the browser implements
| natively)
| [deleted]
| throw10920 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| root_axis wrote:
| If the software development process lacks QA, performance
| is likely to be the least of their concerns.
| eitland wrote:
| > 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 wrote:
| 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 wrote:
| The big one is seeing the results of data modifications
| instantly without a full page refresh.
| MaxBarraclough wrote:
| How about rich text editors in webmail?
| Nextgrid wrote:
| 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.
| cuu508 wrote:
| Annoying when pasting formatted text. Annoying when you try
| to delete a newline but it deletes an inline image.
| Sometimes tricky to add unformatted text after a formatted
| section (the editor assumes I want to continue the
| formatted section).
|
| Inline images and hyperlinks are neat though.
| vbo wrote:
| Since you mention autocomplete, dealing with forms is a lot
| better from both a development perspective and UX, ie complex
| forms being validated client side (as well as server side, of
| course) and getting instant feedback. Modals. Having slower
| things being loaded after the intial page load resulting in
| the page loading faster (moreso with session info being
| loaded less often in SPAs). Infinite scroll for search pages
| (not the Instagram variety). Basically all "modern" web UI.
| eitland wrote:
| Good points.
|
| I'm still not convinced it is worth everything we lost:
|
| - Instant loading
|
| - Sane page sizes
|
| - Cross browser compatibility by default, including text
| based browsers
|
| - Every page is reasonably safe by default
|
| - CPU is idle after initial page load
|
| - Battery life is great by default
|
| and probably a few more.
|
| I guess a good middle road might exist but I wonder if the
| current situation doesn't mostly serve ad pushers and bored
| developers ;-)
|
| Edits: yes, a number to clarify my points and to make it
| clear that I am open to change my views, at least slightly.
| vbo wrote:
| Agree on all counts except instant loading, you can still
| do server-side rendering (from the same codebase as the
| client) and have the client library bootstrap/hydrate its
| state from it.
| [deleted]
| goatlover wrote:
| I mostly dislike infinite scroll and am irritated when I
| see visual things load after the page loads. I also don't
| see the point in SPAs for regular websites. The modern web
| looks better, but sometimes the experience is worse, at
| least for those of us who were around before. Of course by
| this I don't mean actual applications or games on the web.
| Just standard websites.
| easrng wrote:
| Modals can be done with CSS pretty easily (with either
| :checked and a label to activate the modal or :target and a
| link to activate it or with details/summary etc.), so can
| form validation (the required and pattern attributes), and
| lazy loading (add the loading="lazy" attribute for images
| and iframes). Infinite scroll can't really be implemented
| easily but in theory it's possible with server support
| (I'll make a demo and get back to you).
| easrng wrote:
| Here's the promised noscript infinite scroll!
| https://noscript-infinite-catfacts.glitch.me/
| tarboreus wrote:
| Maybe it's a niche perspective, but as a blind person the
| obsession with JS forms is what makes the web borderline
| unusable for us. While it's not impossible to make an
| accessible experience with JS, people mess it up so often
| that it may as well be.
|
| I honestly think the problem with JS reimplementations is
| that develoeprs assume that they are their audience, or
| that people like them are the only people that matter.
| martpie wrote:
| While I understand the concern, I'm not really sure I buy
| the argument "JS makes accessibility bad".
|
| It is for sure easier to do things wrong, but if you
| check at most of the major libraries for front-end (drag-
| and-drop, routing, dropdowns...), accessibility is built-
| in, and a critical selling point (e.g react-router,
| downshift...).
|
| I think the proportion of front-end developers knowing
| about accessibility is just low, and the result is more
| visible for JS-heavy websites/webapps, but this is imho
| an education problem, not an ecosystem issue.
|
| Having worked in agencies, accessibility was always
| treated as a second-class citizen (by clients or
| managers, not by developers, trying to push for it), and
| clients would often say "let's go live without it", then
| would come back to us asking to finish the job once they
| saw their competitors got sued for having an inaccessible
| website.
|
| So JS may be a catalyst, but not the root of the problem.
| It's our job to push for the importance of it, as we
| pushed for responsive websites a while ago.
| hotz wrote:
| I think sites that fail the accessibility test should be
| shamed into compliance. Possibly like how they handle
| sites that aren't https. I can just imagine how
| frustrating it must be to have an impairment that hinders
| usage of a website. Especially if it might be something
| essential.
| tarboreus wrote:
| It's mostly fine for me, because I'm technical and can do
| some weird thing or use OCR tools I made myself or
| whatever. It's incredibly difficult for the average blind
| person, who is statistically likely also to be older as
| well.
| tarboreus wrote:
| The reality is that the education you're talking about is
| never going to happen. By the time you had 80% of devs
| knowing how to do a11y on JS framework #271, a whole new
| paradigm would have come in. It's because accessibility
| is not a priority that accessible defaults, which almost
| definitionally need to be system- or browser-based, are
| so important.
|
| If you make a form with HTML and style it with CSS, then
| you're 85% of the way there with accessibility, and
| chances are it will be usable if you screw the rest up.
| With JS, even if you're working from a checklist, you're
| much more likely to get somethign wrong. And then there
| are regressions. I kind of believe that you know what
| you're doing, because the kinds of people that hang out
| on HN often do. But will your second-generation
| successor, four years from now, know how to update your
| work without breaking accessibility? Empirically, based
| on the low level of accessibility on the web (improving,
| but still pretty tough going), I'd say "no."
| torstenvl wrote:
| Did you really just tell a blind person they're wrong
| about the effect JavaScript has on web accessibility for
| the blind? Holy crap man.
| jakub_g wrote:
| Side note: basic autocomplete can be done fully without JS
| using <datalist>
|
| https://blog.teamtreehouse.com/creating-autocomplete-
| dropdow...
| eitland wrote:
| Emphasis on basic I think: once you go past what could
| easily be done earlier you still have to use JS to
| configure a datasource to load from?
| [deleted]
| Arthanos wrote:
| 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 wrote:
| it's always doom and gloom on here regarding web dev,
| unfortunately
| corobo wrote:
| 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
| frizlab wrote:
| A very good and recent website for learning about Swift do not
| have a single line of JS :) https://www.swiftbysundell.com Some
| people still do care! Admittedly not a lot though.
| alphabet9000 wrote:
| i care, plenty of other people care.
| corobo wrote:
| Well then I dunno where they hang out cause it doesn't appear
| to be on HN anymore
| eadmund wrote:
| 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.'
| alphabet9000 wrote:
| 10 other people upvoted my 'i care' comment; they are here
| on HN, lurking
| Uranidiot wrote:
| bee_rider wrote:
| 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.
| mdavis6890 wrote:
| 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.
| Rd6n6 wrote:
| 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
| germandiago wrote:
| 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.
| newsbinator wrote:
| > I am not sure what Javascript buys you
|
| https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
| Devasta wrote:
| 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?
| bo1024 wrote:
| > 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.
| crabmusket wrote:
| > 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.
| goatlover wrote:
| 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.
| pmarreck wrote:
| 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
| togaen wrote:
| Yes. Please. Enough with the scripting. It's only gotten worse
| since the article was written.
| akkartik wrote:
| These days Twitter can't even show the 280 characters of a
| tweet without JavaScript.
| efficax wrote:
| These complaints are 20 years old now and in the meantime i keep
| building successful JavaScript heavy applications
| ozim wrote:
| 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 wrote:
| 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.
| scelerat wrote:
| 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 wrote:
| "Assume infinite pipe and ludicrous client resources."
| timeon wrote:
| "a good rule of thumb to follow when designing your own
| controls:
|
| Don't."
|
| --
| https://web.archive.org/web/20021009021738/http://www.iarchi...
| laurent92 wrote:
| And then, everyone has their custom buttons, sliders,
| switches, input fields, and everyone is happier for that...
| goatlover wrote:
| Except for when those custom controls fail to implement all
| the features of the built-in ones, as the article details
| from various popular sites, at least back on 2016. But
| maybe at the end of 2021, all custom stuff is fully
| accessible and reimplements everything.
| Andrew_nenakhov wrote:
| Now those are controls I haven't seen in a long time. Long
| time.
| Spivak wrote:
| 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.
| pjc50 wrote:
| The problem is, as always when talking about cross-platform
| development, is that you can have consistent widgets OR
| native widgets, because the native platforms have different
| look, feel, and interaction standards.
|
| Would it be great if everyone on the frontend could get
| together and agree what the native-to-browser widgets should
| look like and how they might be customized? Yes. Would the
| three warring browser manufacturers change their platforms to
| make web development easier and lighter for everyone, at the
| cost of platform uniqueness? No.
| dev-3892 wrote:
| 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 wrote:
| 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.
| jonahx wrote:
| Not a downvoter but...
|
| > Pontificating about how they should just change their
| notion of right misses it completely.
|
| The ask isn't to change their notion of right, but to
| understand that (yes, sadly) there is a tradeoff between
| "usable but ugly system components" and "pretty but janky"
| bespoke components, and they're making the wrong choice.
| Shacklz wrote:
| > they're making the wrong choice.
|
| If what feels like the vast majority of them are making the
| same "wrong" choice, we should probably think about ways to
| make that choice more "right", because clearly, the current
| approach isn't working
| Spivak wrote:
| This is my approach. To me the ask for custom components
| from designers is extremely reasonable. The fact that
| it's so hard to get all the edge cases right on the web
| is a failing of the tooling not the ask.
|
| At some point we have to climb out of the trenches and
| introspect why the most treaded path in web design is the
| one with the rickety bridge and spike pits when we the
| software engineers are the ones who lay the bricks.
| scelerat wrote:
| It's not just appearance but also behavior. There are
| differences across browsers, OSes, and devices in how UI
| widgets work and inevitably the "custom" approach is a
| compromise in favor of the PM's personal workstation.
|
| And lest it be overlooked, the appearance of those widgets
| themselves, is a feature. They are easily identifiable by
| users of that platform as being something they can interact
| with and expect a predictable set of outcomes.
| ehnto wrote:
| To be fair to "the system", it was developed over decades,
| much of it before design was even a consideration, and almost
| all of it from a time when modern designs would have been a
| pipe dream on given device resources.
| coffeefirst wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Nextgrid wrote:
| Lack of technical solutions isn't the only issue. System
| controls (well most of them - recent Windows and macOS seem
| to be regressing) have decades of refinement and battle-
| testing behind them and users are familiar with them. You're
| not replicating all of this alone regardless of how much
| money or years of experience you have.
| soperj wrote:
| Literally stepping off the shoulders of giants and
| wondering why you're less capable.
| mattmanser wrote:
| You and the parent are totally missing the point.
|
| Use the system tools. But make the look of the system
| tools customizable.
|
| System tool. Customizable look.
|
| That's what _should_ be available. But even today you can
| 't consistently change something as simple as a scroll
| bar or a checkbox.
|
| Which, even worse, are by default styled differently on
| different browsers.
| trgn wrote:
| I think the parents are _exactly_ getting the point.
|
| Separating look&feel from functionality isn't that easy.
| In any kind of UX, they are bound to various degrees,
| depending on the use-case.
| radicalbyte wrote:
| This was the entire selling point behind Windows
| Presentation Foundation:
|
| https://en.wikipedia.org/wiki/Windows_Presentation_Founda
| tio...
| ninkendo wrote:
| Customizable look and feel means lack of consistency, and
| confusion as to why things look different without good
| reason.
| levmiseri wrote:
| Consistency is overrated. Context is what matters. And
| context often requires customized controls.
|
| We will never live in a world where an abstract concept
| like a checkbox can have an 'assigned' specific visual
| affordance that doesn't allow for adjustments. Such
| thinking is stuck in the past and won't allow for
| new/better UI paradigms.
| Shacklz wrote:
| This purist talk about how everyone should stick to some
| system standard or whatever really needs to die. It's not
| working. Nobody is doing it.
|
| Everyone, literally _everyone_ is running their own
| thing. Name me big company that doesn 't roll their own
| design system.
|
| Preaching purism really doesn't help anyone, let's just
| accept reality as it is, and stop chasing some utopian
| dreams that just won't ever materialize (and if only
| because it would make a lot of jobs and professions
| useless, overnight, and there's too much inertia for that
| to happen).
| Spivak wrote:
| We're saying the same thing. The web's current tools
| requires devs to reimplement all that functionality from
| scratch, which isn't gonna happen, when the ideal solution
| would be to start with the battle tested native control and
| then tweak from there to fit the design.
| Nextgrid wrote:
| My point is that by tweaking the looks of the existing
| thing you are breaking standards users are used to or
| might be causing issues you're not even aware of (bad
| color choices for colorblind people for example) even if
| the behavior/functionality of the control is unchanged.
| johnisgood wrote:
| Maybe you can introduce smaller changes over a longer
| period of time? I dunno. Would not Windows users be stuck
| with that very old look if there were no changes? I mean,
| is this actually what you are favoring? That said, I
| cannot stand the trend of UI/UX on desktop being so
| touch-friendly, along with more padding and/or increased
| font sizes and less content, too.
| tibbar wrote:
| I think this is an important concern, but not a
| disqualifying one. There is already a lot of variety in
| the space of controls, for example compare browser
| controls to the Office Suite to native OS, it's a big
| spectrum. When controls are customized correctly they
| become more usable within the context of the app because
| they are sized consistently, line up with the content
| grid, follow visual cues from the rest of the app, etc.
| ryandrake wrote:
| But, once you tweak it, it is no longer the same "battle
| tested" thing. Even little tweaks. App developers should
| do themselves a favor and just stick to the standard
| controls that have decades, maybe centuries of tester-
| time working out the kinks and edge cases. A medium-size
| company's UX expert's "restyling tweaks" are unlikely to
| make the control better.
| tibbar wrote:
| This position doesn't make sense to me. Certain
| customizations to the native control (which is the ask
| here) are already available, such as adding padding to
| input controls, increasing the font size, changing the
| width. You can even change the border color and the
| border radius and the background color for some controls!
| Some of these turn out to be necessary functional
| changes, and some of them -- imma say it -- are obvious
| and important adjustments so that your app looks
| consistent and everything lines up properly.
|
| To think that there's no room for variation in the design
| of form controls, given the broader context of a design
| system for app, is just a lack of imagination. I
| guarantee you that the people who design the operating
| system form controls (which change every couple years)
| have all sorts of ideas, and they end putting out one
| possible, relatively minimal option from many good
| designs they considered.
| kaba0 wrote:
| Please have a look at any OOP desktop framework from like
| the past 3 decades. It is not a difficult concept -- one
| is free to overload the render function, while the
| functionality will remain the very same, like getting
| focus with tab, activate to space, whatever.
| [deleted]
| inasmuch wrote:
| As a product designer, I am and have long been looking for a
| company that will enable--hell, allow--me to design software
| that employs system standards. I can't imagine I'm the only
| one.
|
| Problem is, most leadership doesn't care about usability unless
| it affects marketability, which is less and less likely as
| people (users) become more comfortable with and accustomed to
| hopping between needlessly proprietary workflows and
| abstraction of crucial processes.* Often (usually?) designers
| also don't, to be sure, but those like myself who do care are,
| like devs, up against unreasonable speed demands and
| interruptions that make it difficult to do our best, most
| thoughtful work. And though it may seem like design is higher
| up the totem pole, perhaps because it's usually upriver from
| dev, in my experience, most companies see designers as whiny
| graphics monkeys, just as they may see devs as whiny code
| monkeys.+
|
| It's significantly more difficult and time-consuming to design
| novel functions and flows that conform to or complement
| existing standards than it is to draft a new system that need
| only make internal sense and may wantonly disregard the
| environment around it. This is why people like Electron, right?
| This is why people liked the internal combustion engine.
|
| * I'd like to see a study on how this kind of
| acontextualization of work tasks might exacerbate burnout.
|
| + How many companies are actually defined by great design these
| days (versus, say, great functionality)? Not even Apple seems
| to care about that anymore, as they seem eager outpace their
| software with their hardware, rather than creating any iconic
| or lasting designs. As "product design" has evolved to include
| software products, the discipline and its output have become
| just as mutable, and therefor disposable, and therefor 'not
| worth' the effort necessary to make good things, let alone
| great things.
| superkuh wrote:
| >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 wrote:
| Article is from 2016 - should be in title!
| adreamingsoul wrote:
| Lately I've been limiting my JS usage only been use vanilla
| JavaScript for tertiary functionality and server-side rendering
| for everything else.
| bob1029 wrote:
| 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 wrote:
| 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.
| [deleted]
| root_axis wrote:
| 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.
| ljm wrote:
| I think that it's a bit of a cop-out to call your site static
| in instances like this. You've outsourced computation to a 3rd
| party as well as the user's browser, as opposed to doing it on
| your own server. It would be dynamic if you cobbled a comment
| system together with some CGI scripts and an SQLite database
| and some server-side includes, and it's still dynamic if you
| abstract that into a runtime dependency on the client, because
| the content of the page is going to be different whenever you
| refresh and new comments are made.
|
| The difference between the server-side option and the
| outsourced one is that the outsourced one is probably also
| going to soak up and resell a lot of data that you probably
| wouldn't have captured yourself.
| philistine wrote:
| Yup. I say down with comments on websites! Let the big boys
| of websites like this one take care of comments.
| nicbou wrote:
| Removing comments on my website was a great idea. Instead,
| people email me and I don't have to moderate anything.
| [deleted]
| idrios wrote:
| 2mb of scripts actually seems impressively small. I'd say kudos
| to the author for practicing what she preaches.
| alpaca128 wrote:
| 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 wrote:
| 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.
| purerandomness wrote:
| I think you misunderstood the entire point of the author,
| especially since you have called it an 'anti-js essay'.
|
| From the article:
|
| > Accept that sometimes, or for some people, your JavaScript
| will not work. Put some thought into what that means. Err on
| the side of basing your work on existing HTML mechanisms
| whenever you can
|
| As you have observed, disabling JavaScript does not make the
| site stop working entirely for no reason. It degrades
| meaningfully, and the author put thought into _what that means_
|
| Moreover, _enabling_ JS does not break browser functionality
| you 're used to.
|
| That's the entire point.
| root_axis wrote:
| > _As you have observed, disabling JavaScript does not make
| the site stop working entirely for no reason._
|
| Such is the case for most JS sites, the site typically
| doesn't break "entirely", but I consider being unable to post
| or even _read_ comments to be a major functional breakdown.
| Comments are non-interactive text, there 's no justifiable
| reason why I should need JS to read them.
| rauhl wrote:
| > I consider being unable to post or even _read_ comments
| to be a major functional breakdown.
|
| For a blog? I disagree, because the point of a blog is to
| read the _author's_ comments, not those of third parties.
|
| > Comments are non-interactive text, there's no justifiable
| reason why I should need JS to read them.
|
| I kinda agree. The issue is that it is very rare to find a
| static site generator which can interface with a dynamic
| comment storage. To be honest, I don't know that one
| exists, although of course it is completely possible. I can
| understand as a pragmatic matter why someone might have a
| static blog, want to add comments and not be willing to run
| his own dynamic comment system, esp. if that would entail
| _writing_ said system.
|
| All that being written, it would be awesome to have a
| static site generator which _were_ called by a hook in a
| dynamic comment server. I actually would like to write one
| someday!
| crabmusket wrote:
| This seems to be exactly how Gatsby et al work, by
| pulling in "dynamic" content over an API at build time.
| I've never seen this being used to re-render a site based
| on third-party changes like comments, but it's popular to
| pull data from a first-party system like a CMS containing
| e.g. the blog posts.
|
| Though I wonder if the prevalence of programmable edge
| networks will leapfrog that before it becomes really
| mainstream, and allow site owners to add a small bit of
| edge dynamism to pull dynamic content in without client-
| side JS.
| root_axis wrote:
| > _For a blog? I disagree, because the point of a blog is
| to read the author's comments, not those of third
| parties._
|
| The author has posted several comments in the comment
| section, so even by your definition the blog fails to
| meet functional standards. However, IMO, the distinction
| between the author's comments and user comments is
| arbitrary, both are text meant to be read by readers, and
| those readers without JS are missing a ton of discussion
| that's happening in the comments, including discussion
| with the author. There's actually more to read in the
| comment section than in the blog post itself.
|
| > _All that being written, it would be awesome to have a
| static site generator which were called by a hook in a
| dynamic comment server. I actually would like to write
| one someday!_
|
| I have actually seen a system like this implemented at
| company I used to work for. A posted comment would be
| stored in a sqlite database before a request to rebuild
| the comment section is fired (as a partial, to avoid re-
| rendering the whole page/site), subsequently dumping the
| new build into the CDN (with some debounce logic to
| throttle high comment traffic). The rebuild was typically
| sub-second and performed very well.
| tommek4077 wrote:
| It isnt. They always show "This app needs Javascript
| enabled" even if its a simple blog.
| [deleted]
| duxup wrote:
| 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 wrote:
| 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.
| chubot wrote:
| Yeah I'd like to see that too. One site I think that does a
| fantastic job is sourcehut. It actually has a little bit of
| JS, e.g. for the builds page to stream results, but it's fast
| and light, and measured to be fast.
|
| And it's a pretty big and functional site.
|
| https://sourcehut.org/
|
| https://forgeperf.org/
|
| I've looked at the source code and it's very straightforward
| Flask apps and Jinja templates, and hand-written JavaScript.
|
| https://sr.ht/~sircmpwn/sourcehut/sources
|
| For people who don't remember, the result is very similar to
| how Google looked ~15 years ago -- Google News, Froogle,
| search results, etc. The underlying tech was different, but
| the result is the same. Google just used C++ and the "google-
| ctemplate" language.
|
| ----
|
| I wish that every food ordering app was written like this.
|
| I mean all they are doing is displaying a list of pictures
| and then providing a checkout experience -- it's literally
| eBay from 1998, but 1000x slower.
|
| It would also be like 10x faster than a native app on phone
| if it were written like that.
|
| In fact Google has a lightning food ordering app right on the
| search results page that proves the point! However I tend not
| to use it because I don't think it's good to let the search
| provider "hijack" the traffic intended for restaurants. i.e.
| presumably the restaurant will put their preferred vendors on
| their sites, which is almost never Google, and is instead
| some really slow and janky app :-(
| kolinko wrote:
| The comments on the blog are managed by Disqus. If he wanted to
| do them without JS, he'd need to build a commenting system all
| by himself - and that's almost impossible nowadays because of
| the spam issues.
|
| Everything else on the site seems to uphold to his principles.
| mperham wrote:
| She
___________________________________________________________________
(page generated 2021-12-27 23:00 UTC)