39 ms·

Things you don't need JavaScript for

• rado 5y ago
  Hover doesn’t work with touch screens and I wish <details> state was manageable by CSS for responsive pages.
  • john-doe 5y ago
    Check this out, it adds really useful enhancements to <details> https://github.com/zachleat/details-utils https://github.com/zachleat/details-utils
• scim-knox-twox 5y ago
  Also: http://youmightnotneedjs.com/ http://youmightnotneedjs.com/ And: https://kryogenix.org/code/browser/everyonehasjs.html https://kryogenix.org/code/browser/everyonehasjs.html
  • StevenWaterman 5y ago
    These are great - I've bookmarked the 2nd for when I inevitably get asked the question!
  • Sohcahtoa82 5y ago
    The first link needs a section on Smooth Scrolling. Here's an HTML and CSS snippet to implement smooth scrolling: "" That's it. An empty string. In other words, nothing. It's already implemented in the browser! Wasn't that easy? Now stop wasting time on an JS-based implementation of smooth scrolling that breaks in at least 1 browser.
• shireboy 5y ago
  Sidebar and sticky examples don’t work on iOS safari on iPhone. I’m pretty sure sticky can be made to work. Sidebar would need a different technique since “:hover” is not a thing there. In general I like the concept of not using js unless you have to, but it’s important to consider mobile.
  • jdefelice 5y ago
    The sidebar work for me with a long press. I would have know to try it if I didn’t read your comment, it isn’t very obvious or intuitive.
  • StevenWaterman 5y ago
    The sidebar example is my fault for forgetting to make the menu itself tab-accessible (ie focusing the sidebar will trigger the `:focus-within` selector rather than just focusing the links or hovering). I'll update the example so hopefully it should work. As for the sticky example, I'm really not sure what's going on there. It certainly seems to be supported. https://caniuse.com/css-sticky https://caniuse.com/css-sticky
  • charcircuit 5y ago
    Same on Firefox on android
  • captn3m0 5y ago
    The SVG didn’t animate for me in Firefox/iOS.
  • vimax 5y ago
    The sticky was hard to figure out. You have to scroll down in the example frame, but the scroll bar is hidden and there's no indication of more content.
• simion314 5y ago
  CSS animation look cool but do we have a way to debug css performance issues? Last time when I had to fix this I found not tool so the solution was look at the CPU usage and remove the elements you think are problematic until CPU usage goes to 0%. Is super easy for someone to screw things up and cause a 25% CPU usage and not notice it on his dev machine. After this incident my rule is to always triple check in code reviews any animation that has "infinite" in it (though I am mostly a backend dev)
  • Etheryte 5y ago
    Chrome devtools have a Performance tab that's extremely useful for this, as well as other performance issues. It includes repaint information, CPU usage and more, and makes it relatively easy to find the culprit. That said, as a frontend developer I very much agree that CSS animations are a great footgun. A testament to this is running into laggy and slow animations on random webpages, oftentimes ones owned by big companies. Of course, they can be done well too, but not without great care.
    • bryanrasmussen 5y ago
      Firefox Developer also has a performance tab, can't remember if the normal FF build has.
    • simion314 5y ago
      I know about that tool, but for JS you can dig and find the hot spots with painting operations you could not find what css triggered them. I could use them to identify JS code that did too much DOM changes and optimize them though.
      • Etheryte 5y ago
        If you make a performance recording of the page, you can then select the main thread, open event log, and filter by "Layout". You won't get a summarized overview, but you can see the layout root for each entry, which will show you what caused the layout update. For complex pages with numerous parallel animations, you might need to filter this data more, but for example in the article we're discussing right now, manual checking quickly reveals where the layout updates are coming form.
