I have never understood why nobody wrote a web browser on top of SmallTalk.

> even though free software already gives you that independence.

No, not in the way I'd want (and probably not in the way parent wants). For all the same reasons. If you are given something you cannot understand, you depend on the provider for support of the thing you cannot understand. Even if your PC were to be shipped with the blueprints for the CPU, you'd still depend on the CPU manufacturer to make your PCs. The fact that you can sort of figure out how the manufacturer made one doesn't help you to become the real owner of the PC (because of the complexity of the manufacturing process that will make it prohibitively expensive for you to become the PC true owner).

But, let's move this back into software world, where the problem is just as real (if not more so). Realistically, there are only two Web browsers, and the second one makes every effort to alienate its users and die being forgotten and irrelevant. Chrome (or Chromium and Co) are "free", but they are so complex that if you wanted a substantial change to their behavior, you, alone wouldn't be really able to effect that change. (Hey, remember user scripts? Like in Opera before it folded and became Chromium clone? Was super useful, but adding this functionality back would be impossible nowadays without a major team effort.)

So... the Chromium and Co aren't really free. They are sort-of free.

There are, unfortunately, many novel and insidious ways in which software freedom is attacked, subversion attempts come in a relentless tide. Complexity is one of the enemies of software freedom.

There is one such client architecture. It’s called the web. You are describing the present state.

Extremely valid counter points, thank you.

We already interact with false reality through our "old school" computers – internet is full of bots arguing with each other and with us. But my proposition doesn't have to distort the interpreted content.

Neural nets (RNNs) are Turing-complete, so they can simulate web browser 1:1. In theory, of course. Let say we find a way to train a neural net to identically simulate web browser. The weights of this blob might at first seem like an opaque non-sense, but in reality it would/could contain a more efficient implementation than whatever we have came up with.

Alan Kay believed computer science should take its cues from biology. Rather than constructing software like static buildings, we ought to cultivate it like living, evolving organisms.

No, GPUs are not needed for efficient inference.

https://arxiv.org/pdf/2411.04732

Oh, I see now you've edited that to say:

> They achieved it a few times before in 10000 lines (Smalltalk-80 and earlier versions), a little over 20000 (Frank) and 300000 lines (Squeak/Etoys/Croquet)

