4 ms·

I swear some JS devs will go out of their way to avoid learning anything else, whilst simultaneously and breathlessly espousing that we rewrite everything else

I swear some JS devs will go out of their way to avoid learning anything else, whilst simultaneously and breathlessly espousing that we rewrite everything else in JS.

oneweekwonder 2y ago
> Any application that can be written in JavaScript, will eventually be written in JavaScript. - Jeff Atwood (2007)
- peutetre 2y ago
  The game is changing with WebAssembly though. Large JavaScript applications are replacing JavaScript bits with wasm: https://web.dev/case-studies/google-sheets-wasmgc https://web.dev/case-studies/google-sheets-wasmgc Any application that is written in JavaScript will have more and more of it replaced with WebAssembly.
  - wiseowise 2y ago
    > Any application that is written in JavaScript will have more and more of it replaced with WebAssembly. Which is not a lot when it comes to web. Sure some algo heavy stuff like Figma will benefit from it, but GUI around it is still written in what?
    - peutetre 2y ago
      Just do the whole thing in WebAssembly. Minimal dependencies and pixel perfect in all browsers. The distinction is applications versus documents. Works for Dart with Flutter: https://flutter.dev/ https://flutter.dev/ https://www.youtube.com/watch?v=Nkjc9r0WDNo https://www.youtube.com/watch?v=Nkjc9r0WDNo https://www.youtube.com/watch?v=qx42r29HhcM https://www.youtube.com/watch?v=qx42r29HhcM https://wonderous.app/web/ https://wonderous.app/web/ Works for C# with Avalonia UI: https://avaloniaui.net/ https://avaloniaui.net/ https://www.youtube.com/watch?v=6mwQDPlbF5Y https://www.youtube.com/watch?v=6mwQDPlbF5Y https://solitaire.xaml.live/ https://solitaire.xaml.live/ And so on.
      - wiseowise 2y ago
        Amazing, just awesome. Long standing applause. Let’s regress to level of native apps without benefits of said native apps. No standardization, no performance, no unified integration. Let’s get rid of browser plugins that allow us to fight invasive ads and malicious JS scripts, let’s dump decades of expertise and optimizations, let’s undo all advancements of web just to be able to write same old <div> in C#. Nothing better than a single blob of <canvas>. It’s ironic that some of people in this thread convict JS devs of using only JS and then you use those “frameworks” as an example of a good thing when they don’t even have a separation of presentation (like HTML and JS) that would allow other languages tap into it. And all of this is with much worse performance and stability.* * - for now
        peutetre 2y ago
        > No standardization, no performance, no unified integration. WebAssembly has all of these things. WebAssembly already there, lurking your browser. That's why it will succeed. It's interesting how threatened you are by WebAssembly. But change is normal. Embrace the change.
        wiseowise 2y ago
        > WebAssembly has all of these things. Is that why Flutter demo you’ve linked takes 7 seconds to load on Firefox on iPhone 14 Pro and then barely works skipping frames? I can’t even select text on the page, since it’s just a big canvas, lmao. > WebAssembly has all of these things. WebAssembly already there, lurking your browser. That's why it will succeed. You mean how every of those frameworks that you’ve listed have to reimplement a11y every team, since WASM is pure logic? How all of them have to reimplement OS shortcuts and OS integrations? Is that what you call “unified integration”? > It's interesting how threatened you are by WebAssembly. But change is normal. Embrace the change. Why did I even bother replying to you, sigh.
        peutetre 2y ago
        Ah, so what you want is Uno. It uses WebAssembly and the DOM: https://platform.uno/ https://platform.uno/ > Why did I even bother replying to you, sigh. I think it's because you're overwrought. Don't fear WebAssembly.