• jesprenj 5y ago
  I love how a page criticising web developers is unreadable on my phone because one centimeter of text is cut off on the right (:
  • Traubenfuchs 5y ago
    It's absolutely unusable on my iPhone with increased UI size. https://imgur.com/a/Eroiblj https://imgur.com/a/Eroiblj
    • cphoover 5y ago
      same on samsung note 9
  • StevenWaterman 5y ago
    I'm sorry about this, and don't have any excuse for it. I'm working on fixing it now. Edit - It should be fixed now. GitHub Actions seems to be having some issues so it took a long time to deploy
    • geoduck14 5y ago
      Hey man. Just chill. We're a bunch of opinionated techies that like to banter - but we don't sign your pay check or teach your kids or do anything that's actually beneficial for you. You don't owe us an excuse
    • jamal-kumar 5y ago
      lmao so many people I know have amazing projects and work they're afraid to post here because they don't want a massive audience of highly technical people picking at the bugs
      • StevenWaterman 5y ago
        I know there's no malicious intent, I'm just sad that such a basic thing is preventing people from reading the post. I'm happy when people are picking holes in the content - that's all valuable discussion we wouldn't have had otherwise, but I don't think anyone's going to argue in favor of making your website not fit on a mobile screen!
• lysecret 5y ago
  I mean I hate JS as much as the next person. Also, for my blog I wanted to use as minimal JS as possible. But when it comes to a sidebar I don't think adding a few lines like this is soo bad. <script> const button_close = document.querySelector('#menu-button- close'); const button_open = document.querySelector('#menu-button- open'); const menu = document.querySelector('#menu'); // Menu button_close.addEventListener('click', () => { menu.classList.toggle('hidden'); }); button_open.addEventListener('click', () => { menu.classList.toggle('hidden'); }); </script>
  • bandie91 5y ago
    would not < details > tag[1] solve it? [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details#a_simple_disclosure_example https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...
  • StevenWaterman 5y ago
    I'd be a little concerned with using this in production, because it would make your menu completely unusable for anyone without JavaScript enabled. As with most things, the ideal is somewhere in the middle - use these techniques to get a baseline, then embrace progressive enhancement and round off the rough edges with JavaScript
    • krapp 5y ago
      About 98% of people have javascript enabled, and most of the rest will unblock your site if they need to use it anyway. The remnant who absolutely refuse to run javascript under any circumstance aren't worth worrying about unless you want to appeal to them, specifically, as a demographic.
      • StevenWaterman 5y ago
        From further down the page, this is relevant https://kryogenix.org/code/browser/everyonehasjs.html https://kryogenix.org/code/browser/everyonehasjs.html
• maybe_pablo 5y ago
  My browser didn't remember the dark mode checkbox state after reloading.
• rambambram 5y ago
  Can only agree with this article! Details/summary, position sticky and the checked toggle are my favorites (position sticky needs some attention though). It pays of to check for new HTML and CSS tags/functions once in a while. Have been a (web)developer for some years now, and it's only since recently that I found all these things. The amount of JS that I could ditch was astounding to me. Just liberating.
• cphoover 5y ago
  You dont need Javascript to add margin on a website, yet this website cuts off the text on mobile.
• fourseventy 5y ago
  unreadable on mobile
  • mod 5y ago
    Chrome on Android: unreadable. The left side of the paragraphs, somehow, is cut off. I cannot scroll sideways.
  • kaeruct 5y ago
    It's unreadable on desktop Firefox!
• elpocko 5y ago
  Meanwhile, many websites decide to deliberately hide their content from you if you don't allow them to run JS. Not out of necessity - purely out of spite. Like a div that obscures the content, or styling that makes content invisible by default and requires JS to become visible.
  • account42 5y ago
    I assume it's more out of lazyness / apathy than spite in most cases - e.g. they use custom fonts and then only unhide content using JS once the fonts are loaded. Not really an excuse, just don't think its people being actively malicious.
  • duxup 5y ago
    > hide their content from you if you don't allow them to run JS. Not out of necessity - purely out of spite. Like a news site?
    • elpocko 5y ago
      From my daily experience it's more small blogs and the likes than big sites. The kind of site that you only visit once because they got linked on HN.
    • marcosdumay 5y ago
      Recently there appeared a philosophy of "let's hide the loading content so it doesn't reflow". I've seen a few sites requiring javascript that can only be explained by it.
  • ironmagma 5y ago
    Blame the business folks, because this is almost certainly due to analytics.
• onion2k 5y ago
  I really wish developers would just ask themselves if a feature is actually necessary before trying to create it without JS For example, you can make an accordion menu with plain HTML, but should you? Accordions are horrible. They just hide information. 20 years ago an accordion was a design pattern that made a bit of sense - scrolling meant moving the mouse to the scrollbar or pressing Page Down which took you out of the reading flow on the page. Not to mention screens were tiny so a long page didn't work very well. Today though, users can scroll easily with a mouse wheel or a swipe, and screen are much bigger. Just show the text and let the user scroll past it. CSS-derived dark mode is another example of "Yeah, you can, but it's a bit rubbish." The site won't retain the user's choice if you use plain CSS which is pretty horrible. Either use JS, or use your build step to bake two versions and serve them on different URLs like "/dark/page-1" and "/weird-bright-mode-wtf/page-1". The off-canvas menu and sticky bar are quite nice, but again it does feel like developing something that could be better without any clever CSS or JS through sensible design choices.
  • throwamon 5y ago
    On accordions, I'm of the opposite opinion... sort of. I love outliners such as Workflowy and Dynalist. I'd like most textual content to look more like them. It's really great being able to expand/collapse/zoom into entire sections, link from one section to another, etc. You can expand everything with a single command and you should also be able to flatten the tree and read it like a normal page if that's how you like it. Regular pages with accordions are just a poorer version of this. I'd like it to go all the way in that direction.
    • franciscop 5y ago
      Could you point to a specific example please? Or screenshot if those are apps. I'm curious about trying some accordion pattern that people actually _like_.
      • throwamon 5y ago
        Sorry, I can't send screenshots right now, but you can easily find some by googling (yes, they're apps). There's nothing much to it, it's just collapsible nested lists. And to be clear, I think most people would be weirded out by a blog post that looked like that. I think making the "flat" view the default one but adding a toggle for a hierarchical view would be the ideal UX for me, but I bet this is a very niche preference and it wouldn't be worth it for a larger audience.
• Scarblac 5y ago
  But I don't really want that. I hate that my code is spread out over HTML, CSS and Javascript files, it makes it hard to see the whole. Javascript offers ways to do everything only in Javascript. That's wonderful.
  • Grollicus 5y ago
    I do agree with you. I'd go even further and say using vue helps build more maintainable websites in that it encapsulates components and thus keeps related things together. Also that it provides a separation of the data model and how it is displayed, so one can reason about both things separately. But, all that are not things this article is about. They just name five specific things you meet regularly in web design and that don't need JS anymore. And in that case it's valid as the browser will generally do things better than you do yourself, be more accessible and integrate better into different platforms / OSes.
  • StevenWaterman 5y ago
    Off-topic, but this is a big reason why I love using Svelte. A `.svelte` file contains the HTML markup, JS code, and styling for that component. As an example: https://github.com/stevenwaterman/Lexoral/blob/stage/frontend/editor/src/audio/Playback.svelte https://github.com/stevenwaterman/Lexoral/blob/stage/fronten...
• axiosgunnar 5y ago
  > doesn't overdose on javascript > overdoses on css instead
  • o_m 5y ago
    Separation of concerns isn't a bad thing
• jdrc 5y ago
  This is what we need , more native functionality instead of insane levels of JavaScript. But we also need sane standards instead of more for no reason. How many CSS units are there now? 20? And things like css grid just don't look right. We need to make html and the web approachable by the common man, again
  • ironmagma 5y ago
    All the things that used to work in HTML still work, aside from some trivialities like <blink>, so it’s not like it stopped being approachable for simple things. The trick is, people want less-simple things now.
    • phkahler 5y ago
      I thought HTML frames were considered bad practice something something Google?
      • ironmagma 5y ago
        There are a lot of things that are a bad practice. But they still work, for example: https://way2tutorial.com/html/frame/frame_example2.html https://way2tutorial.com/html/frame/frame_example2.html
• kaeruct 5y ago
  I can't seem to get the firework example working. Is this supported on Firefox?
  • StevenWaterman 5y ago
    It definitely works on Firefox, that's my main browser. Have you disabled animations in your OS? I have it set up to respect your accessibility settings - if you have indicated that you prefer reduced motion, it won't play.
• theden 5y ago
  What about compatibility with browsers? CSS can do a lot that JS can but sometimes it just won't work on all browsers. For example the SVG animation on the page doesn't seem to work for me? Also for animation it depends on the use-case. Complicated animations are better suited for JS than CSS https://developers.google.com/web/fundamentals/design-and-ux/animations/css-vs-javascript https://developers.google.com/web/fundamentals/design-and-ux... I recall trying out a complicated SVG animation and it used a decent chunk of CPU time
  • ajmurmann 5y ago
    Yep, I tried the animation in mobile safari and mobile brave. Neither browser animated it and in brave it was a black blob with colored lines on it's edges.
  • StevenWaterman 5y ago
    Have you disabled animations (aka 'prefer reduced motion') in the accessibility options of your device? I check for that and disable animations on the site. If not, then I'd be interested in the device you're using, to try and debug the animation. You're correct though, SVG animations can be resource-intensive. There's an interesting discussion elsewhere in the comments about how best to use the developer tools to debug poor performance in animations, but it can be a struggle.
• timwis 5y ago
  A bit ironic that 4 out of the 5 don't seem to work in Firefox on macOS.
  • samwillis 5y ago
    Pretty sure its not just Firefox, I'm on a Mac and it doesn't work in Safari or Chrome. My guess is somethings broken... Only the accordion is working.
  • kevincox 5y ago
    When I first loaded the page it was broken. Reloading make it work on Firefox on Linux.
• chrismorgan 5y ago
  1–4 are good, but 5 is not. The checkbox hack is decent in a few places (though I’d say <details> is normally a better choice now, and the checkbox hack should be accompanied by certain ARIA properties and augmented with some JavaScript to twiddle properties as it’s used), but dark mode is not one of them. The checkbox hack is only suitable for transient state that you actively don’t want to persist over page loads. Probably the most popular historical application of it is hamburger menus (but <details> or `:hover, :focus-within` are better for that now). I think a more reasonable solution for dark mode is the media query (prefers-color-scheme: dark), following the browser preference by default and augmented by JavaScript to allow overriding that. https://chrismorgan.info/blog/dark-theme-implementation/ https://chrismorgan.info/blog/dark-theme-implementation/ describes my own implementation, which is the most comprehensive and efficient client-side-only implementation that I know of, as perfect as it’s possible to be while being client-side-only and without getting into service workers.
  • hnlmorg 5y ago
    I use 5 for the hamburger menu on one of my sites. It works really effectively too, means I could build the entire site without writing a single line of Javascript (I've got nothing against Javascript but given it's ostensibly just a collection of man pages I did question the worth of adding any Javascript)
    • mwcampbell 5y ago
      Wouldn't details and summary be better for a hamburger menu, assuming you can style them the way you want? Using a checkbox seems problematic for accessibility; a screen reader user certainly wouldn't expect to open a hamburger menu by checking a checkbox.
      • hnlmorg 5y ago
        The hamburger is only needed for the mobile view (to show/hide navigation that is always present on the desktop view) so there shouldn't be any issues for screen readers. But the site is open source (as it's part of an open source project) and I'm happy to accept any PRs to fix any accessibility issues I might have missed.
