5 ms·
I find it fascinating that there are people still using script tags. I have personally become so tied to npm and typescript that it feels that I'm programming
by marcus_cemes 5y ago
I find it fascinating that there are people still using script tags. I have personally become so tied to npm and typescript that it feels that I'm programming in a completely different language and ecosystem, with a build process and IDE-like type checking and linting, a more procedural data-oriented C-like paradigm.
I've never touched the old JS guts, `module.exports`,the prototype chain, ... Babel (and later TypeScript) allowed me to live in ESM land from the beginning. I expect any tool/library to be available using exclusively on npm, in reality, I've been constantly fighting with it over the past few years.
I usually get a shock when I see libraries still offering minified bundles that assign to the global namespace, to me this seems like outdated practice, but I guess that this is still really prevalent in JS, even in 2021. I sometimes want to go back to it, with the amount of configuration and boilerplate necessary to set up a project with npm, Prettier, ESLint, Typescript, Webpack/Parcel/Rollup, SPA vs MPA, React vs Vue vs $SPAFRAMEWORK, it was a lot easier back in the day.
I think the biggest failure in the JS system is the lack of standardisation, it's so versatile that almost anything is possible. A number of different module systems were invented to solve the initial growing pains (the first would literaly replace a `require()` function call with the contents of the given file), and we never escaped them as they became the foundations of Node.js/npm. Then we needed a non-blocking variant, so we just called it `import()`, it returns a promise. Then we wanted proper imports, so we invented the `import ... from ...;` ESM syntax. We made a named import and default import variant (with most bundlers offering a compatibility layer with CJS-type exports, so imports now have a hidden `__esModule: true` key...). In order to stay compatible with legacy CJS, we also added the `import * as ... from ...;` syntax as an escape hatch?
When TypeScript came along, in order to be compatible with JS it became common practice to distribute compiled TS code along with the source code, with an adjacent declaration `.d.ts` file to provide type information. The source code was never leveraged in any way, and so people just stopped shipping the `src` directory, only `dist` and a `package.json`. It makes debugging a pain, but compiling TS libraries would have been tricky, considering the widely varying different feature flags (async, DOM, ...) and strictness options. Perhaps Deno will help with this to some regard. The great thing about Go or Rust (or any other language, really) is that you import source code, not illegible compiled code (unless you're dynamically linking). I believe that Rust is especially good in this regard, it remains compatible with older code by requiring crates to specify a Rust "edition".
Why are we in this mess in this first place?
And why has it remained so darn popular?
- merrywhether 5y agoThe big difference is Rust and Go are new and learned from their predecessors. If they live long enough, they too will become complicated (well maybe not Go since it’s central design paradigm is simplicity) and seem crusty compared to newer counterparts. Java started simple, but has grown and “forked” and now there’s Kotlin or Scala etc. All that variation was because Java was successful and people wanted to use it but in a slightly different way. JavaScript is the same: people keep evolving it _because_ it is so popular.