(The Only Current Alternative: Vanilla JavaScript

I've seen developers who have been working with C for a long time, still developing with MFC (Microsoft Foundation Classes). The reason is simple: there are no real alternatives for building UIs in C . While Qt exists, it requires a commercial license for professional use, making MFC the only option.

MFC provides basic UI components, but it is still capable of creating production-level programs like CAD software or applications for hospitals.

The current state of the JavaScript ecosystem is quite similar.

There is no framework that has been built specifically to address the goals of HPSE. While there are game engines like Babylon.js, these only offer features for 3D graphics and do not provide an overarching structure like React does.

So, in the end, it all comes back to Vanilla JavaScript and TypeScript. It’s not that developers use Vanilla JavaScript because they love it; they use it because there’s no other choice. Just like in the early days when developers had to build everything from scratch in C due to the lack of commercial frameworks, we now face the same situation in JavaScript. There is no existing framework that fully meets the demands of HPSE, so we are left to manually develop with Vanilla JavaScript.

And frankly, this isn’t exclusive to JavaScript. It’s true for most other languages as well.

There’s a saying, "There’s no such thing as a free lunch."

Many of the programs that started with grand ambitions to break new boundaries have ended up relying heavily on custom features built directly within the programming language. HPSE, too, began with the vision of one day running native programs in the browser, and for now, it must be written piece by piece in Vanilla JavaScript.

Some might argue, "Why not just abandon JavaScript and use C or Rust to create a WebAssembly (WASM) module and run it in the browser instead?"

There’s a good story that answers this question.

The leaders of Babylon.js and Three.js were once asked in a comment whether WASM technology would be the future of their engines. Their answer was "No."

The reason is simple: C /Rust code doesn’t run directly in the web environment, which makes debugging more difficult. And thanks to the advancements of the V8 engine, JavaScript can now achieve high performance. JavaScript is a scripting language that runs directly in the browser and offers high productivity—there’s no need to abandon these strengths.

In the past, programmers competed by developing their own operating systems. But after Windows, Mac, and Linux became the standards, the focus shifted to how to build programs that run on top of these systems. Similarly, browsers today have evolved to a point where it’s reasonable to think about how to build programs that run within them.

If there were clear lines about what JavaScript should and shouldn’t be used for, and if high-end tasks were truly unsuitable for JavaScript, then Microsoft would never have started the Babylon.js project, and Three.js would never have been created. The same goes for WebGPU, which is being established as a new web standard.

Recently, I’ve been reflecting on my identity as a developer, questioning what exactly "frontend" means and whether that term can truly encompass the scope of web client development.

I’m sure there’s plenty of misinformation in my thoughts, but I’ll be posting this as my first blog entry to consolidate what I’ve been thinking.

The above is the detailed content of (The Only Current Alternative: Vanilla JavaScript. For more information, please follow other related articles on the PHP Chinese website!