• kevincox 5y ago
  You shouldn't be using a checkbox for dark mode (at least not as the main toggle). You should be using the css prefers-color-scheme media query so that you use the users default with no required interaction and no bright flash of white. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
  • account42 5y ago
    Too bad that FF with enhanced tracking protection on reports that the user wants a light color scheme instead of reporting no preference.
  • throwoutway 5y ago
    Agreed, but as a user sometimes I turn it off because an article doesn’t work well with it. So the default should be user’s global preference but I want local control
    • account42 5y ago
      Sounds like something that would be better solved by a browser extension than having every website with a dark mode also implement a toggle.
    • tomtomtom777 5y ago
      So you would like a website to implement a checkbox to toggle dark mode, in case it doesn't implement dark mode correctly? That doesn't make any sense.
      • deleted 5y ago
        [deleted]
      • bondant 5y ago
        I think he would rather have a checkbox to disable dark mode in case a specific website. So he don't have to switch his system-wide preference in order to browse a single badly designed website.
• WA 5y ago
  2 (Sidebar) is not usable on mobile, because there is no good hover event. Since mobile-first is almost a necessity, it won't work this way. Accordions make most sense as a table of contents, although they are often used in FAQs. But in FAQs, you can't use the browser's search on page to find collapsed words. So you trade better scrollability for searching on the page. Not sure how many people use "search on page" on mobile devices though. 1 + 3 are great though.
  • StevenWaterman 5y ago
    Yeah I agree that the sidebar isn't a very useful example given that it's not even close to something you'd implement in production. The same technique can definitely be made to work with mobile, which is how the burger menu at the top right of the page is implemented - ie just using `:focus-within` rather than `:hover` and using media queries to only display that menu on mobile. I'm glad that you enjoyed 1 and 3 though - it's been really interesting seeing each person take something different away
    • gbear605 5y ago
      Unfortunately the burger menu at the top right of the page also doesn’t work very well on mobile (iOS Firefox). One the menu appears, there’s no way to get it to hide again, permanently covering up any content underneath (in this case, your name). Aside from that, something very weird is going on with the page. There’s a huge blank area to the right of the screen that you can easily scroll to accidentally. This also happens on Safari on macOS, where for some reason it doesn’t let you scroll back left (and persists the scroll position on page refresh?!). I definitely agree with the blog post in general though - we should try to use HTML and CSS instead of always resorting to JavaScript.
      • easrng 5y ago
        You can tap on something else to hide the menu.
        • 5y ago
