Web development has been something I have avoided like the plague for years. The main source of this apprehension stems from the strange lack of opinionation that web development has. I think that may sound like a take so absurd it would land me in an asylum, but when I say opinionation, I don't just mean what framework you use, I mean how individual tasks are completed while programming. As an embedded developer that has focused mostly on C, C++ (god help us), and recently Rust, I am used to things not working unless you fully place yourself, mind, body, and soul into the shoes of the original author of the code. If you don't understand the assumptions made or have the expected institutional knowledge, your project will break, or it will run until it will cost an obscene amount of money to fix then then break.

This is totally contrary to the world of web development. I see how the DOM is rendered on the browser as a great analogy for this, as the HTML is streamed in over HTTP[S] the browser is structuring the way the content on the page should be laid out. You may have seen this when on a slow connection, generally it looks like a white background with black text and blue hyperlinks. Interestingly, the partially rendered webpage is normally somewhat functional. Even if you chop the expected HTML document in half in trasit, the browser will give it a solid college try. There are no syntax errors in HTML. This strategy is known as permissive parsing, meaning that if there are any errors the browser will notice them, find a solution in accordance with the spec, and render it anyway. This is a standard that obviously allows a large amount of tolerance in web development which, in many ways, is the opposite of how embedded developers typically control everything possible on their selected platform.

Another example is dependency management and updates. While frameworks like Rust's Embassy have been changing the landscape of embedded work, generally when an embedded system is being made the dependencies are pulled in and once the product is working you stop messing with it. In webdev, it is expected that you constantly iterate and add new features. When was the last time you expected your printer to suddenly have a new feature, or your mouse? The devices that surround us should work as reliably as possible for as long as possible until their eventual destruction, then when you boot up the new one for the first time you'll get those new features. However, websites made 5-10 years ago would look outdated if viewed today. The world of webdev moves at a breakneck pace that only those passionate about it can keep up with. Not only do I not care about JS frameworks, I actively do not want to be exposed to them.

The simple fact that is pulling me towards web development, more specifically making this blog, is that people expect and are used to interacting with web pages. If I want to make products that people feel comfortable using, I need to make interacting with them feel natural and convenient. Creating native GUI programs is, of course, another option. However, it is exceedingly difficult to create and distribute a signed executable that works on a multitude of systems. The way many applications created these days avoid that complication is by using frameworks like Electron or similar that create a native GUI experience by rendering web content. Meaning that web developers can transfer their skills directly into the world of native applications, at the price of a significant abstraction layer between the user and the system. This is not exactly new: .NET and Java have been doing this for years, that is giving the programmer a portable executable by handing the hard parts of portability for them by creating a runtime. So, the two main ways developers are creating applications for native systems recently is by:

1. using Electron (a light weight web browser) or
2. using a real web browser.

This website is a playground for me to explore different aspects of web development and design. The initial version, which is serving this post at the time of writing, is using two main libraries: Axum for routing and Askama for HTML templating. The website has no code running in the browser and renders everything on the server. The main guiding principles of this website is that it makes sense to me to work on and maintain and that it is as simple as possible. I like writing markdown so blog posts are written in markdown and toml makes sense to me so metadata attached to blog posts are stored in toml files. I had to do a fair amount of "boilerplate" work to get it running and there is much that can be done still to optimize performance, the application itself is a single executable running on one machine. A simple diagram of how the binary converts files into content at the time of writing is shown below:

All of that work could have been skipped if I just picked a framework and ran with it from the beginning. I would have had to adapt the way I want to do things for the way I need to do things with a premade framework but I would be confident that it is secure, fast, and easily expandable. So why didn't I just use Leptos, Rust's most popular (by downloads) web framework? Because I had no idea what any of their claims meant, I don't know enough about designing a website to have an opinion on how things should be done. Will I eventually convert this website over to Leptos? Maybe. I don't know yet because I still need time building things from scratch to really figure out what features matter to me and what is just fluff.

So why is it that C/C++ developers stubbornly stick to a JSON parsing library they downloaded in college and never moved on from and JS web developers switch the framework they are evangelicalizing every week? Opinionation. In order to develop and opinion on something you need to:

• Use that thing
• Be exposed to how it is made
• See the results of it's long term use

C/C++ developers make tools from scratch and they are all about 85 years old at this point so they have seen more than enough long term use. Does that make them better developers? No. It makes them better at developing for their particular use case. A use case that is extremely error prone and has a strong focus on stability. Webdev, by its nature of being on the internet, can be updated on the fly. The most major incidents in recent history with web applications, while highly impactful, were fixed globally in a matter of hours.

All that being said, why am I, a developer that prizes everything that web developers despise, trying to make a website? Because if there is anything that webdevs can do it is remain flexible in an industry that is rapidly changing, that flexibility is a valuable trait in any field. Not to mention that if I want to be as productive and impactful as possible I should learn and understand the basics of the most popular way people interact with applications. And on the other side of that coin, I think there are a ton of new developers working in JS that could benefit from the mindset shift that is required to work on embedded projects.

Grab a Raspberry Pi Pico and start making some lights blink (NOT using python), who knows, maybe it'll make you better at centering divs.