Frontend Anxiety

Disclaimer: This article merely expresses my personal viewpoints and thoughts, with no intention of criticizing fellow industry professionals.

The Maturing Frontend Landscape

I believe the frontend field (referring to web development here) is gradually maturing. Frontend frameworks adopt the core philosophy of component-based architecture and reactivity, combined with their unique syntax, development paradigms, and philosophies, which can handle most use cases. Most current improvements focus on build tools—such as using esbuild, vite, and snowpack to improve compilation speed and developer experience—or various optimizations on existing frameworks, such as Vue 3 introducing the composition API or React’s recent announcement of React Server Components, reducing developers’ cognitive load across various dimensions.

Another trend is the integration of browsers with other sensors and communication protocols, such as the Web Serial API, Web Bluetooth, and Web NFC. With the help of the browser, users no longer need to install additional software or drivers; everything can be handled directly within the webpage. For these types of applications, the webpage is at most just a shell. It doesn’t necessarily need to look visually stunning—as long as it can connect and interact with the device smoothly, it does its job.

On the other hand, CSS frameworks and component libraries have also matured, meaning the barrier to building a good-looking web app is getting lower and lower. Often, it’s just about browsing GitHub, picking a library you like and feel comfortable with, and tweaking some code. I feel that what current frontend frameworks offer has gradually surpassed what most websites actually need. After all, not every website is Facebook, Netflix, or Airbnb.

Translator

I feel that writing code nowadays is a bit like the work of a translator: translating requirements into code, maybe throwing in some tests and accessibility features if you’re diligent, but essentially barely different from being a translator. This kind of grunt work will eventually be replaced by AI, or handled by interns assisted by AI to write the code.

During a previous livestream, I used Copilot to write Vue 3. Although the features built during the stream were relatively simple—so its reference value might not be that high—seeing the code generated by Copilot still made me feel that its potential is genuinely exciting. When simple implementation code can be handed off to AI, we can spend more time on other things worthy of investment.

Here are a few other examples of using Copilot, all automatically generated by AI:

• Wanting to print current variable values to Serial: I only needed to declare a buffer, and Copilot guessed which variables I wanted to print based on the function’s context

• AVR Timer configuration: Usually requiring a datasheet lookup to know which register to use, Copilot directly gave an answer (even though it wasn’t quite what I wanted)

• Based on code snippets and existing functions, Copilot guessed that I might want a stop function, and the implementation was very close to what I had in mind

I know some might counter: “But everything still comes down to fundamentals!” That’s true. For software engineers with solid foundations, these are merely tools, and with the right mindset, there is no need to fear change. But what follows is where my discomfort truly lies.

The Web Is Merely a Medium

Many web development applications fall under the category of a “medium” or a “carrier.” For example, if I want to open an online shop to sell products, the webpage is merely a tool that helps execute transactions. However, an online store website alone without products cannot generate revenue. A developer could build a website with features identical to Netflix, but without film production, studios, post-production, and distribution channels, nobody is going to pay for it. PCHome’s website looks ugly, but they nailed the logistics tracking, warehousing management, and payment processing behind the scenes—things that cannot be achieved by a webpage alone. Even if a blog is packed with flashy, magical features, it will not attract readers without compelling content.

I bring up these examples to illustrate one point: web pages are often just a medium. To me, creating value purely through a webpage itself is extremely difficult, because the value stems from the underlying services and products.

There is nothing inherently right or wrong with this. Ever since the dawn of the internet, the webpage has played the role of a medium, and that has never changed. Yet for me, I’ve started feeling anxious about being just a medium, for a simple reason: I cannot directly create value. Once that thought took root, I felt like I was standing on an unstable sandcastle. To be blunt, it feels like I’m unwilling to merely build pedestals for others. I acknowledge that even as a medium, there are always areas worth improving, and being a medium certainly doesn’t mean having zero value. It’s just, as I mentioned, a personal mental hurdle I can’t quite overcome.

The Web Relies on Massive Abstraction

The essence of web development involves four key elements: HTML, CSS, JavaScript, and the browser. How HTML, CSS, and JavaScript evolve depends on the implementations of various browser vendors.

For developers, knowing the syntax and rules of HTML and CSS, paired with JavaScript, is enough to start building web pages. The rest is handed over to the browser. How does HTML render on the screen? How is JavaScript compiled? What is the implementation behind the JIT compiler? How are HTTP requests established? How is video encoded and decoded? Not knowing these doesn’t matter; the browser handles it all for us. I want to emphasize again: whether one understands these things is neither right nor wrong—it’s simply my own psychological hurdle. Still, this level of abstraction makes me anxious, making me feel as though I am merely consuming the fruits of technological evolution. I know every technology inherently involves abstraction to some degree—otherwise, every developer would have to write machine code—but thinking about it carefully, the degree of abstraction in the web is truly astonishing.