• donatj 5y ago
  6) Sending data but staying on the current page. You can make links or forms submit but not cause browser navigation by having your server respond with a 204 No Content. I feel like this is a completely forgotten technique, but we used this a ton pre-AJAX for little one off things to shoot a message to the server without interruption.
  • encryptluks2 5y ago
    While neat, browser navigation isn't a bad thing on forms considering it is good to notify the user that the form was submitted. Otherwise, they will likely just keep hitting submit.
  • yakshaving_jgt 5y ago
    That's really cool! I didn't know about this. Thanks for sharing. How do you handle reflecting the new state in the UI though? Do you just use JavaScript anyway? I have a form which looks like a toggle, and interacting with the toggle initiates a POST request. If the server responds with a 204, the UI doesn't actually update to reflect the new toggled state. I'm not sure how to work around this.
    • fathyb 5y ago
      Could you do something like "<form action="#sent">" and use the ":target" CSS pseudo-class on an element with a message?
      • yakshaving_jgt 5y ago
        I don't think so. I think the form needs to still point to the URI which is expecting the POST request. Maybe I'm not imagining hard enough, but I don't think this approach will work. Furthermore, according to this article[0], the `:target` approach is viable when it's acceptable to change the browser history, whereas in my case that is exactly what I'm trying to avoid. [0]: https://css-tricks.com/css-target/ https://css-tricks.com/css-target/
        • 5y ago
