sbjs

The burden of proof has already been sufficiently provided by Christianity. Just because many people don't accept it doesn't mean it's not acceptable.

This uses emscripten. Still cool but I was kind of hoping it would have been written in pure TypeScript.

(Dare I say HN is one of them, where the effort is a curated form of elitism, and the mechanism up/down votes?)

There's a psychological basis for people taking pride in a difficult task learned and mastered, and many organizations take advantage of this by creating a culture that rewards this effort when put towards their own products with social status within the organization. It feels manipulative and unethical to me.

It's a logical fallacy to say that a common experience is the only experience, and that fear therefore should be lessened. Perhaps the fear is there for good reason, and perhaps there is a soul and there is moral judgment at death and perhaps our moral character is sealed in stone at death, whether good or bad. Can't rule these out because lots of NDEs say it's a peaceful experience.

Also, why haven't we just standardized on JSX being sugar for {tag,attrs,children} literals? Then it can be manipulated at runtime however anyone wants, and we would have had so much fewer problems with basically everything around it.

Also it was very tempting to have JSX compile into literal strings, effectively being a composable variant of tagged template literals with better IDE support, so that <a href={123}/> compiles to a function that returns `<a href="123"></a>`. It would have simplified the conceptual model significantly, and the implementation almost as much.

But because it would still be joining a bunch of strings together, it's literally about the same speed as the current implementation (which just adds the whole tree to a single array and joins it only once), so there's no real gain there.

And we lose script/style/tag hoisting, which is necessary for components to work the way they do, unless the JSX system is hacked in another (less simple) way to allow for it than currently.

This is similar to a drop-in mod for pico8 games that can turn 2d games into 3d games instantly: https://www.lexaloffle.com/bbs/?tid=37982

So, couple facts about this SSG's design that nobody will ever read:

1. It's hyper-efficient with how it reloads modules, to do the absolutely least amount of work necessary. If a file hasn't changed, it's not touched. If a .ts/.tsx file hasn't changed and nothing depends on it, its exports aren't touched. If it hasn't changed but something has that depend son it, it's function isn't recompiled, only its exports are re-exported by re-running it.

2. Everything in src/ is normal, but everything under site/ is loaded by src/ and compiled via sucrase, and run in its own runtime. This is what allows the psuedo module system above to be so efficient. It's also what makes the JSX feature so simple and yet fast.

3. The JSX syntax essentially compiles down to an object like {tag:string, attrs:object, children:any[]}, which can be manipulated at runtime. This allows for script/style/link hoisting and de-duplicating, which means you can put a css link in a component that's used multiple times in the site, but only loaded in the HTML once, and pulled up into the head element. It's turned into a string by walking the tree and adding to an array and joining it when done. I think it can be improved. For a while it was in the site/ runtime but I saw no benefit to that.

4. Import just uses require under the hood, and importing any file claims a dependency on it which reloads your file whenever the depended-upon file changes, whether the one you're importing is a normal ts/tsx module or a resource file (css, js, jpg, etc).

5. Importing a file tree returns a list of every file under that tree recursively, including future dependencies. So if you `import files from './images/';` then it will reload the file containing this import not only when a file changes in ./images/foo/bar/ but also when one is added or removed from it. This is really helpful in reloading when e.g. new data files are added. And the fact that it returns a flat list of "absolute" file paths (relative to site/) makes it easy to operate on and filter through.

6. When you import a static resource (jpg, css, etc), it returns {path:string, content:Buffer} as well as claiming a dependency on it, so that you can e.g. use the path in a href, or examine its buffer and do something with it, etc. Eventually I want to reintroduce the concept of dynamically generated routes, e.g. given a font dir, you can currently use the Font component, but it genereates a script tag; it'd be better if it introduced a link tag that can be cached by the browser.

7. Components with this are super cool and easy to use, but there's a lot of low-hanging fruit. I'm in no rush to see what kind of things I can do with it, but it's already picking up speed in the past few weeks. One of my next challenges for myself is figuring out how to use the dynamic static resource concept in point 6 to generate unique IDs for pseudo-scoped-css, similar to what react styled-components and all them did.

So cool to see the web reader of archive.org in use on another site besides mine[1]. Also neat how this bridge between the two topics of archaic language and slang is the same one that I cover in my viral tiktok[2], which retells ancient stories traditionally associated with archaic language but in modern slang. There's really nothing about slang that makes it less official than less informal language. Dictionaries don't define language but document its usage. And universities don't define language but study it.

[1]: immaculatalibrary.com

[2]: @gen.z.bible.stories

Good point. I actually did that a few days ago with an extracted lib that became out of date within a day or two, so I made that repo private. This is evolving so fast that I think the same might happen with the readme. That said, the source is incredibly small (400 loc) and straightforward TypeScript.

Overall I'm not super happy with web components to solve the issues of reusability, conciseness, and self-containment.

The most direct problem is styling issues. Cross-component CSS in either direction has some serious limitations. I've written a little bit about it[1] in my blog but the short version is that there are some things that simply become absolutely impossible when using web components.

