It's a highly optimized and extremely simple yet robust implementation of it, sure. Is that reason to dismiss it?
Consider Vite's node-side HMR implementation. It creates its own module system on top of Node's native module system, using `node:vm`. So its modules are really second class citizens that have to be glued to the native module system.
This library used to do that, but moved to using Node's native module hooks, so that there's nothing magical going on, and you can still use the `import` expression to import your HMR modules, they just auto-update when saving.
That's orthogonal, and in fact you probably would use TypeScript to translate JSX to JS when using this library. What this does is (a) provide a Node.js module hook to call your transpile function when it encounters TSX/JSX files, and (b) provide a Node.js module that lets you remap imports, including "react/jsx-runtime" if you want a different JSX implementation.
To clarify, I don't mean that Rich didn't also have extremely good reasons to make Clojure, given he was using Java (and maybe C++) in 2007. They're not the best languages now, but they were so broken back then that they practically caused the language revolution that caused Clojure and Go and Node etc to flourish.
I thought it was self explanatory. It had new idioms I had not yet learned and internalized, so I fully absorbed it. When that was finished, I needed something else to do the same thing with. It's like listening to a song on repeat 10-100 times (depending on the song) when you first hear it. You get everything you can out of it and move on when it's empty.
Infeasible not because it's difficult but because you have more awareness of your limited time that you have to prioritize, and maintaining software falls lower and lower on the list of things you should do.
Hi everyone. I know that's a bold statement you'd expect from a new coder and not an experienced guy unless it's the real deal. And I've got so many decades of experience that I'm really looking forward to hearing feedback :)
It's a false dichotomy to dislike OOP or prefer it. It's like saying I prefer hammers over screwdrivers. Just learn how the tools you have should be used and use them well.
The only app I'm currently maintaining and proud of[1] makes tons of use of "traditional" OOP. It uses lambdas and FP when necessary. I think it makes absolutely no use of JavaScript's dynamic features. I'm fairly sure this code would port easily to ObjC.
After 15-20 years, you just get bored of doing things in novel or "pure" ways, and do the bare minimum needed to get the job done that's in front of you.
Consider Vite's node-side HMR implementation. It creates its own module system on top of Node's native module system, using `node:vm`. So its modules are really second class citizens that have to be glued to the native module system.
This library used to do that, but moved to using Node's native module hooks, so that there's nothing magical going on, and you can still use the `import` expression to import your HMR modules, they just auto-update when saving.