• Cthulhu_ 5y ago
  > PSA: position: sticky; exists now. I joined this company that has a 10 year old Dojo application as their UI. Before I joined they had a guy come over once a week for some maintenance work. They spent several days trying to solve an issue where a bar with a 'save / close' action would show up at the bottom of a dialog, making users scroll down. This was a complaint that users had for literal years. I added position: sticky and had to figure out how it worked, but the issue was resolved with about ten minutes of work. Not to pat my own shoulder too much, but that was pretty cool. Plus it works gracefully, in that if the browser doesn't support it yet, it falls back to (or, should) to the old behaviour.
  • andai 5y ago
    >falls back to the old behaviour Showing up at the bottom?
  • ironmagma 5y ago
    Just don’t try using it in combination with display: table-* or you will curse position: sticky’s name forever.
    • shrew 5y ago
      Or as part of display: grid which also has severe quirks with position: sticky despite it being a much newer API.
    • chrismorgan 5y ago
      Is this still so? I know that in the earlier days of `position: sticky` it didn’t play well with tables (with I think the same limitations on non-tables using `display: table` et al.), but my understanding matches https://caniuse.com/css-sticky https://caniuse.com/css-sticky, that Firefox’s limitation in that area has been fixed for four years, and Chromium’s for ten months.
  • noduerme 5y ago
    First there was position: sticky. Then it was removed and killed. Now it's back? Guh. It's always had problems. It was very hard to wrangle, especially if you have containers in other containers. I know jQuery isn't cool these days, but if you have a site that uses it, sticky-kit is the way to go. It's very fast and handles a lot of corner cases (pun intended).
• pcmaffey 5y ago
  The website is totally broken for me on mobile safari. 1 and 2 don’t work, and the lack of overflow:hidden causes a huge horizontal scrollbar… I’d recommend more testing before using. Though the details element is great.
