Tukuk-OSEvery software project starts with the same question: what should I use? For Tukuk-OS the answer was Node.js with Express — and even though the choice looks obvious today, it was not necessarily so on day one. Here is the real reasoning behind that decision.
First Consideration: One Language
I already knew JavaScript from frontend work. If I had chosen Python or PHP I would have had to learn new syntax, a new package ecosystem, new deployment methods, and new error handling — all while trying to understand search and crawlers.
With Node.js I only had to learn new things within the domain itself: HTTP, indexes, and API calls. The language, the tools, and the mindset stayed the same. In a small project this context saving is equivalent to weeks of real time.
Second Consideration: Fast to Start
Node.js starts in seconds. node server.js and the server is alive. No heavy control panel, no build pipeline, no configuration explainers. Express adds clear structure: routes, middleware, error handling — all with syntax that reads like a sentence.
Startup speed is not a luxury; it decides whether you finish a feature in the evening or postpone it to tomorrow.
Third Consideration: The Event Loop
Search engines do a lot of waiting work: waiting for external API responses, waiting for disk, waiting for Meilisearch. Node.js's event loop suits this pattern — hundreds of pending requests can be served by one process without starting a new thread for each.
For Tukuk-OS this means a small server can handle concurrent search requests without eating all memory. When you click the Images tab and it calls several external providers at once, this model is what is working.
What I Gave Up
Every choice has a cost. Node.js is less suited to heavy CPU work like large-scale image processing (because one JavaScript process blocks the others). I solve it by simply not doing such work — or, if necessary, delegating it to a specialised tool.
I also lost Python's rich scientific library ecosystem, but a search engine does not need it. What I do need — HTTP bindings, parsers, search clients, loggers — all exist and are mature in Node.
Express: Deliberately Simple
The design decision I value most is not using a heavy framework. Express gives me routes and middleware without dictating how my project must be organised. I can structure files as I like, export functions directly, and add a new route without facing layers of abstraction.
Larger frameworks give you more business features, but they also bring more conventions to learn and follow. For a personal project where I am the only builder, freedom is worth more than imposed structure.
Dependency Management
A fair concern about modern stacks is the number of third-party packages. Node.js has a huge ecosystem, and it is easy to pull in twenty dependencies for what looks like a simple task — meaning more code that is not yours that you must trust and update.
My approach: dependencies only if they solve a genuinely hard problem, and as few as possible. I use Express for the server (mature, widely used, transparent), small libraries for specific tasks, and I avoid "meta" frameworks that bring their own way of doing almost everything.
I also run dependency checks regularly to catch packages that are no longer maintained or have known security issues. Dead packages get replaced or, if small, replaced with a few lines of my own code. The principle is simple: every dependency is a promise of future maintenance, and you should only make promises you are willing to keep.
The number of direct Tukuk-OS dependencies stays in the low double digits, and that is no accident. Every package I add must justify itself by solving something genuinely hard or something that would take days to rewrite properly. By keeping that list short, maintenance time stays focused on code that actually belongs to this project.
What I Would Choose Now
If I started again I might still choose Node.js and Express — but with more testing from the start, because confidence gained from automated tests is something no stack choice provides.
My advice: pick a language you already know, the smallest framework that suffices, and do not let the search for a perfect stack delay the actual building. The best search engine ever built started with a server that only displayed text.