4 ms·

It has more gotchas than most languages since bad backend languages just stop getting adopted, and being client-side, issues are less obvious as long as it appe

It has more gotchas than most languages since bad backend languages just stop getting adopted, and being client-side, issues are less obvious as long as it appears to work. n^2 code that should be n with some memoization might blow up a backend service, but freezing the UI for 50 ms is ok-ish in the browser.

wereHamster 5y ago
Blowing up the backend and a 50ms freeze is comparing apples with oranges. If you have code that freezes the backend for 50ms you're unlikely to notice it. And if the code running in the browser blows up you're going to notice just like in the backend case. Also, JS is not the only language that runs in the browser. You have TypeScript, as well as any language that compiles to wasm. If you want one that's not bad, it's up to you to pick one.
- globnomulous 5y ago
  TypeScript doesn't run in the browser.
  - deleted 5y ago
    [deleted]
  - globnomulous 5y ago
    And WASM isn't meant to replace JavaScript. Last time I checked, its use was discouraged for general-purpose web development. It's meant to be invoked in JavaScript, not the one tool used when writing an entire web app. If you want to write code that runs in a browser, JavaScript really is your only option.
capableweb 5y ago
> It has more gotchas than most languages Where do you get this from? Has there been any comparisons made between JS and other languages to see which ones have the most gotchas? I'd love to see the data behind this. > since bad backend languages just stop getting adopted What? This is obviously not true (bypassing the discussion around what "bad" means, which is highly subjective). People continue to adopt all kinds of languages all the time. New projects in PHP are still created (although I disagree PHP is necessarily a bad language [today]) > issues are less obvious as long as it appears to work Hmm, isn't it the opposite? Frontends is what the users see, when something is wrong it's very easy to see that something is broken. And if the backend breaks the wrong way, the frontend usually breaks as a result too if the programmers haven't setup error handling correctly. > freezing the UI for 50 ms is ok-ish in the browser Freezing the browser UI for 50ms is as noticeable as adding additional 50ms to the processing time of all backend requests. If you're actively building it you might notice that the timings off, but if you're just using it, everything might look fine. Not sure what backend/frontend makes a difference here...

wereHamster 5y ago

Blowing up the backend and a 50ms freeze is comparing apples with oranges. If you have code that freezes the backend for 50ms you're unlikely to notice it. And if the code running in the browser blows up you're going to notice just like in the backend case. Also, JS is not the only language that runs in the browser. You have TypeScript, as well as any language that compiles to wasm. If you want one that's not bad, it's up to you to pick one.

globnomulous 5y ago
TypeScript doesn't run in the browser.
- deleted 5y ago
  [deleted]
- globnomulous 5y ago
  And WASM isn't meant to replace JavaScript. Last time I checked, its use was discouraged for general-purpose web development. It's meant to be invoked in JavaScript, not the one tool used when writing an entire web app. If you want to write code that runs in a browser, JavaScript really is your only option.

capableweb 5y ago

> It has more gotchas than most languages Where do you get this from? Has there been any comparisons made between JS and other languages to see which ones have the most gotchas? I'd love to see the data behind this. > since bad backend languages just stop getting adopted What? This is obviously not true (bypassing the discussion around what "bad" means, which is highly subjective). People continue to adopt all kinds of languages all the time. New projects in PHP are still created (although I disagree PHP is necessarily a bad language [today]) > issues are less obvious as long as it appears to work Hmm, isn't it the opposite? Frontends is what the users see, when something is wrong it's very easy to see that something is broken. And if the backend breaks the wrong way, the frontend usually breaks as a result too if the programmers haven't setup error handling correctly. > freezing the UI for 50 ms is ok-ish in the browser Freezing the browser UI for 50ms is as noticeable as adding additional 50ms to the processing time of all backend requests. If you're actively building it you might notice that the timings off, but if you're just using it, everything might look fine. Not sure what backend/frontend makes a difference here...