4 ms·

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 g

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

Waterluvian 4y ago
It’s not a binary choice. Expanding your toolbelt with this knowledge is like giving yourself an extra set of native functions.
- danielvaughn 4y ago
  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.
  - onion2k 4y ago
    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.
    - MrJohz 4y ago
      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.
kcb 4y ago
> JS is a fine tool for making rich, interactive UIs in the browser And for everything else you should probably just use a CMS.
lelandfe 4y ago
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.
- xupybd 4y ago
  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.
  - lelandfe 4y ago
    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
  - gedy 4y ago
    ADA lawsuits don't always follow "common sense" type reasoning though
    - lelandfe 4y ago
      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_withbold.htm#:~:text=(a)%20No%20qualified%20individual%20with,discrimination%20by%20any%20public%20entity https://www.ada.gov/regs2010/titleII_2010/titleII_2010_withb....
      - xupybd 4y ago
        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.
RunSet 4y ago
> 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.
- sbysb 4y ago
  Most people do not want/need this, so the original point stands
  - hot_gril 4y ago
    Some do. Some specifically want the website not to work in Tor.
- ativzzz 4y ago
  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
  - xigoi 4y ago
    By not supporting Firefox, you're assisting Google in taking over the web.
EMM_386 4y ago
> 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.
- Semaphor 4y ago
  > and extremely performant. Sometimes. Counter examples are facebook and the Reddit remake.
  - adamparsons 4y ago
    Trust facebook to both create react AND make the worst performing react application of all time.
  - kaba0 4y ago
    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.
sershe 4y ago
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>
- nicoburns 4y ago
  > 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.

Waterluvian 4y ago

It’s not a binary choice. Expanding your toolbelt with this knowledge is like giving yourself an extra set of native functions.

danielvaughn 4y ago
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.
- onion2k 4y ago
  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.
  - MrJohz 4y ago
    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.

kcb 4y ago

> JS is a fine tool for making rich, interactive UIs in the browser And for everything else you should probably just use a CMS.

lelandfe 4y ago

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.

xupybd 4y ago
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.
- lelandfe 4y ago
  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
- gedy 4y ago
  ADA lawsuits don't always follow "common sense" type reasoning though
  - lelandfe 4y ago
    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_withbold.htm#:~:text=(a)%20No%20qualified%20individual%20with,discrimination%20by%20any%20public%20entity https://www.ada.gov/regs2010/titleII_2010/titleII_2010_withb....
    - xupybd 4y ago
      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.

RunSet 4y ago

> 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.

sbysb 4y ago
Most people do not want/need this, so the original point stands
- hot_gril 4y ago
  Some do. Some specifically want the website not to work in Tor.
ativzzz 4y ago
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
- xigoi 4y ago
  By not supporting Firefox, you're assisting Google in taking over the web.

EMM_386 4y ago

> 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.

Semaphor 4y ago
> and extremely performant. Sometimes. Counter examples are facebook and the Reddit remake.
- adamparsons 4y ago
  Trust facebook to both create react AND make the worst performing react application of all time.
- kaba0 4y ago
  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.

sershe 4y ago

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>

nicoburns 4y ago
> 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.