• exodust 5y ago
  > "3. Sticky Positioning" Yes but javascript can enhance a sticky top nav by watching the scroll position and updating the nav with whatever is intended by design, relative to the scroll position or direction. Such as hiding/showing or doing something else in response. Even though it might still function as a basic nav without js, if I made a movie and found out people were watching it with "special effects turned off" it wouldn't be fun to learn that about the audience. > "1. Animating SVGs" Cool, but the more interesting animation possibilities are javascript driven. Like when using timing, waiting, chaining multiple animations, and responding to user interaction or other events. Need javascript for dynamic animation.
• harel 5y ago
  Came here for "things I don't need Javascript for", from there flowed into Lexoral as a product (pretty cool) and then into the architecture behind it which was interesting. Nice ride.
  • StevenWaterman 5y ago
    Thank you! That's just about the nicest message I've ever read :D If there's a specific bit you're interested in, let me know because I'm happy to chat about it / write future posts about it
    • harel 5y ago
      Well, my journey ended here: https://lexoral.com/blog/svelte-firestore-binding/ https://lexoral.com/blog/svelte-firestore-binding/ and it would be interesting to hear about the whole cloud native serveless journey after you've had some good mileage on it. Lessons learned, pitfalls, caveats and of course victories and fun times.
• maupin 5y ago
  Things you don't need on your webpage: accordion menus.
• brrrrrm 5y ago
  I couldn’t interact with the sidebar on mobile. It kept either reloading the page or scrolling to the top
• leephillips 5y ago
  I was consulting for a startup once and the owner asked me to create an examination he could use to screen front-end "developers". Question #1 asked the applicant to create a modal dialog without using Javascript. He told me that question filtered out several candidates.
  • adrusi 5y ago
    I don't think knowledge of the :target pseudoclass is an especially useful filter. It's not without its uses, but it's not exactly part of the core toolbelt either.
  • bluedevil2k 5y ago
    This is incredibly short sighted and defeats the purpose of an interview. You’re not trying to trick the interviewee with a gotcha question, you’re trying to find ones with the top skills. Who cares if they can open a modal without JS, when you’re building a front end app, guess what, you’re gonna use JS to open the modal. Building on my point about gotcha questions, I recently had a React interview and 3/4 of the interview was about currying functions in JS, something that’s never ever done in a Reqct app.
    • leephillips 5y ago
      Plenty of people who represent themselves as "front-end" "developers" know a good amount of Javascript, or at least some frameworks, but barely know HTML and CSS. This question (and some of the others) filtered out those people.
      • jdauriemma 5y ago
        It filtered out people who didn't know how to use HTML and CSS to render a modal, which is a very specific and not-widely-used HTML/CSS technique.
        • leephillips 5y ago
          It filtered out people without a good general knowledge of HTML and CSS and the creativity and problem-solving skills to apply that knowledge.
• tannhaeuser 5y ago
  No love for classic menus and similar controls using the :target selector? Might be as old as the hills, but still ...
• partiallypro 5y ago
  The dark mode checkbox in this example doesn't remember my selection if I refresh the page. So wouldn't you need JS for it to follow you both across the domain and also upon page refresh?
  • aembleton 5y ago
    Works for me on Firefox 97
    • partiallypro 5y ago
      Doesn't work on Chrome or Edge.
• jaredandrews 5y ago
  I was working on a hobby project recently and wanted to do it without JS. For some reason, I thought there was a way using HTML forms to form a URL. That is, imagine I have two `select` dropdown with a set of numbers in each, and a `submit` button. I thought there was a way to construct a target url based on the values of `select` without using JS. So you might select '2' and '5' from the dropdowns and hitting submit would send you to 'mysite.com/2/5'. As far as I can tell, I was wrong. Anyone disagree?
  • laszlokorte 5y ago
    <form method="get" action="foo.php"> <select name="item" mutiple> <option>1</option> <option>2</option> <option>3</option> </select> <button>go</button> </form> If you select option 1 and option 3 it will submit to foo.php?item[]=1&item[]=3 So in general <form method="get"> will append a query string to the action url composed of the form field values. But it is not possible to specify an url template to control the exact structure of the url. If you want that you have to implement a server side redirect. One thing I did not know until recently myself: form submit buttons can specify their own formaction and formmethod attributes that override that ones specified by the form. So you can have multiple buttons inside on form the submit to different locations.
    • deleted 5y ago
      [deleted]