My main other gripe with them is the need for a build phase. The nature of WC almost begs for them to eventually become zero-build-time, but right now this just isn't practical. It requires too much boilerplate in every .html file (utf8 is broken on my site), the syntax isn't natively there even with tagged template literals, and there's no concept of data-list-fetching or data-based file generation.

There's a branch on my personal website[2] where I tried to start using web components, and it was so problematic that I long abandoned it.

Overall, I abandoned web components entirely in favor of making my own customized JSX-based SSG from scratch[3] which solves the same problems Lit, Next.js, et al. are intended to solve, but in a completely different way: using components for convenience, conciseness, and reusability, but only at the build-phase time. So far it's a well kept secret, which is probably good since it's been evolving so quickly that I wouldn't have been happy with any iteration being widely adopted so far. (Though I think this morning I finished off most of what I was unhappy with.)

[1]: https://sdegutis.github.io/articles/2023-08-07-modern-90s-we...

[2]: https://github.com/sdegutis/immaculatalibrary.com/tree/reset...

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

> Sometime later, I also learned that "three" is usually the magic number for correctly plugging in a USB Type-A device. It's a maddening dance and it begs the question, why wasn't the Universal Serial Bus designed with a reversible connector from the outset?

Honestly when this is the biggest problem you face on a daily basis, your life must be relatively easy.

I remember using linux pipes for a shell-based irc client like 12 years ago. For most application uses, they're plenty fast enough. Kinda wish I had the source code for that still.

These downvotes for a genuine question (-3 points at time of writing) are why I don't participate in HN tbh. And maybe they're exclusively for my parenthetical request for feedback, in which case, still, like, come on guys. Those downvotes are why my posts and comments always shadowbanned in the first place. And they all started with downvotes for genuine questions. The typical response from HN is "I dunno, maybe post better content." But I post the best content I have in both submissions and comments. So yeah, I guess this community is not for me, that's all I can conclude.

Yeah I've been in that camp since like 2016. TypeScript is basically an essential for me now, and I don't debate it with anyone. If they don't get it, it just gives me a baseline understanding of how little experience they have in real world software development.

When migrating sites built on archaic technology, the best bet usually is scraping the site externally and generating normalized data from it and using that to either build a new site or migrate to a new platform with custom scripts.

This reminds me that I made a way to create love2d fonts using pico8 files and ended up coming up with a 3x4 font that I absolutely love and hope to use in a homemade game one day.

> Isn't it better if let count is reactive by default?

> Well, no. The reality is that as applications grow in complexity, figuring out which values are reactive and which aren't can get tricky.

People keep re-learning that there's a certain amount of context that needs to be explicit, and you can't just imply everything. Just like when ruby and python made the mistake of getting rid of let/contst/var/etc and programmers said wait no that's a bad idea, now it just makes everyone's job harder, because neither the compiler nor the developer can figure out what context something belongs to.

What's the best alternative?

> Finally Fennel includes a macro system so that you can easily extend the language to include new syntactic forms. This feature is intentionally listed last because while lisp programmers have historically made a big deal about how powerful it is, it is relatively rare to encounter situations where such a powerful construct is justified.

In other words, there are serious drawbacks to using macros that are usually outweigh any benefits they might give you.

My fyp is mostly Scott Pilgrim clips and bladerunner2049-esque photography, which is weird because I've never seen Scott Pilgrim vs The World or either Blade Runner. Sure there's occasional dance memes just like there's also random pranks and animated memes which I'm sure everyone sees, but like, the algorithm clearly knows what I like somehow, because I ended up really liking both of those movies after being encouraged to watch them by my fyp.

Can someone explain why a bezier function is used in the mouse app? I would guess it's to help give smoother and more natural movement to the mouse using predictions of where it's going based on last few points, but I can't read Rust well enough to make sure.

For me, writing code is always easier than reading it, regardless of who wrote it.

Rarely does an HN comment make me laugh. Well done.

> businesses of fewer than than 250 employees AND less than $10 million in revenue

Seems like they can afford it.

> Have you seen these dehumidifiers? Stop using them or you might die.

I always think this is a funny way to word it. I mean, you're going to die either way. At the most, stopping using them might push it back further. But a car crash might even the playing field too. I think implicitly accepting language like this often indicates that a person isn't accepting the fact of the bigger picture.

Why not? I can't think of anything off the top of my head that I think is fundamentally broken about TypeScript, or even that I strongly dislike about it.

What ways does do the wrong things by default? I can't think of a single one. You might say, well, == is broken and you have to use ===, but that's not "the wrong thing by default" unless you assume that == is what ought to be the default operator and === ought to be secondary. But that assumption has to come from somewhere, and probably comes from the fact that other languages do it that way. But there's nothing inherently incorrect about === being the default operator and == being the rare secondary one. I think the same principle applies to any example you might be able to give me: if you assume that another language is objectively right, only then can you say that JavaScript is objectively wrong in comparison to that language which apparently descended from the heavens.

The second best code is the code that gets the job done.

The best code is the code that also doesn't make it harder to continue to get the job done.