You might not need JavaScript
youmightnotneedjs.com
youmightnotneedjs.com
JS is a fine tool for making rich, interactive UIs in the browser and IMO avoiding it at all costs shouldn't be a priority
Most "webapps" (e.g. almost every bank or brokerage I use, or mint/tax tools/...) are more simple yet are bloated, slow, buggy atrocities. Especially Chase Bank, I say it without exaggeration is that if I was making a hiring decision for one of the developers of that site and the only alternative they had was to slowly starve to death, I would still not hire them.
As someone whose first fun tech job was writing complicated (B2B) Javascript apps in the days when prototype.js was cool new tech and you still had to support IE6, I've come to regret that Javascript even exists, and I'd personally love for web scripting to be made illegal. If your thing is more complicated than GMail, write a native app.
</rant>
Are you kidding me? The JavaScript version of Gmail is awful. One of the slowest client-side apps I've had the displeasure to use. Full-fat Gmail used to be fast and pleasant to use (and at that point it was indeed faster than the plain HTML version), but they did a rewrite a few years back and completely borked it.
Expanding your toolbelt with this knowledge is like giving yourself an extra set of native functions.
JS (well, TS) is fine but it's not good. I'm a frontend dev, and I use JS, React and Next daily for making a rich clientside-driven app that uses a sprinkling of serverside rendering to gather up some data every page needs at the start, and it's nice to work with. It's easy and our velocity is great because of it. If we ever go fully serverside with no code shared on the frontend I'll be arguing that JS is the wrong language for the job because we can be faster, and safer, in something like golang.
We shouldn't be afraid of abandoning JS if we don't need JS.
* Modularisation is really easy. Components are ultimately just functions, with all the benefits for splitting up and deduplicating code that that brings. You don't need to create files to split up code units, which makes it a lot easier to create smaller, more flexible units.
* You're writing templates in a real programming language, ideally one you already know. Yes, there's a bit of syntax sugar with JSX, although in principle you don't need it, but everything else is just javascript. For example, things like importing other files just works - there's no special "partials" directory, and you don't need to figure out how this templating library approaches paths.
* You can manage your CSS much more easily with tools like CSS-in-JS or CSS Modules. Your styles are scoped to your components, which means that dead styles are much easier to find and remove, and you're less likely to have "action at a distance" issues from unexpected rules applying in places you don't expect.
* You have access to a lot of tooling dedicated to front-end development, in particular bundlers that can automatically build your static pages, compress images, optimise CSS, etc. While it can be a pain to get this set up, once it's there, it's a very powerful tool to sending well-optimised results to browsers.
So in principle, I agree that we shouldn't use JS if we don't need it, but my problem is often that, although the space for better tooling clearly should exist, it just isn't there.
Here are the things worth using on this page: Modal, everything under Forms. That's it.
But following standards and avoiding hacky CSS implementations for mission critical interfaces still sounds like a good idea to me
You are legally allowed to make an accessibility hellscape of an intranet site :)
[0] https://www.ada.gov/regs2010/titleII_2010/titleII_2010_withb....
And for everything else you should probably just use a CMS.
If you want a site to work in Tor Browser then it had better work without JS.
Considering something like 98-99% of users at our current company use chrome or safari, we don't even prioritize firefox / edge unless there are user complaints (which there aren't many of because we use modern JS so there are generally only tiny differences between browsers if any). Again our resources are limited and there's only so much we can do
Exactly, this is 2022. I used to be one of those types running Firefox (since the late 90s) with NoScript and other extensions to have 100% ultimate control over who and who could not run JavaScript.
It's ubiquitous now, it's sandboxed, it's safe and extremely performant.
There's no reason to go backwards now.
Sometimes. Counter examples are facebook and the Reddit remake.
Maybe there's a market opening for a tool that compiles javascript to CSS. :shrug:
It feels a wee bit amusing that it’s about “you don’t need JS” but uses SCSS for examples. I think there’s something powerful and accessible about keeping the complexity to an absolute minimum. I’m not sure this page needs SCSS.
You might not need SCSS. In fact, you never need SCSS (or SASS or any of the others). ("hot take" airhorns sound effect)
Is your thing more complicated than GMail? If yes, maybe you can use Javascript in proportion to how much more complicated it is.
If not and you are still using a ton Javascript, please don't ever write software.
An example not on the page are menus powered by the CSS :hover pseudo-class. It seems smart, until you realise the diagonal problem exists, and it is quite hard to select an item in your menu without accidentally opening one of the sibling menus.
Unfortunately, software development seems extremely poor at passing knowledge on to the next generation so you see these problems being “rediscovered” over and over again.
For the accordion, why not just use <details>?
The purpose of this site is awesome! I appreciate the transparency of pointing out issues like "no user control over images".
Here's a similar codepen I made two years ago: https://codepen.io/spartanatreyu/pen/OJVVQRw
It doesn't use floats, so it ends up being silky smooth.
It could be simplified with today's scss/css, but it's still a decent demonstration of how smooth animations should be.
Your demo is doing the same thing as the original – transitioning a `translateX` value. Indeed, I get a smooth, consistent 60fps from both, and a performance profile reveals that no paints occurred in the original! That's AKA "there is no way to improve this"
So, I'm pretty sure float won't have any impact to performance, as the elements themselves don't reflow during the transition.
[0] https://web.archive.org/web/20131109172325/https://www.html5...
I can see the jank on my machine, and commenting out the float statements makes the jank disappear.
Even though the elements aren't reflowing, there is something going on in the browser that is making it slow down.
Strangely enough, recording the browser performance seems to "fix" the jank so long as the browser is recording. Perhaps capturing screenshots of the page every frame is forcing the browser to deliver frame updates at the correct time.
Transform values (and opacity values, like your Codepen use) operate at the compositor level, and don't need to paint.
That means that an element using those values with a float layout won't impact FPS – the transition is unaware that the element is floated.
> recording the browser performance seems to "fix" the jank
If Chrome is also exhibiting it, it has a passive FPS meter to record this. DevTools, Ctrl/Cmd-Shift-P, "FPS". I get a pretty steady 60FPS: https://imgur.com/a/lgntlpw
As soon as I take out the float and rerun the examples they run butter smooth.
Turning on the fps overlay on Edge (it's the same one as chrome) shows stutters (but for some reason I need to make sure I'm moving the mouse smoothly for the fps counter to update, guessing it has something to do with the preview sitting inside an iframe).
Disabling that setting doesn't seem to have had any negative impacts on website performance...this slider is butter smooth, WebGL works fine, and 4K Youtube videos are smooth.
Regarding user control, I suspect you could get at least "pause" functionality to work using the checkbox trick to disable animation if the box is checked.
I'm using Firefox on Wayland with an iGPU and the slider works smoothly on my end.
Chrome's task manager says the page is using ~0% CPU, 20mb of GPU memory, and 90mb of ram.
It likely isn't using much more power than if running at entirely idle, often enough less than the extra a CPU might use doing the same job at a lower frame rate, displaying and updating your current desktop.
People who have a problem with JavaScript need to get over themselves. JS is one of the closest languages we have to pseudocode (which is optimized for readability by humans). It has some bad parts, but you can avoid these and write very secure, high quality code.
IMO, the simplicity of JavaScript makes it easier to spot mistakes in the code.
This is not my experience at all. I find Typescript to be a world better than JS.
You are correct you can write secure, high quality code. You can do that in assembler too. However that's very difficult and it's easy to go wrong. I think JS is better than assembler but there are much better languages.
Sometimes we become an expert in something so it's much easier for us to use. Then we think that thing is the reason it's so easy. When it's our expertise that makes it easy for us. Do you think that could be the case?
The next project was forked from the same codebase and had an even more complex feature set. I took everything back to JS and never regretted it.
I've done other backends in Python, Erlang, Java, Golang, and C++. Done mobile apps in ObjC and Swift; not directly comparable, but JS (via React Native) was also nicer like night and day.
It might just be personal preference. If you've given other languages a go and still love JS that's great. I'm glad you enjoy it.
Python is the more pseudocode-like language, though. It has a place for scripts, data science / ML, and coding interviews.
The current debate over shoving the styles into components or shoving them into the toolcahin boggles my mind. It's driving me crazy.
Never again, not even a little.
Half of them look and feel incredibly janky to use as well.
I can hear the cries of anguish now. "battle tested! facebook! declarative! library not a framework/if you don't use it you'll end up using your own framework!".
Interesting, but how is "form validation" through HTML, SCSS not a security threat?
I mean, you basically tell attackers how to brute force.
I do wish more websites would use these techniques where appropriate to make the web faster, but maybe using JS is good to keep web developers employed (imagine if so much of demand were implementable via markup languages, reminds me of this post: http://harmful.cat-v.org/software/c++/I_did_it_for_you_all).
But also, JS client-side validation is also client side, and therefore exposes the same amount of information to an adversary.
Either way, you need input validation on the backend.
The backend must always validate and it's this validation that matters for any sort of 'security' or data integrity issue.
We live in a global world. There is probably not a single site that can be sure to have only "local" users. Ask anyone who moved from one country to another or just tried to plan a bit more exotic holiday trip.