I'm passionate about creating fast and efficient web applications, which is why I've been using Qwik for the last few years instead of popular frameworks like React. I've even launched a client project using it, and the performance was impressive. However, I've encountered some limitations with modern JS frameworks, particularly regarding server-side rendering. In my experience, rendering HTML with languages like Rust or Go can be significantly faster—around 30-40 times quicker—compared to SSR with JavaScript frameworks. Recently, I've ventured into Rust and Axum, and I'm considering a side project to build a social media app similar to Reddit. My goals for this app include: 1) Using server-rendered HTML with templates (like Askama), 2) Creating a frontend that provides a single-page application experience, 3) Minimizing JavaScript use, ideally sticking to vanilla JS unless absolutely necessary, and 4) Ensuring small bundle sizes for quicker load times. I'm curious if anyone here has experience in constructing complex web apps mainly with vanilla JavaScript? How do you manage and organize these apps as they expand? Have you developed your own abstractions or mini-frameworks, and if so, how extensive did they become? Any regrets or lessons learned would also be appreciated!
5 Answers
Honestly, I wouldn't recommend going down this road without a framework. Vanilla JS gets messy very quickly when building larger applications. You'll end up creating your own tools and abstractions, which can turn into a real hassle. Consider adopting lighter frameworks like Svelte or even Alpine.js, which can help manage interactivity without burdening your app with unnecessary weight.
If you’re aiming for a true vanilla JS experience, I’d say go for it, but expect challenges. Performance can be great without the overhead of a framework. Using modern APIs like the Navigation API or creating small client-side routers can yield fast load times, but expect to handle SSR issues carefully. And plan for state management! It can creep up on you faster than you think.
Exactly! The simpler it starts, the messier it can get as the application grows.
I built a desktop app using vanilla JS, and while it worked for a while, I had to eventually add a thin reactive layer. The problem is that with more components needing to react to changing data, things get complicated fast. For your Reddit-style app, I recommend htmx with your Rust templates. You can achieve SPA-like behavior without a heavy framework, which reduces code maintenance. Also, remember that performance issues often arise from database queries rather than SSR, so focus on developer productivity first.
Absolutely! Once you start adding complexity, the state synchronization problem becomes apparent.
I’ve developed a variety of apps using different approaches, and when it comes to restructuring, conventions are crucial. You don’t actually need a framework; what's important is how you modularize your code. My structure is more about creating small, reusable packets for state management and event handling. As for regrets, it's often about not drawing the line early enough with abstractions. Keeping things minimal helps a lot!
I tried something similar about a year ago. I built a project tracker with Rust as the backend and kept the frontend as vanilla JS as much as possible. Initially, it was fantastic! Server-side rendered HTML was lightning fast, but soon I hit a wall when I needed more interactivity. I started creating my own event handling system, state management, and a router. It quickly got messy. My advice? Consider using a lightweight library like Preact or Solid for the interactive parts. They have tiny bundle sizes and allow you to keep the fast server-rendering without creating your own framework from scratch.
Right? Managing state is the trickiest part. Once you have multiple components dependent on the same data, vanilla JS starts feeling chaotic. Using something like Preact ensures you're not reinventing the wheel!

That's a good point! There's definitely a balance between maintaining simplicity and managing complexity.