sbjs

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.

It's English, it just looks like regex. In English, the ? belongs inside the parens in this case.

Just updated the text to be hopefully much clearer.

Oh no, I must have mis-explained it.

The file `site/myfile.js` does exist. All FileTree does is recursively load all files in a dir into memory.

The `useTree` module hook does two things:

* Pulls the file from memory when loading it instead of from disk

* Adds a cache busting query string when resolving it for invalidation

Combined with tree.watch(), this essentially allows you to add a very lightweight but extremely accurate hot module replacement system into Node.js

    const tree = new FileTree('src', import.meta.url)
    registerHooks(useTree(tree))
    tree.watch().on('filesUpdated', () => import(tree.root + '/myfile.js'))
    import(tree.root + '/myfile.js')

Now save src/myfile.js and see it re-executed

Just added some code samples, thanks for the suggestion.

Can't remember, was like 10 years ago. But basically after I finished mastering the last feature I needed to, probably macros.

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.

I guess that confirms my theory.

Thanks, yeah it sounds like we have similar goals. Where's your project so I can take a look?

Your patience with Michael Saboff is incredible.

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.

Yes.

I posted an example in the thread.

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 :)

Full title: A letter to the Rev. E. B. Pusey, D.D. on his recent Eirenicon. by John Henry Newman, D.D., of the Oratory.

I wrote one and it's the only software I still maintain and am proud of. I'm kind of inventing a new React like thing in it. It's way cool.

TypeScript is no headache for me and has no header files.

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.

[1] https://github.com/sdegutis/immaculatalibrary.com

Having written ObjC since 2009 or so, honestly it's a fine language, and although I wrote a fair bit in Swift, I don't really see it as a significant improvement over ObjC, which is Good Enough™ to keep using. Something has to cause serious friction to be replaced with something significantly better, and ObjC/Swift just don't fit that pattern.

> where the term becomes meaningless

Sure, you're welcome to just stop examining thoughts at the surface level and not dig deeper. Other people here seem content with that. I'm not.

That's still following an objective perceived benefit: quenching a passion and satisfying curiosity.

You have an implicit assumption that the benefit of learning information always justifies the effort and time spent on learning it. I don't think that's a given or true.

Not everything said is worthy of being heard. True yesterday, today, and forever.

Our models of science are all going to be slightly wrong if there actually is a divine being that intervened in the events of history and changed or updated the laws of nature six distinct times during the genesis of the reality we know and experience scientifically. If this actually happened and we don't account for it, but try to answer questions with the incorrect assumption that the laws of nature have always been static and immutable, we're going to derive incorrect inferences.

Yeah see there's the logical fallacy. Thanks for confirming.

Absolutely this is where we diverge. The nature of logical fallacies is that you generally can't recognize when you're committing one. In this case one of us is, and by definition neither can know which. To resolve that, I don't rely entirely on myself, but examine the logic of many others, which I'm sure you also do. But again where we differ is that I only trust the logic of those who have proven to have very good moral character as well as high intelligence and much knowledge, such as John Henry Newman.

Hey Jesse, hope you're doing well man. You and I talked about this topic a bit in the past, and since then I've had a little more insight into these issues:

1. Burnout happens when we don't believe in a cause or our belief in it is unjustified, whether we realize it eventually or intuitively understand it without it being conscious yet. In all three of these cases, the reality is just that it's not worth doing in the bigger picture.

Obviously, the question of why something is worth doing is complex. I'll admit that there's plenty of reasons for doing things that we ourselves aren't aware of for a long time.

I had a passion and almost obsession for solving software problems for decades, and I didn't know why, but I just followed the flow throughout it all. Eventually it led to a short-lived career, and the only concrete result of it so far is immaculatalibrary.com, but there's also the extremely in-depth knowledge and understanding of logic that I gained from it all.

Honestly I'm able to continue to work very steadily on immaculatalibrary.com, making incredible progress in the past month alone, without any burnout, because I fully know that it's worthwhile, even without explicitly being able to describe why.

Countless reasons for writing software are purely insufficient. Money, fame, solving problems we think are huge, inflating our egos, etc. Fortunately I have no following for my pet software project, so none of these things cloud my vision, and I'm able to focus on it for what it is, and for its only clear and immediate end: publishing and digitizing certain public domain books I find useful and think other people should also.

2. Burnout also happens when we realize that we're building a mansion on top of a pile of garbage. When my site was written in Jekyll or Node.js + Express.js + Postgres + Pug or any other technology I experienced with, it was incredibly hard to move forward and make real progress. I had already resolved to maintain the website indefinitely, but I gave up on it intermittently when I made it too difficult for myself to make literally any changes to the website, sometimes for months on end.

The solution for me was to start from absolute scratch, examine the principles of how I wanted to write the site, build it slowly according to that, re-examine these principles regularly in light of what I had already made and how it was working out, and evolve and update my method accordingly.

And honestly, during most of the past 2 years, I had a website building app that I am not proud of at any of those iterations. But I am proud of what I have now. And it's very possible that I won't be proud of it in the future for what it is now, in the same way. But that doesn't quite matter. As long as I'm proud of it in the moment, and happy with it, while admitting to myself that it's an evolving WIP, and knowing full well that this is always going to be a dynamic process for myself, then it's good enough for the purpose it has.

But that's just the nature of software. It's never finished, but it can be finished in the moment for the job you need at that moment, as long as you examine what the job is and what it should be. The only way I've solved burnout for myself is making sure that the source and destination are satisfactory to me and that I'm fully honest with myself and open to the facts.

I genuinely feel like there's two camps of professionals: those who know how to do something and do it extremely well; and those who know how to describe something and break it down very well. The former are the ones making the magic happen, like Fabrice Bellard. The latter become very influential teachers like Bob Martin. Both are needed (although the former more so), but the latter usually get all the attention and credit.