HN user

sbjs

962 karma
Posts52
Comments262
View on HN
immaculata.dev 1y ago

Show HN: Mid-level Node.js helpers for building a front-end website

sbjs
1pts0
immaculata.dev 1y ago

Comparing Immaculata to Vite

sbjs
1pts0
immaculata.dev 1y ago

(ab?)using Node module hooks to speed up development

sbjs
38pts16
thesoftwarephilosopher.com 1y ago

Why I ever wrote Clojure

sbjs
89pts50
thesoftwarephilosopher.com 1y ago

Build.js.dev.build

sbjs
1pts1
thesoftwarephilosopher.com 1y ago

Build.js.dev.build

sbjs
1pts0
immaculata.dev 1y ago

A New Way to Vendor

sbjs
1pts0
immaculata.dev 1y ago

Immaculata

sbjs
4pts3
immaculata.dev 1y ago

Show HN: Immaculata.dev, TypeScript DX Primitives

sbjs
1pts0
immaculata.dev 1y ago

Show HN: Immaculata.dev, web build tool for engineers

sbjs
1pts0
github.com 1y ago

Show HN: Immaculata, simple front-end build tool

sbjs
1pts0
thesoftwarephilosopher.com 1y ago

Standardize JSX while there's time

sbjs
1pts0
thesoftwarephilosopher.com 1y ago

I can't delete my framework

sbjs
2pts2
github.com 2y ago

Show HN: A new way to create universal/ssr TypeScript apps with JSX

sbjs
1pts0
github.com 2y ago

Fairly sure I just made something better than React

sbjs
2pts5
archive.org 2y ago

A Letter to Dr. Pusey on His Recent Eirenicon, by Dr. John Henry Newman (1868)

sbjs
2pts1
github.com 2y ago

Show HN: Fast Jekyll Alternative in TypeScript with JSX

sbjs
13pts5
github.com 2y ago

Show HN: Simple/Fast JSX Ssg

sbjs
4pts0
sdegutis.github.io 2y ago

The simplest SSG I could think of

sbjs
2pts0
sdegutis.github.io 2y ago

Severe Imposter Syndrome

sbjs
3pts0
github.com 2y ago

Show HN: Stylus based animating monochrome drawing app in only TypeScript/DOM

sbjs
2pts0
www.thesoftwarephilosopher.com 2y ago

Modern 90s Web Dev

sbjs
2pts1
www.thesoftwarephilosopher.com 2y ago

My Dynamic Static Blog

sbjs
1pts0
github.com 2y ago

Show HN: MMO Pixel Art

sbjs
2pts0
medium.com 2y ago

The MMO pixel art social experiment that was editfight.com

sbjs
1pts0
www.thesoftwarephilosopher.com 2y ago

I just can't write normal software

sbjs
12pts15
www.thesoftwarephilosopher.com 3y ago

Heavily discounted software expert – The Software Philosopher

sbjs
1pts0
news.ycombinator.com 3y ago

I made a new TypeScript runtime on Node.js

sbjs
1pts0
github.com 3y ago

Dice-coefficient: Doubled speed by not using an array

sbjs
1pts0
github.com 3y ago

Server-Side JSX

sbjs
1pts0

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.

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

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.

Immaculata 1 year ago

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

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.

[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.

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.

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.

Awareness at Death 3 years ago

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.