The Web Sits at the Top of the Pyramid

Since web pages rely on browsers, and HTML, CSS, and JavaScript standards are completely public, any evolution must go through proposals, drafts, final specifications, and finally, browser implementation. Although Chrome often leads the pack and provides various experimental APIs, platform-specific limitations still drastically restrict use cases. The Bluetooth and NFC mentioned earlier existed years ago and were taken for granted on other platforms, yet on the web, developers have to wait for browsers to implement them before they can be used, limiting technological advancement.

It feels like a new technology has been around for ages, and when browsers finally implement it, you get super excited—only to realize that everyone else has known about it and integrated it into their services long ago.

In Summary

To sum up, the sources of my anxiety are:

• Web pages are mostly just a “medium” and a “carrier,” making it harder to “directly” provide value
• The frontend domain has matured
• Most code is just translation and can be replaced by AI
• The web itself relies on massive abstraction

Value Creation

I mentioned a similar concept in my article On Value. As long as a kitchen timer looks aesthetically pleasing, consumers will pay for it even if its functionality is basic (whether high-volume, low-margin business models have value is outside this discussion). Yet, convincing users to pay that same price for software is remarkably difficult. Another example is SwitchBot, which I’ve been loving recently. Looking closely at its mechanics, it’s quite simple: connected via a Bluetooth-enabled SoC, integrated with a mobile app and various major services, resulting in an excellent IoT product.

Step One

I want to position myself closer to being a value creator, and over the past year, I have been moving in this direction. My first step was diving into hardware and IoT applications. Nowadays, you can buy low-power microcontrollers like Arduino (made in China), AVR chips, Raspberry Pi Pico, and STM32 at very low prices. Grab a breadboard, soldering iron, and a few electronic components, and you can start experimenting immediately.

After this past year, to be honest, I’ve grown increasingly bewildered. On one hand, doing hobby-level development is undoubtedly a long way off from competing with seasoned industry veterans. On the other hand, looking at the salaries in related fields (embedded systems?), they are discouragingly low, making me reluctant to switch careers entirely. Being bewildered might be a good thing, though—at least my current life affords me the leeway to tinker with these things, and being able to acquire them at such affordable prices is something to be thankful for.

Thinking about it, my only real advantage is probably that almost everything I learned back in vocational high school can be put to use: registers, multiplexers/demultiplexers, adders—circuits I was battered with over and over back then. Transistors, amplifier circuits, oscillators, rectifiers, resonance—things that were once just test prep material turn out to be so precious today.

Step Two

My second step was trying to make experimental circuits look more like finished products. I went to learn basic 3D printing and 3D modeling in Fusion 360, while trying to understand PCB manufacturing. For instance, to understand how capacitive keyboards work, I designed a PCB myself and had it fabricated.

Aside from discovering circuit errors that forced me to pause progress, once I understood the whole process, I realized it wasn’t as difficult as imagined. It just takes time and patience to get familiar with the workflow, much like any other domain. I have other commitments to attend to recently, but once things settle down, I’ll be able to resume. I hope to see a finished product in my hands one day.

Step Three: Hardware-Software Integration

As mentioned earlier, web technology advances are constrained by browser implementations, so I recently started exploring platforms with higher possibilities. Currently using a MacBook and an iPhone as my daily driver and phone, I started with iOS. In the video, I connected a Bluetooth module to my MacBook, syncing the current Pomodoro timer status with the computer. I can control the status directly on the computer without wrapping it in a browser, connecting directly via CoreBluetooth.

Although the example here is simple and the circuit looks rough, the concept I want to convey is that hardware-software integration (or IoT integration) can elevate value even further. A Pomodoro notification that might otherwise be easily ignored can be resolved with a physical buzzer and LED display, and the same principle applies to other applications.

Step Four

Step four is trying to understand the Linux kernel. While smaller applications can be handled by microcontrollers like AVR, many embedded applications are built on the Linux kernel or require writing drivers.

This step is still a bit far off for me.

The Next Step

Honestly, I don’t know what the next step is either. If you have any ideas, feel free to tell me on Twitter.

Looking at it this way, does my definition of value sound like something “tangible”? At this stage, yes. Compared to software, I feel these things create value more easily. However, applications like machine learning, AI, game development, data science, and video editing software—while being software—can, to me, directly produce value. Although writing UI interactions is still fun, it’s about time I explored other horizons.