• layer8 5y ago
  Just a pet peeve: Sticky headers or footers that overlay scrolled content are bad, because they interfere with jumping to page search results and anchors, as browsers do not take into account that the target may be hidden by an overlaid element. => If you use sticky headers/footers, lay out the other content so that it isn’t overlaid by those headers/footers.
  • clairity 5y ago
    seems like the better solution is for the browser to take into account the sticky block when scrolling to the desired content.
    • layer8 5y ago
      The problem, I guess, is that there can be legitimate transparent-ish overlays (covering large parts or the whole of the viewport), and it would be difficult to find a sensible logic that works well in most cases in practice. Anyway, it doesn’t matter much what would be the better solution as long as browsers don’t implement it.
      • clairity 5y ago
        yah, it's fraught with edge cases, but every browser/dom feature seems to need to run a gauntlet of them anyway, so i'm not sure this one is especially complicated. but the slowness of new features is definitely frustrating, even if understandable.
• patafemma 5y ago
  This is a very good article: it explains each point clearly and also includes clear and appropriate code examples. I personally love using modern CSS as much as possible, as opposed to javascript, since it allows separating the visualization and functionality from each other. Of course using pure CSS can also offer noticeable performance benefits. The thing the article seems to be missing is an explanation about when not to use CSS. In my experience there's a lot of scenarios which could be solved with pure CSS in theory but in the end will be implemented in javascript. The first reason is browser compatibility. If older browsers need to be supported (unfortunately IE is not completely dead yet), many CSS based solutions are just not possible. The second reason is changing requirements and future-proofing. Often only the simplest requirements can be fulfilled with a pure CSS solution. When more requirements are added or the feature needs to be extended in any way, the only possible solution is to just completely scrap the CSS solution and re-implement it in javascript. I feel this happens so often that most web developers just prefer implementing the feature in javascript straight away because they know it will be easier to change later if needed.
  • codeulike 5y ago
    The second reason is changing requirements and future-proofing. This is a great point. "how am I going to maintain this?" or "how will someone else maintain this?" are often the most important questions and are often overlooked.
• nottorp 5y ago
  Why, you don't need javascript for anything. Maybe for killing the user's battery?
  • easrng 5y ago
    Pretty sure CSS animations can kill battery.
    • nottorp 5y ago
      I don't want animations in my web site either thank you. Unless it's a game maybe.
• shhsshs 5y ago
  > This isn't just a toy example either. The browser will automatically remember the checkbox state, meaning you can save the user's preference for free - try ticking the box and refreshing this page! Aside from the typical complaints that you should be using prefers-color-scheme instead… This doesn’t work for me. Is it supposed to leverage autocomplete or something?
• dietrichepp 5y ago
  Something I'm struggling to implement at the moment is image carousels. I don't necessarily need something that has full functionality without JavaScript, but it would be nice to provide some kind of progressive enhancement, and make something that works both on desktop and mobile.
  • smoldesu 5y ago
    I wonder if you could abuse the <marquee> tag to get halfway there. It won't be pretty or feature-filled, but it should at least render properly on all devices.
    • dietrichepp 5y ago
      <marquee> is fairly solidly deprecated. If I just wanted an auto-scrolling set of images, I can conjure that up with some CSS animations.
  • pdenton 5y ago
    Here's a starting point: https://www.w3.org/WAI/tutorials/carousels/ https://www.w3.org/WAI/tutorials/carousels/
    • dietrichepp 5y ago
      Thanks, but I also want the carousel to have reasonable behavior for mobile devices. So there's a lot of synthesis from different carousels online that I'm doing. The synthesis is the hard part.
      • deleted 5y ago
        [deleted]
  • Eduard 5y ago
    https://css-tricks.com/css-only-carousel/ https://css-tricks.com/css-only-carousel/
