TL;DR Of course, I realize that most major websites today are written in them, I'm just offering an alternative.
Hello everyone! Today, so many sites use frameworks like Next.js, Nuxt.js and others that you can't help but think that this is hopelessness, but it's not!
In this article, we will look at the main methods that you can use to create your web applications.
Let's get started!
π¦ Web Components (Vanilla Custom Elements)
Yes, probably the most trivial solution that comes to mind is to create just components, but without frameworks. Although it is trivial, it is quite effective.
class MyComponent extends HTMLElement {
connectedCallback() {
this.innerHTML = `<button>Hello World</button>`;
}
}
customElements.define('my-component', MyComponent);
In native javascript, of course, there have long been solutions such as the CustomElementRegistry interface, which we can access in the example through the customElements property, or the good old template tag along with it.
This is quite a niche thing today, but nevertheless, it is an officially supported technology, so it will be relevant for a long time and will not depend on any module.
π Ajax and HTML
The second method, which is becoming increasingly popular today, is getting data from the server directly in the markup. We describe small settings for the request, and the module will receive the components.
<div>
{{#request src="/api/title"}}{{/request}}
<button data-action="increment" id="btn">Click!</button>
<div>
Clicks: {{#request src="/api/clicks" after="click:#btn"}}{{/request}}
</div>
</div>
The big advantage of this method is that we can take the components to the server and reuse them regardless of the domain. Also, such constructions are quite lightweight. In the example, HMPL syntax was used.
ποΈ CMS
This is the most ancient method and today many developers no longer consider it, but its benefits for business are undeniable - this is a Content Management System.
No matter how far web development has advanced, people will still use WordPress and other similar platforms even in 20 years, because it is convenient and provides many ready-made solutions for business.
πͺ¨ Static site generators
Also an ancient, but still relevant way of creating a website. Here, it is great for creating blogs or documentation, when we do not work with content from users, but only show static data.
As an example, of course, we can cite Jekyll - this is probably the most popular tool for creating static blogs designed for web 1.0 design, but nevertheless, it is also a cool way to create a site. Example of code on Jekyll:
---
layout: default
title: Home
---
# Welcome!
This is the homepage of my Jekyll website.
## Latest Posts
<ul>
{% for post in site.posts %}
<li>
<a href="{{ post.url }}">{{ post.title }}</a>
({{ post.date | date: "%m/%d/%Y" }})
</li>
{% endfor %}
</ul>
Yes, most content is generated via Markdown, so this method is suitable for what I wrote earlier.
β Conclusion
Yes, frameworks are not a panacea today. Website development is good because it allows you to choose a wide alternative between creation methods. If a tool supports compiling code into ready-made HTML, it is already suitable. And it does not matter what language it is written in, even Rust, or something else. Therefore, choosing a method specifically for a task is easier than ever today.
What do you use in your projects instead of a framework? It will be interesting to know in the comments π!
Thank you for reading the article β€οΈ!
Top comments (32)
"You can replace frameworks with..."
*proceeds to list a bunch of other frameworks*
Just because something runs on the back end, or during a build step doesn't mean it's not a "framework"!
I agree though, throwing things like Next at every project is kind of wild, and makes very little sense as a strategy.
And more people should use custom components, you're right there!
Unfortunate π
But I like this post. @anthonymax we should work up an easy way to create a CMS integration.
Thank you! Most likely, such a method has already been created, since CMS has existed for 20 years.
As developers, we love our code and tools. But in the end, the customer doesnβt care if the problem was solved with a hammer or a screwdriver. They just want it solved.
honestly love seeing all the old tools and new tricks mixed like this, makes me rethink how much we really need frameworks - you ever feel keeping things simple actually ends up saving more time or nah
For small projects, it definitely saves time and money, but for large ones, despite all the coolness of other projects, Next.js is irreplaceable.
pretty cool seeing someone call out the basics like this - i always feel like we forget how much can be done just by keeping things simple
you ever notice how sometimes old tools end up working even better when things get too complicated?
Love seeing Web Components get some attention again! For a few projects, I've started using stateful AI-driven builders instead of traditional frameworks, and it really changed my workflow.
Curious if anyone else has tried ditching frameworks for newer no-code or AI-powered tools?
I think it's worth a try. Web components are like a built-in framework in javascript, and many people just don't know about it! Well, and of course, dynamically obtaining components using all sorts of HMPL, Alpine.js, HTMX shouldn't be denied either.
Jekyll is very goood! Nice post.
Jekyll for Blogging - Timeless Classic
Yep. good
Man, this kinda stuff always gets me thinking about what I actually need versus what everyone else is hyped about. Love seeing these options laid out.
Alternative is the main thing
Great article!
Thanks!
Appreciate the insightful breakdown of alternatives to mainstream frameworks. Revisiting native Web Components and lightweight approaches like HMPL.js is a great reminder that simpler tools often suffice.
I've found that it's often better to start with a simple base β plain HTML, small libraries, or native web features β and then scale up only when the complexity justifies it. Jumping straight into a framework can lead to building your app around the tool, rather than around the problem you're trying to solve. That inversion often adds unnecessary weight and long-term maintenance costs.
Great to see more articles like this challenging that instinctive framework-first mindset π
Pretty cool how going back to basics actually holds up. Always makes me second guess jumping on the next big thing right away.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.