https://deno.com/blog/commonjs-is-hurting-javascript
“CommonJS is hurting JavaScript.” It’s “not browser native. You need bundlers and transpilers to make all of this code work client-side.”
Seems reasonable! Can we talk about JSX next?
22 replies
with a casual side-eye at TypeScript 👀
-
-
-
@khalidabuhakmeh the `className` burns already—so deep
-
@zachleat It doesn’t needs to be if it isn’t running in the browser. The issue is everyone bundling node(!) modules into codebases with browser as a target. It’s not as if we’re targeting different architectures that are functionally virtually identical.
@timsev but we *needed* isomorphic JavaScript for single page applications, right? 🫣
…right?
@zachleat In the early days, SPA’s were exclusively client-side and could’ve worked fine with a browser-specific package manager (like bower). I think it was node.js folk that pursued isomorphism, and devs that built JS-heavy sites followed naturally.
-
@easrng I agree with the premise of the article! My point is that we should apply that premise to JSX too.
@easrng if JSX had been architected to use tagged template literals (a la htm), I would have no complaints—but alas, it was not. What I’m hearing is that you’re fine with transpilers for JSX—I wish they weren’t necessary.
@zachleat no i'm saying jsx is completely optional. there is ~no scenario in which you are required to use jsx, since it's just syntax sugar for
hcalls.@easrng ehhh, I see what you mean—but saying that you don’t need to use JSX because someone else already ran the transpiler isn’t quite a strong enough argument for me to board that train of thought.
we needn’t belabor it further though, thanks for the chat!