• dqv 5y ago
  Another one that really bombs UX is using javascript for the site navigation in general. That is, instead of <a href="/some/path">Place</a> They will do something like <a href="#" onclick="window.location.href='/some/path'">Place</a> (or whatever the current equivalent is in framework du jour) Making it impossible to right click the link and open a new tab. Yo, I need to be able to reference data from multiple areas of the application and your javascript is making that really hard to do! I know that you can do this properly in javascript, but it would appear that at least some people have not gotten the memo. So I'm going to say - you don't need javascript for navigation.
  • loudtieblahblah 5y ago
  • post-it 5y ago
    > Making it impossible to right click the link and open a new tab Keeping `<a href="/some/path">Place</a>` but adding an event listener to capture your click and run some JS instead fixes that particular issue but opens a whole other can of shit.
    • dorgo 5y ago
      for example?
      • delecti 5y ago
        Google does it. Search any query, hover over a link, and then click the link. While hovering (pre-click) you'll see the actual target link, but once you click it redirects through some Google tracking nonsense.
    • chrisweekly 5y ago
      20 years ago this was called "unobtrusive javascript" and it's still a good idea today. BTW, https://remix.run https://remix.run is a sweet new framework that properly embraces progressive enhancement, ie almost everything works with JS disabled.
• grishka 5y ago
  You can also build all kinds of toggleable things with hidden <input>s, "+" sibling selectors, and <label>s to activate the inputs. For example, an accordion that only has one section expanded at a time can be made with hidden radio buttons next to each item. Or a navigation drawer/sidebar can be made with a hidden checkbox. Any kind of spoiler-style "click to reveal contents" sort of thing can also be made with a hidden checkbox, it's more flexible than <details>.
• LAC-Tech 5y ago
  Do most frontend devs in 2022 even know CSS? They might know tailwind or bootstrap, but I doubt they even know what kind of HTML their react component library is producing, let alone have the capability to style it.
  • torbTurret 5y ago
    Absolutely awful take. Basically every interview will have some section asking about styling.
    • LAC-Tech 5y ago
      I've been doing primarily front-end stuff for the past two years. What's awful about my take? Never had an interview question about styling before - but some places ask you about inverting binary trees than never have you do anything that involves inverting a binary tree, so that wouldn't tell me much.
      • fistynuts 5y ago
        Your two years of experience is showing.
        • LAC-Tech 5y ago
          My years of backend before that certainly influences how I see things. Maybe it would have been better if I'd drank the "modern front end" kool aid from day one. I came in a sceptic and remained one.
          • worik 5y ago
            The front end world is a miserable place of dreadful software built on fantastic foundations. I have dabbled periodically in modern front end development, but it depresses me hugely. All the mistakes that gave us PHP dominating back ends (another sad story) being repeated in a modern context. Learn CSS? I did. Feel like I wore out MDN but I agree it is awesome. An adequate solution to a very difficult problem.
• jrajav 5y ago
  Worth noting that using `transform` can cause performance issues in some cases, especially if the element being transformed contains many heavy children. This is something that can come back to bite you later on if you rely on `transform` techniques too much.
• sylware 5y ago
  One thing you really cannot do with javascript: write an alternative "working" web browser (noscript/basic (x)html) as a small team of devs (or an individual) in a reasonable amount of time.
• seinecle 5y ago
  Creating frontends. You can use Java's JSF for that (it has js under the belt but you don't need to touch it).
• tejtm 5y ago
  Number zero: Reading text.
• throwaway81523 5y ago
  I understand that the .dev TLD is not supposed to support unencrypted HTTP (i.e. it is HTTPS only), browsers are supposed to know about this, and in fact the main ones supposedly do. I wonder if we could also have a .restricted TLD that doesn't support javascript, the more invasive of these CSS hacks, transclusions of any sort except from the same domain, or cookies persisting longer than the browser session. That would make it a lot easier to have reasonable security assurance about pages with private contents, at the expense (or rather, the added benefit) of not being able to have blingy javascript effects on the page.
  • zozbot234 5y ago
    This kind of information is not appropriate for a TLD. If anything, it should be tacked on by extending the existing client-side-only URI fragment, i.e. the portion after a # delimiter. A number of mechanisms are available for such an extension to be broadly compatible with existing uses.
    • throwaway81523 5y ago
      Hmm ok, but maybe .dev should also have been handled that way? It seems too easy to mess up. Maybe the change should be at the protocol level, like rhttps (restricted https) instead of https. We do already have gemini but it is not really practical.