tylerchilds 2y ago
i swear some non js devs will go to extreme lengths to demonstrate solutions that will never run on another machine instead of writing js
- anyfoo 2y ago
  Why would they never run on another machine? It's not that hard to write portable code, and done very often. Nowadays for example, you rarely ever think about whether you're on arm or x86. If you write non-portal code, there might be an important reason (like writing OS components, which you won't do in JS).
  - tylerchilds 2y ago
    almost every time code doesn’t run on my machine, the root cause is a political disagreement with a c-compiler author three layers below my actual problem. javascript doesn’t have a compiler is my main point.
    - FridgeSeal 2y ago
      Bit rich to complain about that when all the major browsers have just as significant differences, and that’s before we bring node into the equation, let alone talking about a good 30% of websites I visit with any quantity of JS in them are either perpetually broken in some way, or so jank as to be effectively broken.
      - tylerchilds 2y ago
        totally agreed about all of the above and i take credit for none of that code i write plaintext at uris, progressively enhance that to hypertext using a port with a deno service, a runtime that unifies browser js with non browser js. that hypertext can optionally load javascript and at no point was a compiler required aside from the versioned browser i can ask my customers to inspect or a version of deno we get on freebsd using pkg install. node is not javascript would be my biggest point if i had to conclude why i responded. microsoft failed at killing the web with internet explorer and only switched to google’s engine after securing node’s package manager overtly through github and covertly through typescript. microsoft is not javascript is my final point after circling back to my original point of microsoft is also one of the aforementioned reasoned c-compilers are politically fought over instead of things that just work.
TacticalCoder 2y ago
> I swear some JS devs will go out of their way to avoid learning anything else, whilst simultaneously and breathlessly espousing that we rewrite everything else in JS. The JStockholm syndrome.
mardifoufs 2y ago
It's usually the opposite. And the post is specifically about making JavaScript tools, why would you not expect them to be written in JS? I guess not making tools for say, c# devs in c# would also be bad?
- FridgeSeal 2y ago
  Presumably because, apart from Python (see Ruff, uv, etc) most languages aren’t running into such major issues with their own “self hosted” tooling that it’s worthwhile to rewrite several of them in a completely different language.
  - mardifoufs 2y ago
    Yes I agree! And JavaScript also isn't really at that point yet. Python is really in a class of its own here... sadly enough. Though I don't see an issue with tools for JS built without JS. It's just that I don't think that it's a bad thing for a JavaScript dev to want the ecosystem around JavaScript to be written in JS. JS is orders of magnitudes faster than python in any case.
  - wiseowise 2y ago
    God what I’d do if someone wrote build system in Rust for JVM and freed us from Maven and Gradle.
- rbower 2y ago
  > It's usually the opposite. And the post is specifically about making JavaScript tools, why would you not expect them to be written in JS? Take a look at rollup, vite, etc. These tools are essentially replacing webpack, which is written in JS. Modern Rollup (^4) uses SWC (Rust-based bundler), and vite is currently using a mix of esbuild (Go) and Rollup. I think they're switching to SWC in v6 though. The point here is that for certain operations JS is not nearly as fast as lower-level languages like the aforementioned. Bundling is one of those performance-critical areas where every second counts. That said, as a TypeScript developer I agree with the sentiment that JS tools should be written in JS, but this isn't a hard and fast rule. Sometimes performance matters more. I think the reasonable approach is to prefer JS – or TS, same difference – for writing JS tools. If that doesn't work, reach for something with more performance like Rust, Go, or C++. So far I've only had to do the latter for 2 use cases, one of which is hardware profiling.
zero_shift 2y ago
OP is a Servo contributor

I swear some JS devs will go out of their way to avoid learning anything else, whilst simultaneously and breathlessly espousing that we rewrite everything else in JS.

oneweekwonder 2y ago

> Any application that can be written in JavaScript, will eventually be written in JavaScript. - Jeff Atwood (2007)

peutetre 2y ago
The game is changing with WebAssembly though. Large JavaScript applications are replacing JavaScript bits with wasm: https://web.dev/case-studies/google-sheets-wasmgc https://web.dev/case-studies/google-sheets-wasmgc Any application that is written in JavaScript will have more and more of it replaced with WebAssembly.
- wiseowise 2y ago
  > Any application that is written in JavaScript will have more and more of it replaced with WebAssembly. Which is not a lot when it comes to web. Sure some algo heavy stuff like Figma will benefit from it, but GUI around it is still written in what?
  - peutetre 2y ago
    Just do the whole thing in WebAssembly. Minimal dependencies and pixel perfect in all browsers. The distinction is applications versus documents. Works for Dart with Flutter: https://flutter.dev/ https://flutter.dev/ https://www.youtube.com/watch?v=Nkjc9r0WDNo https://www.youtube.com/watch?v=Nkjc9r0WDNo https://www.youtube.com/watch?v=qx42r29HhcM https://www.youtube.com/watch?v=qx42r29HhcM https://wonderous.app/web/ https://wonderous.app/web/ Works for C# with Avalonia UI: https://avaloniaui.net/ https://avaloniaui.net/ https://www.youtube.com/watch?v=6mwQDPlbF5Y https://www.youtube.com/watch?v=6mwQDPlbF5Y https://solitaire.xaml.live/ https://solitaire.xaml.live/ And so on.
    - wiseowise 2y ago
      Amazing, just awesome. Long standing applause. Let’s regress to level of native apps without benefits of said native apps. No standardization, no performance, no unified integration. Let’s get rid of browser plugins that allow us to fight invasive ads and malicious JS scripts, let’s dump decades of expertise and optimizations, let’s undo all advancements of web just to be able to write same old <div> in C#. Nothing better than a single blob of <canvas>. It’s ironic that some of people in this thread convict JS devs of using only JS and then you use those “frameworks” as an example of a good thing when they don’t even have a separation of presentation (like HTML and JS) that would allow other languages tap into it. And all of this is with much worse performance and stability.* * - for now
      - peutetre 2y ago
        > No standardization, no performance, no unified integration. WebAssembly has all of these things. WebAssembly already there, lurking your browser. That's why it will succeed. It's interesting how threatened you are by WebAssembly. But change is normal. Embrace the change.
        wiseowise 2y ago
        > WebAssembly has all of these things. Is that why Flutter demo you’ve linked takes 7 seconds to load on Firefox on iPhone 14 Pro and then barely works skipping frames? I can’t even select text on the page, since it’s just a big canvas, lmao. > WebAssembly has all of these things. WebAssembly already there, lurking your browser. That's why it will succeed. You mean how every of those frameworks that you’ve listed have to reimplement a11y every team, since WASM is pure logic? How all of them have to reimplement OS shortcuts and OS integrations? Is that what you call “unified integration”? > It's interesting how threatened you are by WebAssembly. But change is normal. Embrace the change. Why did I even bother replying to you, sigh.
        peutetre 2y ago
        Ah, so what you want is Uno. It uses WebAssembly and the DOM: https://platform.uno/ https://platform.uno/ > Why did I even bother replying to you, sigh. I think it's because you're overwrought. Don't fear WebAssembly.

tylerchilds 2y ago

i swear some non js devs will go to extreme lengths to demonstrate solutions that will never run on another machine instead of writing js

anyfoo 2y ago
Why would they never run on another machine? It's not that hard to write portable code, and done very often. Nowadays for example, you rarely ever think about whether you're on arm or x86. If you write non-portal code, there might be an important reason (like writing OS components, which you won't do in JS).
- tylerchilds 2y ago
  almost every time code doesn’t run on my machine, the root cause is a political disagreement with a c-compiler author three layers below my actual problem. javascript doesn’t have a compiler is my main point.
  - FridgeSeal 2y ago
    Bit rich to complain about that when all the major browsers have just as significant differences, and that’s before we bring node into the equation, let alone talking about a good 30% of websites I visit with any quantity of JS in them are either perpetually broken in some way, or so jank as to be effectively broken.
    - tylerchilds 2y ago
      totally agreed about all of the above and i take credit for none of that code i write plaintext at uris, progressively enhance that to hypertext using a port with a deno service, a runtime that unifies browser js with non browser js. that hypertext can optionally load javascript and at no point was a compiler required aside from the versioned browser i can ask my customers to inspect or a version of deno we get on freebsd using pkg install. node is not javascript would be my biggest point if i had to conclude why i responded. microsoft failed at killing the web with internet explorer and only switched to google’s engine after securing node’s package manager overtly through github and covertly through typescript. microsoft is not javascript is my final point after circling back to my original point of microsoft is also one of the aforementioned reasoned c-compilers are politically fought over instead of things that just work.

TacticalCoder 2y ago

> I swear some JS devs will go out of their way to avoid learning anything else, whilst simultaneously and breathlessly espousing that we rewrite everything else in JS. The JStockholm syndrome.

mardifoufs 2y ago

It's usually the opposite. And the post is specifically about making JavaScript tools, why would you not expect them to be written in JS? I guess not making tools for say, c# devs in c# would also be bad?

FridgeSeal 2y ago
Presumably because, apart from Python (see Ruff, uv, etc) most languages aren’t running into such major issues with their own “self hosted” tooling that it’s worthwhile to rewrite several of them in a completely different language.
- mardifoufs 2y ago
  Yes I agree! And JavaScript also isn't really at that point yet. Python is really in a class of its own here... sadly enough. Though I don't see an issue with tools for JS built without JS. It's just that I don't think that it's a bad thing for a JavaScript dev to want the ecosystem around JavaScript to be written in JS. JS is orders of magnitudes faster than python in any case.
- wiseowise 2y ago
  God what I’d do if someone wrote build system in Rust for JVM and freed us from Maven and Gradle.
rbower 2y ago
> It's usually the opposite. And the post is specifically about making JavaScript tools, why would you not expect them to be written in JS? Take a look at rollup, vite, etc. These tools are essentially replacing webpack, which is written in JS. Modern Rollup (^4) uses SWC (Rust-based bundler), and vite is currently using a mix of esbuild (Go) and Rollup. I think they're switching to SWC in v6 though. The point here is that for certain operations JS is not nearly as fast as lower-level languages like the aforementioned. Bundling is one of those performance-critical areas where every second counts. That said, as a TypeScript developer I agree with the sentiment that JS tools should be written in JS, but this isn't a hard and fast rule. Sometimes performance matters more. I think the reasonable approach is to prefer JS – or TS, same difference – for writing JS tools. If that doesn't work, reach for something with more performance like Rust, Go, or C++. So far I've only had to do the latter for 2 use cases, one of which is hardware profiling.

zero_shift 2y ago

OP is a Servo contributor