Smalltalk-80 is significantly more than 10kloc. 6–10kloc gets you a Blue Book virtual machine without the compiler, editor, GUI, class library, etc. The full system is about 80kloc (Cuis is a currently runnable version of it, plus color: https://cuis.st/). Nobody's seen Frank (though you say you have a mostly working copy, I note that you haven't included a link). The 300kloc estimate for Squeak with all the trappings is at least in the ballpark but probably also a bit low.

None of the three contained spreadsheets, "social media" similar to Mastodon or MySpace, or a web browser, though they did contain a different piece of software they called a "browser" (the currently popular term for such software is "IDE" or "editor".)

You could implement those features inside that complexity budget, as long as you weren't trying to implement all of JS or HTML5, but they didn't. In the case of Smalltalk-80, those things hadn't been invented yet—though hypertext had, and Smalltalk-80 didn't even include a hypertext browser, though it has some similar features in its IDE. In the other cases it's because they didn't think it was a good idea for their purposes. The other two systems do support hypertext, at least.

These systems are indeed very inspirational, and they pack a lot of functionality into a small amount of code, but exaggerating their already remarkable achievements does nobody any favors.

you can see for yourself, e.g. by looking at the Smalltalk emulators that run in the browser, reading Smalltalk books, etc.

I think it's the "blue book" that was used by the Smalltalk group to revive Smalltalk-80 in the form of Squeak. it's well-documented for instance in the "back to the future" paper. I haven't had the fortune of studying Squeak or other Smalltalks in depth but it seems fairly clear to me that there are very powerful ideas being expressed very concisely in these systems. likewise with VPRI/STEPS.

so although it might be somewhat comparing apples to oranges, I do think when, e.g., Alan Kay mentions in a talk that his group built a full personal computing system (operating system, "apps", etc) in ~20kLOC (iirc, but it's the same order of magnitude anyway), that it is important to take this seriously and consider the implications.

similar when one considers Sutherland's Sketchpad, Engelbart's mother of all demos, Hypercard, etc. and contrasts with (pardon my French) the absolute trash that is most of what we use today (web browsers - not to knock the people who work on them, some of whom are clearly extremely capable and intelligent - generally no WYSIWYG, text and parsing all over the place, etc etc)

like, I just saw a serious rendering glitch just now while typing this, where some text that came first was being displayed after text that came later, which made me go back and erase text just to realize the text was fine, type it again, and see the same glitch again. that to me seems completely insane. how is there such a rendering error in a textbox in 2025 on an extremely simple website?

and this all points to a great deal of things that Alan Kay points out. some of his quips: "point if view is worth 80 IQ points", "stop reinventing the flat tire", and "most ideas are mediocre down to bad".

not that I've done the LOC calculations, but I would guess Alan Kay, etc. include, e.g., Etoys, the equivalent of paint, and some games in what they consider to be their personal computing system, and therefore in the ~20 kLOC.

and hardware is one of the crucial points Alan makes in his talks. the way he describes it, hardware is a part of your system and is something you should be designing, not buying from vendors. the situation would be improved if vendors made their chips configurable at runtime with microcode. it doesn't seem like a coincidence to me that a lof of big tech companies are now making their own chips (Apple, Google, Amazon, Microsoft are all doing this now). part of it is the AI hype (a mistake in my opinion, but I might be completely wrong there, time will tell). but maybe they are also discovering that, while you can optimize your software for your hardware, you can also optimize your hardware for the type of software you are trying to write.

another point is that any general purpose computer can be used to simulate any other computer, i.e. a virtual machine. meaning if software is bundled with its own VM and your OS doesn't get in the way, all you need for your softare to run on a given platform is an implementation of the VM for the platform. which I think begs many questions such as "how small can you make your OS" and "is it possible generate and optimize VM implementations for given hardware".

also something that came to mind is a general point on architecture, again from Alan Kay's ideas. he argues that biological systems (and the Internet, specifically TCP/IP, which he argues takes inspiration from biology) have the only architecture we know of that scales by many orders of magnitude. other architectures stop working when you try to make them significantly bigger or significantly smaller. which makes me wonder about much of hardware architecture being essentially unchanged for decades (with a growing number of exceptions), and likewise with software architecture (again with exceptions, but it seems to me like modern-day Linux, for instance, is not all that different in its core ideas to decades-old Unix systems).

I don't think supporting a lot of different hardware is a big factor, but if you think it is, building standardized hardware to your liking is a pretty affordable thing to do today. You can use a highly standardized Raspberry Pi, you can implement custom digital logic on an FPGA, or you can wire together some STM32 or ESP32 microcontrollers programmed to do what you want. Bitbanging a VGA signal is well within their capacity, you can easily get US$3 microcontrollers with more CPU power than a SPARC 5, and old DRAM is basically free.

I think it's probably possible to achieve the level of simplification we're talking about, but as I explained in https://news.ycombinator.com/item?id=43332195, the older systems we're talking about here are in fact significantly more code than they are being represented as here.

L11n message catalogs (.po files, which I think is what your remark about i18n is intended to refer to) are not conventionally considered to contain lines of source code.

You can write a lot of games in not much code, especially when efficiency isn't a major concern. I've made some efforts in this direction myself.

Without a game engine, Tetris is maybe 200 lines of JS http://canonical.org/~kragen/sw/inexorable-misc/tetris.html, 200–300 lines of C (building on the fairly minimal graphics library Yeso) https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/tetris... https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/tetris..., or 300–400 lines of assembly when optimized for small executable size http://canonical.org/~kragen/sw/dev3/tetris.S https://asciinema.org/a/622461. The fairly elaborate curses Tetris in bsdgames (which I didn't write) is 1100 lines of C. Emacs comes with a tetris.el (which I also didn't write) which is almost 500 lines of Lisp.

Space Invaders without a game engine, using only a color-rectangle-fill primitive for its graphics, is about 160 lines of JS http://canonical.org/~kragen/sw/dev3/invaders ; when I factored out a simple game engine to make the code more readable, and some added elaborate explosion effects, it's closer to 170 lines of JS http://canonical.org/~kragen/sw/dev3/qvaders. (These have a bug I need to fix where they're unplayably fast on displays running at 120Hz or more.)

A minimal roguelike, hunting treasures in a colored ASCII-art maze, is 54 lines of Forth: http://canonical.org/~kragen/sw/dev3/wmaze.fs https://asciinema.org/a/672405.

And, though it doesn't quite rise to the level of being a game, a Wolf3D-style raycasting engine with an editable maze world is about 130 lines of JS http://canonical.org/~kragen/sw/dev3/raycast.

I didn't write this, but you can write Pong in JS in Notepad in five minutes: https://www.youtube.com/watch?v=KoWqdEACyLI

Emacs comes with a peg solitaire (which I didn't write) which is under 400 lines of Lisp.

The Hugi sizecoding competition delivered a lot of games that were under 200 bytes of code: https://www.hugi.scene.org/compo/compoold.htm

My experience writing these tiny games is that a lot of the effort is tuning parameters. If Tetris speeds up too fast, it's too frustrating; if it speeds up too slowly, it's boring. If the space invaders drop too many bombs, or advance too quickly, it's too frustrating; if too few or too slowly, it's boring. I spent more time on the explosions in Qvaders than on writing the entire rest of the game, twice. This gameplay-tuning work doesn't show up as extra source code. All of these games significantly lack variety and so don't reward more than a few minutes of play, but that's potentially fixable without much extra code, for example with interesting phenomena that stochastically occur more rarely or with more level designs.

MacPaint, for what it's worth, is about 2000 lines of assembly and 3500 lines of Pascal: https://computerhistory.org/blog/macpaint-and-quickdraw-sour... but you could clearly put together a usable paint program in much less code than that, especially if you weren't trying to run on an 8MHz 68000 with 128KiB of RAM.