You might not need JavaScript(youmightnotneedjs.com)
youmightnotneedjs.com
You might not need JavaScript
http://youmightnotneedjs.com/
90 comments
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.
</rant>
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>
> 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.
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.
It’s not a binary choice.
Expanding your toolbelt with this knowledge is like giving yourself an extra set of native functions.
Expanding your toolbelt with this knowledge is like giving yourself an extra set of native functions.
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.
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.
* 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.
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.
I doubt screenreaders have a way to interact with your devices :)
But following standards and avoiding hacky CSS implementations for mission critical interfaces still sounds like a good idea to me
But following standards and avoiding hacky CSS implementations for mission critical interfaces still sounds like a good idea to me
ADA lawsuits don't always follow "common sense" type reasoning though
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 :)
[0] https://www.ada.gov/regs2010/titleII_2010/titleII_2010_withb....
You are legally allowed to make an accessibility hellscape of an intranet site :)
[0] https://www.ada.gov/regs2010/titleII_2010/titleII_2010_withb....
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.
I believe it! I’ve worked with interfaces for warehouses and rental shops, and it’s the same thing.
> JS is a fine tool for making rich, interactive UIs in the browser
And for everything else you should probably just use a CMS.
And for everything else you should probably just use a CMS.
> 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
If you want a site to work in Tor Browser then it had better work without JS.
If you want a site to work in Tor Browser then it had better work without JS.
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
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
By not supporting Firefox, you're assisting Google in taking over the web.
> 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.
There's no reason to go backwards now.
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.
> and extremely performant.
Sometimes. Counter examples are facebook and the Reddit remake.
Sometimes. Counter examples are facebook and the Reddit remake.
Trust facebook to both create react AND make the worst performing react application of all time.
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:
Maybe there's a market opening for a tool that compiles javascript to CSS. :shrug:
[deleted]
Love it. Going to play with some of these.
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.
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.
My favorite reference point for Javascript use is simple-HTML version of GMail. It's a webapp and it works fine with ~0 javascript.
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.
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.
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.
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.
For the accordion, why not just use <details>?
For the accordion, why not just use <details>?
[deleted]
The lack of accessibility makes many of these simply non-starters.
First example - Image Slider is very janky for me. Firefox, beefy GPU PC, Ubuntu.
The purpose of this site is awesome! I appreciate the transparency of pointing out issues like "no user control over images".
The purpose of this site is awesome! I appreciate the transparency of pointing out issues like "no user control over images".
It's janky because it was made 6 years ago and it uses CSS Floats (which are famously janky).
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.
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.
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.
[0] https://web.archive.org/web/20131109172325/https://www.html5...
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...
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.
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.
Here's a dead simple example, do you experience jank with it? https://jsfiddle.net/6etnpzyx/1/
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
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).
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).
Awesome work! +1 this looks silky smooth.
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.
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.
https://css-tricks.com/the-checkbox-hack/
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.
https://css-tricks.com/the-checkbox-hack/
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.
I'm using Firefox on Wayland with an iGPU and the slider works smoothly on my end.
Interesting, which GPU? On Windows, it's very smooth for me, but I have a 3090ti...
Chrome's task manager says the page is using ~0% CPU, 20mb of GPU memory, and 90mb of ram.
Chrome's task manager says the page is using ~0% CPU, 20mb of GPU memory, and 90mb of ram.
It worries me we're discussing gpus when it comes to an image slider.
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.
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.
Most browsers are GPU accelerated.
Ran butter smooth on my old pixel 2 phone using Firefox.
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.
TIL input type="color"
Same! ...so, i had to look it up, and quite interesting indeed: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
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.
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.
Have you tried many other languages?
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?
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.
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.
My experience has been that JS is difficult to maintain. Especially when the project gets a few years old.
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.
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.
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.
Python is the more pseudocode-like language, though. It has a place for scripts, data science / ML, and coding interviews.
Agreed, Python is a great language too.
Javascript bad, HTML good. Upvotes to the left.
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.
I've never used jQuery before and don't feel like I'm missing much. But these comparisons of how to do something in A vs B are always useful.
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.
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.
[deleted]
These are neat tutorials, thanks for sharing, but I still need Javascript. I can't deal with CSS, and idk what SASS is.
There's no reason to avoid JS to these extents.
Half of them look and feel incredibly janky to use as well.
Half of them look and feel incredibly janky to use as well.
I remember also seeing a gridview with filtering without JavaScript but I can not find it.
This page is missing 1 more obvious use-case: no-js loading spinner.
You might not need scss
Informative. Thank you.
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!".
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!".
I've been wanting to do this ever since I had a junior dev ask for React for a simple expand to show/collapse to hide text element.
[deleted]
The web site broke the "back" button on my phone. I had to manually navigate back to HN by url.
you might not need a good user experience
[deleted]
> http://youmightnotneedjs.com/#form_validation
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).
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.
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.
Client side validation, regardless of the technology used, is a performance and UX optimization.
The backend must always validate and it's this validation that matters for any sort of 'security' or data integrity issue.
The backend must always validate and it's this validation that matters for any sort of 'security' or data integrity issue.
Frontend form validation is not for security, it's for user experience. Backend validation is for security.
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.
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