I don't like JS, so here's me coming up with a plan to replace it.
Eyo, Levi here.
You know what I love about programming languages? Static typing, easily understandable code flow, ability to refactor the code while knowing exactly what is impacting where
[TODO: Image of the robot reading a 'signs you suffer with stockholm syndrome' book]
The JavaScript programming language, the one everyone loves to hate. Back when it was made, it made sense. There was a need for something that allowed to add some quick interactivity to pages in order to allow for some sort of form validation before a request was sent, to avoid a full round-trip to the server and back. Yet, they managed to take what was meant as a small tool, and do with it what programmers always do, not think about why!
Everyone who knows me knows one indisputable fact: I. Hate. JavaScript. Always have, always will. Now, to be fair, JavaScript does have some redeeming qualities. It's flexible, prototyping is absurdly fast, and hey— spinning up a Node REPL to test a few lines is actively useful. Compared to Python, it's... acceptable.
But here's the thing: JavaScript sucks!
It has no static typing, which means every slightly complex codebase is a complete choose-your-own-adventure nightmare. Why is this goddamn variable suddenly returning [object Object]? I don't know! You don't know! God has left us!
Also, it's S L O W. Not as bad as Python- and there goes the people who disguise C++ code as Python code.
Writing in JS feels less like coding and more like arm wrestling a language that learned self-defense from a YouTube tutorial.
And of course, let's not forget the phase when they tried to face-lift JavaScript with a new standard, in order to make JavaScript great again! And the solution for this problem ended up being! ECMAScript. What the f-
XKCD #927 - Standards
The idea behind ECMAScript is novel, a standard way to make JavaScript a singular language that will behave the same in all browsers(If you didn't knew, that wasn't always the case... Thanks Microsoft... Or still isn't, thanks Google.) But they managed to make everything 10 times more complex than it already was. Every year introduces yet another new features and functionality into a already broken pile of garbage, in hopes that if the pile is big enough, it'll fall down into a singularity that will magically solve all problems!
And of course, as if it wasn't enough, Microsoft of all people had the bright idea to make yet another programming language! Is it the 7th? 8th? Just how many languages does Microsoft-
Please someone get Microsoft some condoms already
And their (questionably bad...) response to JavaScript was TypeScript....
Changing the font and color of your bank account doesn't make your crippling debt any more bearable.
It isn't even a proper programming language, it is more like a extended dialect that tries to solve some of the pressing JS issues, such as static typing, interfaces, some more easily understandable flow control... Yet it doesn't hide the underlying issues that the language has, it only gives it a new face: variable as any.
Having worked with JS for so many insufferable years, I have made the decision either become a functional memeber of society, or ditch this language for a better one! And you won't believe what was my decision!
I said better-
Starting out the research, my first general idea was to poke around with WebAssembly. For those who don't know:
WebAssembly (Wasm) defines a portable binary-code format and a corresponding text format for executable programs as well as software interfaces for facilitating communication between such programs and their host environment.
If you understood absolutely nothing: WebAssembly = native program, but inside your browser. We came full circle, we are finally back to native programs.
But, WebAssembly solves a few problems. No more having to hadle a metric f-ton of operating system specific cases, or dealing with different libraries for different platforms. No more having to guess whenever you have to use the electric oven or the gas oven for when you decide to put the baby in the oven and the pizza to sleep.
And Rust(I'm a Rustacean if you didn't know), has quite a ecosystem for WASM. Some notable pieces are:
- Wasm Pack - A Rust compiler for WASM
- Trunk - Yet another Rust compiler for WASM
- WASM Bindgen - Bindings generator for Rust WASM modules
- js-sys - Interops Rust with Browser's JS context
And so, I thought: Boy! Maybe I can just use Rust for it!
The start of the disaster
My first thought was: Let's not reinvent the wheel. Grab a library that already does what you want, and go with it. I don't have time to reinvent the wheel! I have places to go, foxes to pat, floof to spread!
So, I went to check on what options I had:
Leptos and Dioxus
I am going to be fair. They are not bad, but... after poking around on their code, they feel bulky for what I need, it gives me the feeling I'm using a chainsaw to cut a slice of bread. It works, but at this point the mess you'll make will completely hinder any result you might get.
Needing a entirely new extesion to the cargo command just to compile or run the code doesn't exactly rings to me as flexible or portable.
Yew and Sycamore
It is not bad, just... It feels like the Sega Dreamcast.
Yew actually feels a bit more reasonable, since it has a more classic HTML feel, it almost feels like nothing had changed at all:
html! {
<>
<h1>{ "RustConf Explorer" }</h1>
<div>
<h3>{"Videos to watch"}</h3>
<p>{ "John Doe: Building and breaking things" }</p>
<p>{ "Jane Smith: The development process" }</p>
<p>{ "Matt Miller: The Web 7.0" }</p>
<p>{ "Tom Jerry: Mouseless development" }</p>
</div>
<div>
<h3>{ "John Doe: Building and breaking things" }</h3>
<img src="https://via.placeholder.com/640x360.png" alt="video thumbnail" />
</div>
</>
}
Yet the React-like approach becomes apparent when everything has to work through state being passed around with Components, and managing lifecycles becomes a pain, as if Rust's borrow checker didn't managed to be enough of a pain in the ass.
But, in overall it is a solid option, just not one I'd make. Maybe if I take one too many drinks and ends up waking up at 3 AM in a coding rampage spree sponsored by the 5 five hours energy drinks that pushed me into the forbidden hour.
egui
We're back to GameDev, holy f-
Egui feels like a entire OpenGL context just to use IMGUI to make a app. It works, and oh boy! It's fast! But at the same time, that feeling of being overkill lingers in the back of your head. Not to mention the fact that needing a graphics card just to render a damn Todo app makes Electron feel more reasonable.
Yet, at the same time, the feeling you get when your egui app runs the exact same in your browser, windows, linux, mac, and even your goddamn Android phone is nothing short of magic... When it works.
In terms of code, it is the most foreign one of all of the options:
pub struct CodeExample {
name: String,
age: u32,
}
impl CodeExample {
fn ui(&mut self, ui: &mut egui::Ui) {
// Saves us from writing `&mut self.name` etc
let Self { name, age } = self;
ui.heading("Example");
ui.horizontal(|ui| {
ui.label("Name");
ui.text_edit_singleline(name);
});
ui.add(
egui::DragValue::new(age)
.range(0..=120)
.suffix(" years"),
);
if ui.button("Increment").clicked() {
*age += 1;
}
ui.label(format!("{name} is {age}"));
}
}
It is not bad, just different enough for you to have to keep going back to the docs until you get the hang of it. And that is actually okay!
Now, to be fair, egui actually have some tricks up it's sleeves, like eframe actually handling most of the lifecycle stuff, which actually makes it appealing and simplified enough to write a small tool. Yet, can't exactly recommend pulling out a large program with it. But hey, what do I know? The crazy ones at ReRu pulled out their entire company using egui, maybe it can brig back your missing father that went to buy milk so many years ago.
And of course, a bad idea comes
Would it be so bad if we went back in time? Back when things were simpler?
I said simpler, not granny-
Back before everything was a app and everyone's attention span went to shit with the invention of the iPhones, most programs were fairly simple. And some of them, actually were fairly simple web pages.
And with the creation of PHP back in 1995, we saw the surfacing of web apps. Simple web pages that allowed you to interact with servers through forms, allowing for a fairly easy way to create programs. It worked for that purpose, so why not go back to that?
For that, I have done some research, and found out... this.
It is idiot proof!
Meet Tera, a templating engine. Now you might be thinking i have completely lost it and went cuckoo! But no. This allows me to write a simple HTML file, with some templating tags (fun fact, this entire site is made with Zola, which, uses Tera under the hood) in order to output HTML from a server.
This lets me spin up a dead simple web server in Rust, and have requests simply output HTML from it. Seems simple, no?
And this is actually something I have been trying to do ever since I started programming and discovered Node.JS, thaks to libraries such as Express and EJS. Yet, it never really felt right with me, needing a lot of steps to have even the most dead-simple programs run properly.
And so, my digging continued until I went for this plan:
- tiny_http - The most dead-simple HTTP server for Rust
- matchit - A dead-simple URL Router
- tera - The templating engine of choice
- tailwindcss - The CSS styling
The keen of you might actually spot the problem in here. It's not that bad...
Okay, it is that bad
You might be quite angry at me for it, but Tailwind is not a good choice. Yet, it is the one I managed to get working without needing to wrestle with Vite, or needing a framework like React to use. I could simply use my own CSS, yet... I'm not good with CSS, so it isn't a good idea.
I have tried picocss, yet it showed to be lacking in some aspects. In the future, I might swap Tailwind with something else.
Wrapping it up
I have decided to wrap it up here despite having just said what my 'stack' is going to be, because this post is already getting too long. Plus, I want to have something more substantial to show off.
The few ones who knows me might have spotted a small repo by my github called micro_http, which is actually the start of my research on all of this.
By the future, I hope on bring more info regarding my progress with this, and maybe some toys(not that kind) y'all can play with.
'Till then, cya next time