It seems like every week there is another ground-breaking new web framework. Some of them are interpreted, some compiled. Some of them are based on HTML tags, some component driven, and so on.
So, what would the "ideal" framework look like, maybe using ideas of existing frameworks? Of course, no framework is perfect for use everywhere, but what would come close?
Top comments (58)
This might be controversial, but:
My ideal framework would be the lack of one. For me the web itself should change to support modern apps, and remove the need for any frameworks. As the web was never intended for most of the use we're giving it today.
What I mean is, that the technology/language should already provide what you need to build modern apps without needing a framework on top of it.
Needless to say that this is almost imposible, the web can't change as drastically. So we will need too keep with good old js+html+css+framework+libraries.
What would it look like or how would it work? I have no clue
I disagree I even think the web should be just a wasm runtime and it should not even support html/css/js they should be just a stack people can choose if they want and compile them down. Imagine a world where one website UI is powered by HTML the other by SwiftUI and the next by Qt I think the we should have this kind of openess, of course for all this to work the WebAssembly spec needs to have some system level and graphics stuff added and all need to agree on this but in the end the web should just be a wasm runtime/os of the world.
Hey there Ivan!
I don't think I know what you disagree on, you disagree on what my framework would be? or that it will never get to that point?
I have to disagree here, that's what I was going to. There are way to many options to build a website, making it harder to learn and making it quite dificult to beginers to start. As the first challengue is to decide which of the 1000 frameworks to start learning. It also makes it more dificult to introduce standards (just look at javascript, and how it changes from engine to engine), imagine what would happen if you could code them in 10 diferent languages like (Swift, Qt, etc...) what a nightmare.
For me ideally there would be one and only one way of doing it, can seem quite extreme though :D
You think to complicated, you need to think of my concept as an OS for the world, and running wasm is exactly what you want it runs everywhere the same, you said only one way and this is ONE way there is a compile step which makes this possible, and you don't need to learn every language you simply learn the stack you like, the browsers being able only to do what they do now is what makes the ecosystem complicated.
Ohh I see, you mean the web being some kind of OS? that can run any code compiled for it?
Then yeah, I agree with that. That could be one solution, though quite a huge one!
Exactly 😀
1) I think you're talking about front-end web frameworks (i.e. running client side, and by definition today, Javascript enhancements).
2) The original question does hold a similar bias, but I'll note that frameworks exist in a load of other contexts, not least what in web terms would be called the back end.
3) I don't think your dream is so unreasonable or even unlikely per se, but may well be long lasting (so meaningfully not likely to happen). Javascript is, IMHO evolving as a language probably faster than any other. It lags behind frameworks of course, because it's in a different game, namely specifying what browsers should be supporting (their end users if you will are the web browser producers). Javascript frameworks by comparison are the converse in both respects, they have to support popular browsers and their customers are web developers. And so I see the role that these frameworks provide is different but also changing as, over time Javascript absorbs the best of what they offer, that can sensibly we imposed as a standard upon browser producers.
Yup that's correct, I was referring to front-end web frameworks specifically. I don't think we should group/compare front-end, backend and mobile frameworks, as they are world of themselves.
And yea, I agree with point 3. That's the reason why I think it's unlikely to happen, at least in the near future. Though I hope we get there at some point :D
My idea was, if we could build the web now, what would we do differently? Most likely everything
OR IS IT?
I used React/Vue/Angular, hated them all, especially the NPM install needs. The depencies are a disasted.
So, I dug into what's needed to build a SPA 'framework/library'
I made taino.netlify.app/
It's 1 script, no npm install needed [i recommend using live-server just to run it as it updates soon as you make changes]
It's 13KB uncompressed, 3kb compressed via netlify.
To see if it could be used to make a full scale website, I made indiegameshowcase.org as a proof-of-concept-turned-actual-product website.
If you know JavaScript you can write Taino. It takes an experienced dev maybe 2 hours to pick it up, junior devs need a bit more hand holding.
Well said. screw frameworks
They are the most deceiving tools on the web, yet, we happily use them as if they give us convenience.
I'd say create a series of html documents and put them in as template files in a expressjs app and you're good to go. Let us devs sort out the rest.
Exactly
But as you said, this would be impossible. We would have to literally relearn web development.
Not only re-learn it, but re-build it and re-implement it everywhere
I'll start
My "ideal" framework would be a framework which is compiled: it would have components in a file with script and style tags (like Vue/Svelte). As usual, components can be imported, other JavaScript/CSS can be imported, and styles and scripts are scoped, etc. and the compiled output will be HTML (Yes, actual HTML, not just a boilerplate), CSS and JavaScript. AFAIK there is no framework like this, and the closest is Svelte, but Svelte doesn't generate HTML.
I have to ask, why must it be "compiled" ?
What's the benefit?
Like, if i write an email, i don't want it processed and rewritten if my english is good enough to convey the exact same message.
HTML and CSS make the frontend skin and bones There is zero reason for this to be compiled when it should carry no logic.
Javascript adds functionality to this skin and bones, i can see compiling it to play nice is a good idea, though most browsers now understand javascript well so there's no longer a need to make it play nice, it just plays already.
Also, rendering flat HTML out is no longer necessary. Google can index Javascript sites/applications. The other search engines should catch up. Bing can do it some, and DuckDuckGo just copies Bing's results, so i'd say that covers like 99.9% of the western markets [i don't really deal with Yandex or Baidu to know about them]
So I do want a good response on "Why must it be compiled?"
This isn't programming, it's web development.
I'd like to split up parts of the webpage to different files that contain all the needed code for that specific component so that the code base is more structured and I can reuse the components. Sure it's possible to do components without JavaScript frameworks, but including the components is a chore and making them work in every scenario is difficult. Not even talking about configurability of the components.
Components are tricky and can be complex, but we still don't need large frameworks to support them.
I wrote taino.netlify.app in under 30 hours about 2 years ago just to see what the least amount of JS needed is to build SPA websites. The core code can be used to make a 10 page blazing fast site in hours covering like 90% of websites. It's 13kb uncompressed and requires no npm installs, runs as a static site on any service like netlify/heroku/aws S3/digital ocean apps etc.
Since then i've used it on a few small test project and a proof of concept turned into a full scale product indiegameshowcase.org
So frameworks and compiling are really overkill for the web. I fully understand why Google and Facebook need them. With thousands of devs working on platforms processing a trillion requests a day...yes, go all out with code structuring and enforcement of standards.
For the every day dev making blogs, small ecomm, business brochure sites....there is no reason at all we should be using these bloated tools, unless you want a FAANG job I guess, which isn't the worst thing in the world. I just want people to know there are simpler options.
"Compiled" as in "converting structures which aren't actually valid HTML/CSS/JS into HTML/CSS/JS, possibly optimizing the code on the way". Like Svelte
HTML and CSS are fairly straightforward languages.
Perhaps writing valid HTML and CSS leads to devs being more detail oriented.
We have practically a dozen free tools to validate your HTML and CSS if you're not sure it's good.
Learning write HTML and CSS in a different syntax/format to then have a compiler convert it back to proper HTML/CSS makes ZERO sense.
JS is more complex, but again we can do it all with vanilla JS. Svelte is just another iteration of what Angular/React/Vue etc started. You're learning another syntax and when things break you have to debug it "for svelte" instead of writing Javascript and debugging Javascript. [There's a long rant attached to this, but we CAN build full complex websites using only vanilla JS and it really doesn't take nearly as much effort as some would have you believe, plus you can debug all of it because it's just JS]
I'm guessing I wasn't that clear 🤦. By compiling HTML I mean compiling stuff like two way binding, components, and other stuff which may be valid HTML but won't render as you like.
We definitely can build complex websites with Vanilla JS. Frameworks just make it a bit easier (and more maintainable) for us.
Svelte is able to generate HTML. It is called server-side rendering in Svelte and it's possible to do it in the build step.
I have done it for an old version of my work-in-progress website framework. Since then I've switched framework, because Svelte didn't meet my requirements recarding actually the same feature.
I've tried to make my own JavaScript framework like Svelte / Vue with the features I need, but I didn't really succeed. Maybe I'll try again some time.
I'm not so familiar with Svelte, and maybe SSR is possible. I'll try it out.
I'm actually doing the same thing right now. You should definitely try again
Take a look at RiotJS. Now at version 6. It's compiled and has been around considerably longer than Svelte
RiotJS seems nice, I'll try it out. Thanks!
Can you clarify what you mean by this? I'm not sure I understand it.
Consider this component:
If you run this through Svelte, you get this HTML as output:
It's basically a boilerplate. In my "ideal" framework, the
h1element would be there in the HTML (maybe statically embedded, if the framework is really good). This could speed up a little bitI see what you mean now - Something that outputs closer to Static Site Generators without being fully static 😊 That would be amazing!
Why not use a function h1("Headline")? This would be even quicker as it create a DOM element without rendering HTML. And as it is a function, it can be part of any algorithm you want.
Yep, it would! I'm actually building a prototype of something like this.
What about next.js?
It sounds interesting, but I haven't used it, so I can't say much.
Could you imagine a web without HTML? A framework that works on the DOM directly could be much smarter than what we see today. The Document Makeup Library (DML) is one first step in this direction.
DML sounds interesting, but writing a whole lot of JavaScript would feel weird.
No, DML is VERY different.
You do not write too much Javascript. As an example, the DML-homepage was set up using only two short HTML-pages. Each page contains about 100 lines of project specific Javascript-code, no HTML, only very few CSS. Behind the scenes you can use some libraries that do the work for you. So, the whole site with numerous pages was created using markdowns, the content is build dynamically after page load. All the routing is done dynamically while the page content is loaded.
Why do I call this a "framework"? Because it contains everything you need to build a web page or a SPA.
There are lot´s of examples on dev.to that show, that sources usually are very short.
This may server as an example:
HTML
DML
But the approach is far more powerful than you can see from this few lines. Instead of building pages "by hand", you let Javascript do the work. Want to create 10000 buttons? Just write a loop to do the work:
Voila! with only two lines
One library and a text editor is really all you need.
You think, 10000 functions may be too much, can we save some memory?
ok, this was three lines of code, but only one alert function for all buttons.
You will need to learn Javascript, but it is the only tool you will need. This pays back very soon!
The ideal framework for me doesn't get in the way and has just enough tools to get the job done, supports tree shaking, has the performance of hand optimized code, foregoes needless abstractions, provides an enjoyable developer experience and doesn't fill node_modules with a GB of dependencies. It basically consists of manageable reactivity and JSX as a template language (because of the superior tooling). Also, it would be free and open and supported by a welcoming and friendly community.
Only a few weeks ago, I found Solid.js and it seems to be as close to this as it gets.
I would say the closest is Angular. It lacks the better performance and smaller bundle size and more 3rd-parties of other solutions, but it has an amazing philosophy, ease of development and general stability which would really justify some more support from the community instead of pure hatred.
You have mandatory TypeScript and RxJs and first-party packages for routing, fetching and forms, which is pure gold. The rest is meh and should be improved.
Angular is especially awesome when you scale , but it's not the best for small apps.
The ideal framework would be one that doesn't try to put web technologies into everything. Ideally, web frameworks should stay web frameworks. Electron, React Native, stuff like that doesn't make sense to me - why reuse a web-language to do non-web stuff? Just because we can?
Now, sticking to the web, anything that doesn't rely on node_modules (or better - that doesn't rely on the Node way of doing things) at all, no bundling, with the minimal tooling possible. Just plain JS files that you can drop into your HTML files and be good to go.
Seriously speaking, front-end development is a nightmare. Even the so-hated PHP is a better language to work with (for me) because it is so much simpler!
We reuse a web-language to do non-web stuff because nobody wants to learn a whole new language and maintain a different codebase for non-web stuff like apps.
While the no-node way is easier, it's not very flexible. You can't have multiple file components, or stuff like that. If you need those, in the end you will have to compile it.
He is talking about Javascript frameworks that work on user interface not desktop or mobile apps
Maybe the best for me would be single-file component based (like Vue.js) framework with asynchronous rendering (like Crank.js), full build-time rendering (SSR) with partial hydration (like Elder.js) and support to seamlessly integrate with server (like Inertia.js).
Web developers are far too many, and with conflicting (strong) opinions. What would come close to ideal? Nothing.
For the kind of applications I deal with
vueandriot.jsseem to be a great fit. I also like redom, with some wrapper functions it can be cool to work with.I have recently been exploring flutter/dart
It's not html, it's not css, it's not javascript, but it makes for beautiful pages.
What I find most appealing is write once compile to web, desktop or mobile
If you want to try something different (and it is very different) have a look.
Happy Coding
There is no "ideal" framework. There are no standards, except for "experienced opinions" as I like to call them, and some "not so experienced opinions" too.
The popular ones are currently React/Vue/Angular, which all only exist because Facebook and Google have thousands of developers and both made a massive social media/marketing push to get developers to use them thereby creating interview-ready subjects around the world at a fraction of the cost, this is why they got so big so fast. Personally, they're ok, they build sites, but I know they're not perfect by any means and the devs using them are of course also only human so mistakes get made.
What bugs me is that they're presented as the "best" solution when they often aren't.
Remember, they are made by hardcore application/backend/programmers and are used to tell frontend web developers how websites should be made.
How many deep programmers or backenders do you know who understand jack about CSS/HTML/SEO. They can write some sure, but they don't know how to make beautiful and fast interfaces without overcomplicating the crap out of it.
The majority of websites are 5-10 page small business brochures. They don't need a framework/platform that can process a million requests a minute. Wordpress does this fine on decent hosts, even wix or any no-code platform can handle that.
For ecommerce applications WP with WooCommerce does fine, so does Shopify and a myriad of other ecomm platforms, though none of them seem to be perfect leaving clients always wanting customizations. Integrations with ERPs are the worst because those platforms are all ancient and overly complicated.
For larger applications, enterprise level tools, even then these frameworks are not always the right choice, especially if they are used on an internal application where the data matters and not the interactions necessarily. They're not the worst thing for the job, but it's again case by case.
At the same time, we have an army of devs now who know one framework very well, so they can apply them to the jobs at hand. The most experienced devs I know mostly prefer a custom system because custom means flexibility that no matter how flexible a framework is, it cannot compete with in the long run.
I made my own js "frame/lib" code thing. It's just one script for making websites, just to prove it can be done without an npm install and be cross-browser and device friendly [screw internet explorer though]. It's called Taino JS if you want to take a look. If you know Javascript you can use it. At 3kb compressed i'd challenge anyone to find something smaller and faster [though it's also not perfect by any means]