This gets posted once a month and everyone who dislikes JS is like YEAA but the reality is these are great for simple websites / apps but once your app starts getting more complex all of these components will start to need to do more things like on click interactions or interacting with other parts of the page or the backend and you'll end up porting it to JS anyway
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
GMail manages to implement a pretty complicated app without Javascript (their simple HTML mode) and it works just fine, on anything other than my gaming PC it's faster to use and I prefer it. And we are comparing it to Gmail itself, one of the few Javascript apps actually created by people in possession of some engineering sensibility.
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.
> we are comparing it to Gmail itself, one of the few Javascript apps actually created by people in possession of some engineering sensibility.
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.
Heck, if you write server side React with NextJS or something, you can return an entirely js-less page even though you wrote it entirely in JavaScript. Have your cake and eat it too.
That's true, but if you ask the question "Is Next and JS the best way to do this?" the answer is almost certainly "No". The reason why it's seems like so many devs are doing it this way is because so few devs are being honest and truly critical of their toolset.
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.
I broadly agree, but I've never found a tool that is as good at simply generating HTML as front-end React.
* 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.
Also, the majority of these are accessibility fires, and will need to be completely replaced if you intend to support users on screenreaders (which you should).
Here are the things worth using on this page: Modal, everything under Forms. That's it.
I write CRUD apps that run on industrial machinery. Do I need to support screen readers? Many of these machines require very good vision to operate. It's just not safe if you can't see what is going on.
Nah, an industrial machinery interface won't be liable for ADA suits. Title II of the ADA only covers "the benefits of the services, programs, or activities of a public entity"[0] – public being the keyword.
You are legally allowed to make an accessibility hellscape of an intranet site :)
Many of these systems are an accessibility hellscape for users with 20/20 vision. They're bult expressly to the desires of upper management without any input of the people operating the software.
Never have I ever worked at a company where tor browser usage even shows up in our metrics (would it even show up in metrics? probably not), nor have we heard from anyone about using tor browser, so to us, those users simply don't exist or if they exist our resources are so limited that it's not worth pandering to that usecase.
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
> 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
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.
The amount of shit those websites do and yet they remain somewhat functional is a remark on how performant JS runtimes are. All that “log every single mouse movement and send it as some analytics continuously while we load 55 new ads and 10 new fonts” would probably give a hard time for Qt with c++ as well.
Some of the proposed substitutions, especially the view switcher, use opaque and tricky CSS, the sort of stuff that would show up in mailing lists of CSS hacks in the past. The equivalent javascript code would be much easier for almost anyone to read and debug.
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.
There are obvious downsides to many of these CSS hacks. Pay close attention to the usage notes.
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.
Please respect the prefers-reduced-motion setting when adding animations. I don't want to waste my time watching stuff slowly slide around on the page.
The world of high performance CSS animation has not changed much in 6 years (or more![0])
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.
The original is doing `translateX` yes, but it also has float in it.
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
I see jank on that example with both Firefox and Edge on a 2020 iMac running macOS Monterey.
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).
I recently disabled the "Use hardware acceleration when available" setting in Firefox on my machine (Ubuntu 22.04, Nvidia 1080ti) on a whim and discovered that it had been the cause of tons of jank on my machine, often bleeding over and causing super low fps in random other application windows, which I hadn't previously attributed to FF itself.
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.
Working fine for me on both Safari and Firefox on an M1 Mac.
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.
Firefox that isn't properly GPU accelerated on Linux can do this, and you're likely to experience janky transitions if you're not using Firefox on Wayland, as well.
I'm using Firefox on Wayland with an iGPU and the slider works smoothly on my end.
A surprising amount of stuff that you might think it's done with just dumb bitmap rendering surfaces, is these days actually painted on graphics primatives with it all composited together by your GPU.
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.
I appreciate the work, but I'm feeling some pure visual effects might be unnecessary. When you can scroll effortlessly on a screen and have effectively infinite space, do you still need to squeeze a lot of elements to a small area? Instead of using image sliders, view switchers or tabs, you can consider using a larger container and show all contents at the same time, with the help of js-free flexboxes or grids.
JavaScript is the best language for application and API development.
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?
I had a large NodeJS web backend that my teammate and I switched to TS . It just felt like JS but with extra steps. The type system is rather manual (compared to say Rust), and it didn't catch any mistakes I wouldn't have noticed on my own or caught in integration testing. It also complicated the toolchain all the way through. But we rolled with it.
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.
Is this satire? If it's not, then this question is going to sound dickish. That's not my intention, I'm just genuinely wondering if this is satire because it's not always obvious on the internet.
I agree for web stuff, and it took me longer to realize this than it should have. Mained about 8 other languages first. Looking back, I was wasting so much time on pedantic stuff.
Python is the more pseudocode-like language, though. It has a place for scripts, data science / ML, and coding interviews.
https://youmightnotneedjquery.com is actually a great pitch for jQuery. I still use jQuery, I don’t care. For small things, the API is nice (except the $ sign) and they still continue to publish updates.
It's not that hard to remove jQuery, using this site, after using it to prototype something. I had 97 $s in a recent file and it only took an hour to convert it. It takes way more time to convert React to vanilla JS. But I think that's been the point of React for long time: lock-in.
The current debate over shoving the styles into components or shoving them into the toolcahin boggles my mind. It's driving me crazy.
I'm quite impressed by the scroll indicator, though I have no idea how it works. Also I have a feeling that whatever technique it's using it won't be that flexible to position the indicator anywhere on site.
There’s really no reason to not to at this point. Building websites with anything other than self-contained components is zero percent worth it. css-as-dry was a mistake.
I'm waiting for someone to be truly brave, and come out with "you might not need react".
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).
As others have said, client-side validation is to assist a user with providing proper values. (Example: Did you forget to type the "@" sign in your email? Did you miss a digit in your phone number?)
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.
A lot of form validation can cause anything from bad user experience to making the whole service unusable. Phone numbers outside North America are not fixed length. Addresses come in many formats. The list is endless.
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.
But there are sites that explivitely ask for a "local" phone number. Maybe their automated sms system can't send to foreign numbers ? I' pretty sure that's how banks in the us operate
Anyway in that case, the front-end should definitely catch it before the backend throws a fit
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