You Probably Don't Need A Front End Framework

steelvoltage profile image Brian Barbour Updated on ・4 min read

Let me preface this with saying one important thing.

You should learn a popular Front End Libraries/Frameworks if you want to do Front End development professionally. Build things with them. Understand component based architecture. Practice, practice, practice! Build examples and plenty of little apps to showcase on your portfolio.

When you're starting on a serious personal project, use what you learned about frameworks to think about whether or not you need one. It may seem like it, at first. But, they are a bit like using a fire hose to water your plants.

fire hose

I recently started my own personal project, building a mini forum/message board app. (I've always loved message boards and wanted to make my own for years, so it been fun to me to make one, plus the learning experience doesn't hurt.) At first I tried to figure out a way to jam Next.js into my project for the view portion.

I really like the framework after playing around with it. It's sleek and does Server Side Rendering of React with little effort or boilerplate.

My initial goal was weave in authentication and hook my own database up to it. Good thing Zeit has plenty of examples to show you how. Through said examples I determined that I would have to create a separate Express server that runs along side Next or make endpoints with Next's new API routes.

No big deal, right?

Well, that's a lot of engineering for something simple and experimental like my little message board. In the end, I decided to reflect on my project deeper and determine what the minimum viable product would look like. Worse case scenario, I could bring Next in later if I really needed what it offered.

The lightbulb went off.

I realized that Express.js, a server-side Framework, already has the tools. HTML, CSS, and plain client-side Javascript too have more than enough power to take care of any client-side needs that would arise.

You see even with all the tools in my belt at my disposal, I still kept trying to pick up a tool that I didn't need to solve a problem I didn't have.

After that epiphany, I begun to use app.render in Express.js and brought in Handlebars for templating out my pages. Not only did it simplify my app and get me moving, it also helped me appreciate the raw power in server rendering pages.

It baffles me that a lot of the learning materials I relied on shoved me so hard in the direction of Single Page Apps, rather than something tried and true, and better yet--simple.

I regret that I didn't appreciate server rendering or use it earlier along my path. There is so much power in simply handling all your logic on the server and then spitting out a page. Plus, if I need some interactivity on the front-end--I can just link to a script on my page and manipulate the DOM with plain Javascript.

The downside is that you get a white screen between pages while the server loads the next route. If you can consider that a downside. I'm not so sure it is one, as that's kind of an expected behavior for websites and browsers.

Changing trajectory with this project also got me thinking about some of my previous ones. Many of those could have been done with simple static pages. Half of them didn't even need a Node.js server. I'm glad I used React, Gatsby, so on and so forth, but I never actually had any justification for them.

We can do a lot with the base fundamental tools that we have. Client-side Frameworks exist to abstract the harder parts of working with the DOM away. I think the main reason being as an app grows, so does its complexity. It gets frustrating to handle all the interactions, coding event listeners and such out by hand.

But, I don't know if my message board app will ever reach that point.

I've decided for personal projects at least, to let them grow towards needing a framework, rather than imposing one upon them at the beginning. I can easily convert Express endpoints ones that return JSON and then build views that use something more than templating. I think that's the biggest take away here. You probably don't need a Front End framework, especially while your app is still simple.

What do you guys think?

Also, if you haven't done it yet--fire up a Express.js server and practice server rendering your pages/views. I am sure you'll see what I mean, if you remain unconvinced. There are plenty of tutorials out there on how to do it. This one by Brad Traversy is one of my favorites. It uses EJS instead of Handlebars (they do basically the same thing with different syntax.)

Posted on by:


markdown guide

I understand the point of this article and agree, you should not simply choose a FE framework just because everybody else is.

However, I think you glossed over the fact that by replacing frontend frameworks with SSR you lose static hosting, preloading, perceived site speed to the end user, and many other possibilities.

Don't get me wrong, SSR is still great and has plenty of great use cases.

What you end up building seems like an SSR framework, like Ember, but without great developer tools, documentation, and community support that a framework provides.

I think frameworks can be overused or used for the wrong purposes, but it is always a great idea to use tried-and-true frameworks so you are not rebuilding the wheel.


Maybe the generic term rebuilding the wheel needs an antithesis. Like just because you want to build a car, you don't need to import an entire Tire Store. While it is unpopular to say "manipulate the dom" directly, its perfectly fine, and people do it and yes, almost all frameworks bring extra code to your project that you frankly do not need, nor ever use. There just aren't enough native pure Javascript programmers out there. And rendering Server side has been around so long, its a perfectly fine and secure paradigm to deliver a blog or message board. Of course you can use "Ajaxy" style lazy loading to bring in content as you need it without a page-rerender. Its cool you brought up Ember, I need to check that out in greater detail. Cheers!


I like the metaphor with building cars, but the beauty of JS and these frameworks is that in most cases, when configured properly, you are tree-shaking dependencies and truly only shipping the runtime (which in most cases is smaller than a single hero image) and your code.

So, instead of importing the entire Tire Store, you should be importing the 4 exact tires you need, and get back to building the car.

I can see where you are coming from, but tree shaking isn't a silver bullet as not everything is easily shakable. And any given dependency can tie unnecessary code in. Also, I'm very weary of setups that require a significant amount of knowledge to get good results. One benefit of SSR is that the simple thing also has relatively good performance.

SSR has relatively good performance, until you actually have high traffic to your site.

Static sites using CSR hosted on CDNs will heavily outperform at scale. Each client is performing the heavy lifting, instead of a singular server you must pay to increase resources.

I would also argue that any tool will be more performant the more adequately you understand and utilize it to the best of its ability.

Most websites won't ever see the scale you are referring to. And many parts of SSR can be cdn hosted as well. Not to mention that in many applications, the companies behind it have been SSR the client side framework to get a faster first paint, you now have both downsides. I will say that PWA can get around this by locally caching the CSR. What I'm getting at is that the simple projects, and the new programmers don't get addressed in a lot of these discussions. If you trivially set up one of these CSR apps, you're in for a long uphill battle for performance. Not to mention that extra work has a real cost associated with it in terms of development time and investment.

You clearly just do not want to use CSR SPAs, and that is okay.

However, you cannot argue that SSR is easier. As a FED, Isomorphic applications are simply easier to build. React, Vue, Gatsby, Nuxt, and Gridsome all have great CLIs that make scaffolding, extending, and optimization insanely simple.

When you use these tools, you are delivering a better end product to the user that is cheaper, more performant, and more secure.

I'm sure if you gave some of these tools a chance, and really dove deeply in, you would see the benefits for yourself.

The keyword in your argument is "Application". The niche of sites that really embody that definition is small. If you are dealing with a really demanding use case requiring a large number of changes to the page over the course of a single usage, and you have to keep track of your state while doing so, CSR is a viable option. My point is that the number of sites that actually need that is a minority.

And as a FED you might find FE apps easier to build, but not everyone is a FED. Some have to build both ends, and when that is the case, being able to simply template some html server side and send it down the wire is much easier than spending hours just configuring and tweaking your bundles, tree shaking settings, code splitting, SSR the inital view, etc. Not to mention that you then have to build the server side API for your application alongside the FE. If you are on a large team and need to be able to silo development between different groups of developers, then CSR apps can give you that extra decoupling distance. But that again is the minority.

I really think you're in the minority for all of these opinions, but I do respect your opinion. Thank you for your time and input toward the discussion. Hopefully I haven't turned you away from CSR SPAs.

"So, instead of importing the entire Tire Store, you should be importing the 4 exact tires you need, and get back to building the car." -sounds like using Python ;)

Andrew makes valid points. Matt, he is in the minority because the majority of web devs are not doing backend work.
I'm full stack lamp, i've built SSRs with caching that load as fast and score better on pagespeed insights and other tools than some SPAs.
It's rarely the tools we use, but the skill of the developer using those tools that really matters. Side note: i've also used angular, react, and vue, though not as much as i'd like yet, so don't judge me just on the lamp statement.

You can build SPAs and CSRs, but if you're screwing em up, an SSR site can outperform it just as easily as SPAs and CSRs can outperform SSRs when those are setup wrong.

People like coding things with the things they know how to use.

How many of us actually stop to go and learn the other side of it to truly have an understanding of how they all work? Very few of us even work in environments where we have to try them all out. Agency work puts me in a lot of projects where i have to learn other ways of doing things, most people work on one platform, using one tech stack, for years and then want to claim that stack is the better way of doing things.

I like to think I've seen enough to say the tools hardly matter if the developer knows how to use them.


Its the Trying and the truing that's the problem. Thats where all the casualties, sleepless nights and unnamed soldiers lay. Let's be honest...People use React because Facebook made it. That mess dont even load half the time. But....that blue F tho...must be good...smh. i teach hundreds of devs and 90% of their problems are with frameworks not even the app they want to make which can usually be done in the time they spend learning what render does.


"However, I think you glossed over the fact that by replacing frontend frameworks with SSR you lose static hosting, preloading, perceived site speed to the end user, and many other possibilities."

You are missing the point here. Preloading and perceived site speeds are issues you must solve when using a FE framework because they are so heavy in size and cpu consumption, but you get them for free by not using a FE framework. Static hosting is also irrelevant, he is making a forum. Remember, the users of your FE framework app needs to download the whole framework and your app before it is usable. FE frameworks exist for creating complicated UIs that load lots of its state async. (Ie: facebook) Removing logic from the front-end and moving it to the server is way more efficient for a browser. As an added bonus it requires less code and removes the need to adapt for things like "perceived site speed" - you only get speed. The author is totally on point with this article.


Right. The point I tried to drive home is it depends entirely on the scope of your project.

For my own, if I ever get to the point where I'm rebuilding the wheel, it wouldn't be too hard to bring in the framework and migrate stuff over. The server logic/backend stuff is all there already.


Matt, Ember isn't an SSR. There is FastBoot, which provides SSR similar to some React solutions, but it's not the default stack.

As others have said, with proper caching you can serve up SSR apps that run just as quickly as SPAs. In fact, if you're rendering the same content multiple times, you're probably doing it wrong. Those apps have the advantage of offering the developers a 1:1 relationship between their markup and what is rendered, with none of the abstractions upon abstractions that CSR folks accept without question.

My personal position is that this cannot be an intellectually honest debate without considering the role of Turbolinks and libraries like it. Rails or Express + Turbolinks are simpler to build and load faster than an SPA because there's no client compilation.

There are reasons to use client libraries like React, but they are actually the exception. Rails + Stimulus + Turbolinks for the win.


What is SSR? I just googled it and it said it was that concept where you can write any program with basic loops and if statements.


SSR - Server Side Rendering
CSR - Client Side Rendering

Thank you, saved me a web search.


To throw my two cents into here. I think that many projects that use one of the FE javascript frameworks are putting a lot of work on themselves that is not necessary. Specifically, the fact that "Everything is a component" adds some incidental complexity since you then build the component to deal with cases your app will never experience, not to mention that you build an entire component for an item that never changes across your app (some navbars) for example. You're maintaining bindings for data that may never change. And I know that you can bake components that you don't need to change, but that is the default and free on SSR. Very few applications actually change enough things for the equation to balance. The only thing that is tipping the scale are SPA which i believe are actually just proposing a problem to require the FE solution.


There is no need to build a component navbar if you do not want to. Most FE JS frameworks mount to a specific ID on a static index.html file. If you really wanted a global navbar, you could just write the vanilla JS/HTML/CSS on that page.


The navbar is an example, their are plenty of times that you would stamp a template and then never change the data associated with it, at most later removing it from the DOM. In these instances, the data binding has extra memory consumption and parsing cost that are not warrented.

It's basically irrelevant, and you don't need to do data binding if you don't use it. You can create React elements instead of React components for example. And handling DOM manipulation directly is more expensive than letting the virtual DOM handle it, since it's guaranteed to do less work, with less mental overhead overall. Sure, if you don't like a FE library it's going to be a pain, but if you know it, it's easy af.

You should check out Sapper/Svelte if you hate the VDOM so much. It compiles down to raw JS and has no runtime, and ships with a Next-style SSR first then CSR workflow.

Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

I guess the question I'd ask is wtf you need to "compile down" anything. Seriously: why do people make things more complicated than they need to be?

In another thread, you suggested that a commenter had a "minority opinion" on the subject. This is literally the same as saying that you're right because lots of people you know agree with you. Including your mom and your dog.

Probably because that "compilation" is what allows developers to:

  • code the features in due time, without rewriting the wheel for every single feature
  • deliver the "semi native" experience most people expect from the web these days, including the clients who will bitch and moan and will not settle
  • get everyone on the same playing field, everyone has already worked on Laravel/React/Angular/Vue/whatever and can get to work without having to spend a week to retrain for each and single project
  • automate the stuff that usually is menial and annoying, like complex DOM manipulation, and use the latest vanilla JS available
  • "hyperoptimize" with stuff like Prepack, WASM, ASM.JS, minification, uglification, and all sorts of wizardry.

People think that developer experience and user experience are like alpha/omega, but that couldn't be further from truth. Having a tool like Webpack that can deliver multiple bundles for each browser "era", do progressive enhancement without fatigue and sometimes just do something "awesome" can make a project better even if only because the developers are motivated and having fun.

Webpack and Babel can absolutely work their magic regardless of whether you're using HTML or a template language that compiles to HTML. A big part of my frustration is that you're conflating (or confusing) the two and it lowers the bar for the conversation.

There's absolutely nothing inherent to a compiled template that allows you to code faster, deliver "semi native" or get everyone using familiar tools. It's a false dichotomy.

Seriously: generate HTML, cache it, deliver it. Make use of Turbolinks and consider Stimulus for your structure needs.

And if you are going to advocate using a compiled template methodology, be responsible and paint a picture of the complexity you take on to support this approach.

If you haven't compared the user experience and development speed of a combination like Rails + caching + Turbolinks + Stimulus to literally any front-end system, you might be alarmed to find out that you're just wrong about both dimensions.

...dude, it's your thing. I have my own stack that has the same advantages, it just doesn't use your libraries.

There's absolutely nothing inherent to a compiled template that allows you to code faster, deliver "semi native" or get everyone using familiar tools. It's a false dichotomy.

That's because it's not your stack.

If you haven't compared the user experience and development speed of a combination like Rails + caching + Turbolinks + Stimulus to literally any front-end system, you might be alarmed to find out that you're just wrong about both dimensions.


You literally can't do the stuff we do in our apps by using server side rendering only. Stating that your stack does it isn't gonna cut it too. Stimulus literally does the same thing that made me move away from Next.JS and only do React on Express: redraw the entire view on the client browser.

Seriously: generate HTML, cache it, deliver it. Make use of Turbolinks and consider Stimulus for your structure needs.

Why would I have to write my view in another language entirely with Rails. I do React. It renders on Express. Express caches accordingly. Delivers. It arrives on the browser and goes on client side from there.

You might be blinded by all this talk about CRAs. It's more like isomorphic apps really - it's SSR if you disable JS client side, or it's both. We use JavaScript on our end-to-end stack, or include it on Laravel, where it's still ages faster and mentally 10 times less complex than doing DOM manipolations. Bootstrapping it takes about 2 to 3 hours where I also include the CRUD part, which is more about setting up the APIs more than anything. It's no stress, it's a proven and well understood stack that worked for me for years now. I don't even do any actual complex code anymore probably, since most of the complex stuff is abstracted away by composition.

Stimulus doesn't redraw the entire view. In fact, it doesn't draw. That's not what it's for. Check it out, you might actually learn something.

Give us some examples of things that you can do with React on Express that can't be done without a compiled template and a virtual DOM.

Keep in mind that I can drop in Stimulus-Reflex and have the same websockets-driven update loop that you get in something like Phoenix LiveView.

Oh yeah, it's Turbolinks that redraws. Yawn.

Ok, unfair there, it actually does stuff. But why are you using a number of libraries there? Most of my stuff only uses Express, React and React-Router, and that's all. React-Router is very much just about composing a number of React components. I might include a CSS library at best, but then we're going into the territory of the designers.

I have an example for you I'm currently studying.


Can you do this with Turbolinks?

Do you even lift, bro?

Looking forward to that big list.

Dude, I just read the intro to Stimulus (stimulusjs.org/handbook/origin). Way to make me feel like a young piooner! I'm definitely ignorant of "majestic monoliths". 😝

I'm having a good laugh here because it's written like the people here is a bunch of old developers complaining about the modernity being so modern and so much inside JavaScript.

A throwback to when a single programmer could make rapacious progress without getting stuck in layers of indirection or distributed systems. A time before everyone thought the holy grail was to confine their server-side application to producing JSON for a JavaScript-based client application.

A time when I would gladly kill myself if I could not see one more line of friggin' jQuery again!

So many layers nowadays!

But Turbolinks alone is only half the story. The coarsely grained one. Below the grade of a full page change lies all the fine-grained fidelity within a single page. The behavior that shows and hides elements, copies content to a clipboard, adds a new todo to a list, and all the other interactions we associate with a modern web application.

Prior to Stimulus, Basecamp used a smattering of different styles and patterns to apply these sprinkles. Some code was just a pinch of jQuery, some code was a similarly sized pinch of vanilla JavaScript, and some again was larger object-oriented subsystems. They all usually worked off explicit event handling hanging off a data-behavior attribute.

Yeah, you guys ever heard of "application states"? Like you know, only handle how to display your data and let it do its thing adding in just a touch of CSS animations? 😅

While it was easy to add new code like this, it wasn’t a comprehensive solution, and we had too many in-house styles and patterns coexisting. That made it hard to reuse code, and it made it hard for new developers to learn a consistent approach.

Oh the good old days when we had multiple templates with the same functionalities copy pasted from page to page because composition wasn't a thing, you had handle every touch point, cross the fingers that third party libraries didn't conflict by polluting and altering prototypes, state and input were handled in an entirely different context than the actual view and you couldn't expect a view to be deterministic. 😀

<div data-controller="clipboard">
  PIN: <input data-target="clipboard.source" type="text" value="1234" readonly>
  <button data-action="clipboard#copy">Copy to Clipboard</button>

You can read that and have a pretty good idea of what’s going on. Even without knowing anything about Stimulus or looking at the controller code itself. It’s almost like pseudocode. That’s very different from reading a slice of HTML that has an external JavaScript file apply event handlers to it. It also maintains the separation of concerns that has been lost in many contemporary JavaScript frameworks.

I don't really know what the heck is going to do actually. You put the handlers in an entirely different place and folders and pollute your HTML instead of actually writing a coherent, all in one thing! :P

Stimulus is concerned with manipulating this existing HTML document. Sometimes that means adding a CSS class that hides an element or animates it or highlights it. Sometimes it means rearranging elements in groupings. Sometimes it means manipulating the content of an element, like when we transform UTC times that can be cached into local times that can be displayed.

But why? I write my application states and it handles it on its own, right after I wrote my views - which are states! It's free real estate!

[barey explain modern JavaScript ???]

Stimulus also differs on the question of state. Most frameworks have ways of maintaining state within JavaScript objects, and then render HTML based on that state. Stimulus is the exact opposite. State is stored in the HTML, so that controllers can be discarded between page changes, but still reinitialize as they were when the cached HTML appears again.

Oh yeah, I can feel the headache of how to preserve client state on a server! So very much like the good old days! I'm also going to keep all my state on the HTML so you know it's the real deal when it gets out of sync and the state goes out the window. 😅

It really is a remarkably different paradigm. One that I’m sure many veteran JavaScript developers who’ve been used to work with contemporary frameworks will scoff at. And hey, scoff away. If you’re happy with the complexity and effort it takes to maintain an application within the maelstrom of, say, React + Redux, then Turbolinks + Stimulus will not appeal to you.

I haven't touched Redux since 2016. I actively ask people to stop abusing Redux to do todo apps. Why is everyone obsessed with Redux!? Local state is all you need. JSX is about as easy as HTML. All you have to do is write camelCase instead of kebab-case. 😅

In fact, it feels like the same kind of secret sauce we had at Basecamp when we developed Ruby on Rails. The sense that contemporary mainstream approaches are needlessly convoluted, and that we can do more, faster, with far less.

I sure wish they used Ruby on Rails for Gitlab, it's so slow! ...Oh wait they did! Maybe it's not the damn stack the issue you know? 😝

Furthermore, you don’t even have to choose. Stimulus and Turbolinks work great in conjunction with other, heavier approaches. If 80% of your application does not warrant the big rig, consider using our two-pack punch for that. Then roll out the heavy machinery for the part of your application that can really benefit from it.

At Basecamp, we have and do use several heavier-duty approaches when the occasion calls for it. Our calendars tend to use client-side rendering. Our text editor is Trix, a fully formed text processor that wouldn’t make sense as a set of Stimulus controllers.

So you need the heavier-duty approaches there. That's no alternative to it. Even for "simple" stuff like calendars which usually have a little bit of state to handle the current position in time and the events.

Above all, it’s a toolkit for small teams who want to compete on fidelity and reach with much larger teams using more laborious, mainstream approaches.

Nope. Most of my scaffolding takes an afternoon or two by myself, and I'm set. And that's because I haven't yet made an internal scaffolding project. After that I'm just composing the views with our private library of modules, writing new ones, integrating the HTML from the designers and their transitions and/or helping with the APIs which are still made the old grandpas' ways of MVC; I did mine with Node back when I was by myself, now I have colleagues that do backend PHP and optimize the data architeture better than I can ask from myself.

Sure if we had to write our own text processor, that would take weeks and weeks, and that's why we sometimes use already existing libraries (like recharts or draft.js). But you don't do that with SSR do you?

I have no idea of how much experience you have with modern "frameworks", but my experience with React has been quite magical for a while since I stopped going after the cool kids and just read the React docs and do the things the simple way. Most of my components do this: get the data, format it, display it, handle the interactions. I can see all they do in a single file, or maybe put a very pure pattern elsewhere for reuse. If it's a very "monolythic" app I will have a function that does web requests on the browser or fill the initialState by straight up calling the data controllers on the server. And I will cache my stuff up before serving it. I will use a single approach in my entire project, and my modules will have a coherent architecture instead of a miasma of stuff loosely composed.

First of all, jQuery is an incredibly powerful tool. Like anything else, if you use it improperly you will end up with a mess. The notion that jQuery is somehow inherently bad because it was popular before you started your coding bootcamp is not a good sign for the rest of this.

Nobody is suggesting that you shouldn't use components or that Stimulus is the right call for every scenario. Stimulus doesn't make sense for building a text editor; if you read how it is designed, it's not something you'd do with any pre-existing framework.


I don't use GitLab, but GitHub is written in Rails as well. The funny thing is that Rails sucks so bad, projects like Laravel essentially exist to port over all of the features they came up with.

The thing I have to keep reminding myself is that you said it yourself - you really are literally just a young front-end developer that isn't particularly confident with back-end. You literally haven't been doing this long enough to have accrued any perspective on how maybe the thing that was super cool when you graduated and formed the default basis for everything you've worked on might not actually be more than a fad religion that people got excited about, like Scientology.

MVC and its many sub-variants are dominant outside of your bubble and not going anywhere. I've been working with React and React Native since January and every day I keep waiting for the lightbulb to come on that shines a light on why people are so keen on masochism. If you look at the HN thread for Rails 6, it's chalk-full of people talking about how nice it is to work with Rails after working with React. If you want to pretend like you've got it all figured out and the issue is closed, then I wish you the best of luck.


For what it's worth, and I am keeping track, the things that you've listed as what you can do with a CSR that are impossible with a SSR are:


I don't really want to discuss with you anymore. You've been provoking for far too long now, stating that your stack is the one true way to do things. Even the Stimulus intro stated that they won't use it for all things, and you go on blabbling on how superior it is, you don't understand that React is just the V in the MVC, and you don't really have experience with it.

PS. Hacker News is Toxic Town and I won't even give them my pageview.

I'm not trying to provoke you. I'm calling your bluff because I know that you're wrong. I know that you're wrong because I've actually used every generation of tools since the public web started. After a while, you see patterns. The question of where logic should live is cyclical.

I admit that six months of React doesn't make me an expert, but I have experienced enough pain to be able to directly compare it to all of the different options available.

Anyhow, let us know when you've started on that list of things that only React can do.

I never assumed that only React does X. Stimulus authors however stated in plain English that you will need something more than SSR to do stuff. Not Turbolinks, not Stimulus, not Rails. Something else.

They pointed out one example: text editors.

And I pointed out another: transitions with global states and shared elements (where one view hands off elements to another).

You also ignored every single other point I made at the beginning. But I won't reprise them because it's pointless. You're full of yourself.

Dude - I never suggested that you don't need client-side code. That's not even a thing.

If that's what set you off, then I'm sorry for not being clear that we actually used to build real stuff before front-end frameworks were popular again. (Yes, before jQuery there was a first-wave of libraries competing for the same trophy. I'll bet that you've never had to suffer YUI, MooTools or Dojo, or remember when Google released their own library... Closure.)

Sharing elements is not really a serious feature now, is it? If you are committed to doing all of your state transformation on the client, you have to be able to move objects from one place to another. On the server, we just call functions and pass data structures around. We don't need to pass functions into props eight levels deep because we don't need to have an adversarial relationship between the different parts of our data model. It's that endless shuffling of concerns up to the parent that feels so wrong to me.

A really good analogy would be calling a meeting exclusively to schedule more meetings. There's an inherent design inefficiency that gets worse with complexity. Meanwhile, I can pass a collection into a partial and never spend a second of my day fretting about how some React component I pulled from npm is going to do a shit job of abstracting the browser's native functionality.

One thing Rails really gets right is that things are consistent and repeatable. We call it the principle of least surprise. It's what the client world is sorely missing.

Anyhow: I have 26 years of experience. That's perspective, wisdom or a demonic pact. I'm not claiming to be humble. My opinion is highly qualified.

Dude - I never suggested that you don't need client-side code. That's not even a thing.

See, that's the thing. We both create our views on both server and clients.

If that's what set you off, then I'm sorry for not being clear that we actually used to build real stuff before front-end frameworks were popular again. (Yes, before jQuery there was a first-wave of libraries competing for the same trophy. I'll bet that you've never had to suffer YUI, MooTools or Dojo, or remember when Google released their own library... Closure.)

And it was awful. Since your routes and your views weren't actually data driven but only rendered with the stuff already in, and you just waited for HTML to mount and Js to load to replace divs or attach handlers, views never actually came together with intents being in the same place. More often than not, libraries used different ways to mount their components. jQuery did solve the thing somehow, because it was popular enough that people just bothered to make jQuery plugins, but you relied on their code to do the things - often an obfuscated code that you couldn't control, remember Revolution Slider? - and carefully made sure that they didn't conflict with each other. No clear and clean way to have your data passed down to each component, unless you stored the data in the attributes - polluting the HTML.

Sharing elements is not really a serious feature now, is it? If you are committed to doing all of your state transformation on the client, you have to be able to move objects from one place to another. On the server, we just call functions and pass data structures around. We don't need to pass functions into props eight levels deep because we don't need to have an adversarial relationship between the different parts of our data model. It's that endless shuffling of concerns up to the parent that feels so wrong to me.

We don't. We at best go 3 levels deep probably. (Here's a very generic example.)

  • We have a router. It declares our routes in a React way, by composing React components (react-router-dom). This defines how our users discovers the resources on our webapp by navigating the URLs. Being at the top, the children can access the history, the current location and how to navigate.
  • We have our route. It contains our actual architecture, and will use our location to decide what to get from our data model. It calls one or more functions, which are handled differently according to our context (browser or Node): either call the controllers, or call the APIs which map 1:1 with the controllers. It then displays our route, which is basically a number of "dumb" components displaying informations, or that listen to user inputs and change the local state of our route.
  • Our components. These display the props, have small states to handle filtering or sorting of data, or control the inputs to be clean and in the corrent format we need.

This might look like this in a monolythic app:

- index.js // loads up Express to do the rendering and serve the app
- data/ // where the ORM or the queries reside
- controllers // our controllers to load the data
- components/ // shared by all places
- routes/
-- index.js // defines our general routing strategy
-- route X/
--- index.js // defines the architecture of the route
--- components/ // only for this route

We don't pass stuff down 8 levels. We do pass event listeners to complex component (1 level deep), then from there on it's irrelevant to our route what our component does. It's a black box you can rely on and you don't need to think about other than for cascading styles.

A really good analogy would be calling a meeting exclusively to schedule more meetings. There's an inherent design inefficiency that gets worse with complexity. Meanwhile, I can pass a collection into a partial and never spend a second of my day fretting about how some React component I pulled from npm is going to do a shit job of abstracting the browser's native functionality.

I think about it even less than you do, because I don't have to wrap browser functionalities and don't manipulate directly the HTML, either to get data or replace it. I just call the browser APIs from the service workers or my script, or emit events as needed. The only API I don't talk to directly is usually the History, since react-router-dom is an historic (lol) library that is very reliable and written from better developers than myself. I do have a general knowledge of how it works internally anyway.

One thing Rails really gets right is that things are consistent and repeatable. We call it the principle of least surprise. It's what the client world is sorely missing.

That's the ultimate point of React. You can expect a component to always reproduce the same HTML given the same props. The authors of React took all they could from functional programming and the concept of purity.

Anyhow: I have 26 years of experience. That's perspective, wisdom or a demonic pact. I'm not claiming to be humble. My opinion is highly qualified.

If all you do is the same stack over and over for years, does it really matter? When I started, I did use Ember for a while, then Meteor (with jQuery lol), then AngularJS, all while using WordPress as the "boring reliable framework". 2016 I went all in on React but still sided it with other stuff.

Wow I have got the notification to read this to give feedback but this is something really out of the park, thanks!

Dear fellow dudes. Why don't we be nice to each other?

Federico you are talking about rendering HTML, routing, handling state and al sorts of stuff you typically do in a SPA. Single page applications are really cool you frontend guys are writing awesome code. I also like to play around with functional programming and I love frontend development.

The thing is sometimes we backend developers need to maintain monolithic applications that is not a SPA or we do not need a SPA for your use case. If you build a SPA you might also need a backend that means you need to build 2 applications you don't always want that. We render HTML from our server side app and we need some bits and pieces of javascript to enrich the user experience because the standard HTML elements are just not enough. Reactjs or whatever javascript component framework might be overkill for what you try to achieve. Stimulusjs is meant for this kind of situations not for replacing Reactjs of whatever frontend framework. Stimulusjs is super simple you can read the reference in 10 minutes and you get it. I don't agree on all the choices they made but I could use it om my terms very easily.

So to summerize Stimulusjs is not meant to replace Reactjs or whatever frontend framework or to build a SPA. It is just meant to enrich some bits and pieces of HTML easily in mainly backend applications.

PS Stimulusjs has nothing to do with jQuery btw you can just use vanillajs.

In my 20+ years I've seen all kinds of frameworks, libraries, front-end, backend, etc, etc. I remember when you couldn't find a JS developer because everyone was a jQuery developer. I remember when NoSQL was going to save us all from relational databases. I remember when OOP took over functional programming and now we're back to functional programming like its brand new.

Stimulus will be like Ember. Something that almost nobody has heard of. If you build the client facing portion of your application you WILL need other things that will ultimately negate any reason you chose it in the first place. And worst, you won't find a developer with any knowledge. State management is also poorly thought out. It seems like something a backend developer with no real frontend knowledge would come up with. I like trying every new framework when they come out to see if they're useful but this one is a dud.

As far as React vs Ruby, I've found that developers tend to think whatever language or framework they first used is the perfect tool for every project. Which is why there are so many bad applications out there. React is a tool. Ruby is a tool. Angular and jQuery are tools. Expert developers have many many tools in their toolbox and choose the right one for the job. Btw... 80% of enterprise applications are built with Angular over React and nobody builds with Ruby anymore.

Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

Okay, boomer!

First of all, your comment can be broken down like so:

Paragraph 1: I've sure seen some things
Paragraph 2: "nobody" does the thing I don't like
Paragraph 3: "nobody" does the thing I don't like

You, sir, are being an armchair quarterback.

You mentioned that you like trying every new framework. It doesn't sound like you actually tried Stimulus, which doesn't profess to have state management. It was created by the same folks as both Ruby on Rails and the original Prototype JS library that inspired jQuery... people who have forgotten more about JS than you know.

Stimulus is outrageously well designed, and absolutely nails a series of sweet spots - especially when paired with Turbolinks. If React or Angular are doing it for you, then you almost certainly don't need or want Stimulus and that is fine.

If people don't want to build with Ruby that's their problem - leave the massive productivity arbitrage to us, that's fine. If you choose to follow a herd because of head count, that makes you a certain kind decision maker and nothing more. You will seek out details that confirm your confirmation bias.

Firstly, It sounds like you've never actually been in a position to choose the tech stack. The reality is, it doesn't matter how much you like something. You need a team. And you need people down the road when your team is gone. And that means choosing something that not only solves your problems but something popular enough that you can find someone that knows it. It also means choosing something that has a lot of support so it's around for a long time. There are a lot of team leads out there wishing their app was built in Angular or React instead of Ember as example. I love development in Vue. It's fun. I'd never choose it for an enterprise project though.

Secondly, you don't know my experience level with anything. For all you know I'm an expert and author in JS. I've met plenty of developers like you over the years when filling teams. You think because of all those years they'd be experts but in reality they know one way to do things because that's how they did it for years and years. They can't do it any other way and as far as they're concerned, their way is the only way.

Thirdly, you are a very close minded, immature, and insecure person. I originally simply stated the facts but you immediately took it personal. I insulted your personal beliefs apparently but I'm not going to apologize because you have thin skin and are unable to discuss openly and honestly. You will no doubt have more insults for me personally because that's your nature. So I leave you hear to argue angrily and close-mindedly with every other developer who disagrees with you.

Open and honest conversation is the only way to improve anything or to learn anything new. Good lucky buddy.

Stop harassing me. You are welcome to your opinion. Please voice it elsewhere.


I 100% agree with the author. In fact, it is what I started with a year ago when I needed to develop a simple dashboard. And guess what? - I ended up with building my own small ssr/isomorphic stack... I could just use Next.JS or something similar. However, now I don't regret this decision, because when you building your own tools you know what approach would make you more productive. As a result my productivity increased at least by half after I built my own tools.

I suggest to add Turbolinks, it improves routing in SSR applications. For SPA-like experience there is WebWorker and CacheAPI. with them, it is possible to provide SPA user experience in SSR applications.


I really need to dive into WebWorkers tbh. Thanks for the tip.


A point that many does not take into account: old devices. I live in a 3rd world country where internet is a luxury (so is decent mobile devices). I made an HTML app with Ionic and most of my users could not use it (I have 1.4 million downloads, so, "most of my users" is a lot of users). Reason: Android WebView in ancient versions (Lollipop come with Chrome 37). Most of those frameworks start rendering something with Chrome 55 (Ionic is using all cutting edge techs, as CSS variables, ES6, etc., so, Chrome 64-ish is the minimum).

That said, one part of my app works fine (even in oldest Android 4.4 with Android WebView): the Flarum forum. They do not use any fancy frontend frameworks and Mithril (a view framework, as React or Vue).

So: if you want to be successfull for people who are not techies (as they will not update their phones - they don't even know that option exists sometimes), or if you pretend to be a hit on BRICS or poor contries, don't use fancy front-end frameworks ;-)


What if my app uses SSR for those who can't use React (which I have yet to encounter a browser where it doesn't work)?

A CRA with SSR is "fancy", but my "fancy" allows for accessibility and noscript experience too. It's not like I forgot how the web works. React still spits out HTML at the end. I can get the bundle down to reasonable sizes (60 to 120 kilobytes) or not have a bundle other than the CSS if the userstring is too old.

[btw, I can set it up in an afternoon, it takes a couple files more than a normal React app]


You cleary misunderstood me, so no point arguing.


This is a much a needed article. Many web sites these days have become unusably slow because of the SPA JAVASCRIPT madness. You need a core i7 and 16 GB of ram to run many of the popular web site smoothly.


I mostly always tend to reach for a front-end framework and my choice is Aurelia. The things that I get in a framework are invaluable to me and save a lot of time.

You can go vanilla, but in the end you end up just creating your own framework piecemeal by installing a trove of Node packages. You install a router, something for templating and a a few other libraries. I often start off with the intent of not using a framework, but the time saving of not having to reinvent the wheel are hard to argue against.


Right. I wouldn't write my own FE framework, rather I'd just refactor what I have to use one... if my project grows to need it. For now its just overhead and complexity that it doesn't need.


If you're building simple things that don't need many packages or functionality, that's absolutely the way to go. If you're building a LOB application or something that's laden with features, it's hard to argue the case against a framework if it can save you tens and hundreds of hours in work.

I do think people lean on existing frameworks and libraries a lot, but the concern for me is they're not bothering to learn basic JavaScript fundamentals or their perspective of what native browser API's can actually do versus what frameworks allow you to is skewed.


I feel that if you’re fluent in a frontend framework there isn’t any reason to write your personal projects in vanilla code. If I was still stumbling around react and I was more comfortable with regular express and html templates, I’d use that.

At the end of the day even if it’s true it’s just a small personal project 14 people will maybe see, why worry about the bundle size?

These “you don’t need a framework” posts never resonated with me.


I wasn't saying that you should write your own front end framework, just that you should think if you really need one to do the things you want to do.


I regret that I didn't appreciate server rendering or use it earlier along my path.

Server side rendering was all we could do back in the day 😂


I'm rather new, just learned all this stuff recently. So, it was all Front End framework related.


The focus of this article is all over the board. You could write the same article about not needing a backend framework, or not needing any framework. Or I would argue nobody should be making a one user forum. If you are doing it just for fun, or to practice skills, then what you want to learn is the primary driver of your choice in framework, front end or backend, and renders the rest of your points moot.


I kind of regret the title, as this was more to share something I learned or discovered making my app--rather than to tell people what they should/shouldn't do. It was more about my thoughts/experience. That's why you got the impression that the focus is all over the place.


I think it wasn't that you discovered you may not need a framework. You discovered that you didn't need a client rendering framework. Express is actually considered a framework. It's meant to help you create web apps. And it's only a recent development in the industry that we started to send only JSON from the server and have the client parse it and render something new on the page.

I'm glad you discovered Express HTML templating. :) It's quite simpler than doing SPAs, as you've noticed. It's my go to for quick prototypes. I only do SPAs if I'm sure I'll need some rich client functionality. And even then, sometimes I can get by with just adding some JS to the rendered page that allows the user to have that page change with some AJAX calls before they move on to a different page. And for that, I can use jQuery, or just vanilla JS if I don't think I need jQuery.

If this project becomes anything more than an experiment, I can easily my Express endpoints ones that return JSON and then build a front end. I think that's my biggest take away. My oohhh I gotta share this moment.


Server side rendering is the correct approach for most web applications, it's just that the SPA hype is extremely strong last few years. But, it seems to be dying down lately.

Check out turbolinks and Stimulus, they can help you build rich client-side experiences while still keeping majority of your logic in the back-end. I have a feeling you might like them.


So true. But I used angular for building my personal app (a nice click to copy interface for the bazillion credentials I use everyday). I did it because back then I was a newbie and wanted to learn "the cool kid's technology". No regrets though, because that's what taught me everything I know about javascript, ES6+, compiling UI from source code and such stuff today and this really makes me a cool kid in my team. I remember pushing my angular source code repo to Heroku and wondered why it always displayed "Your app crashed". The first time I saw plain HTML, JS, CSS files after running "ng build" I was like "hallelujah"


"You probably don't need a FE framework" - pretty presumptuous title. In my experience I haven't met a single project that hasn't benefitted from or eventually needed a FE framework.
THere's a simple rule of software architecture that says when faced with a choice, go with the one that's easier to change. If you are absolutely sure that your project won't grow beyond the reach of SSR, by all means, it makes sense.
But otherwise, adopting a FE framework is the option easier to change because you can adopt it incrementally (with a few exceptions, frameworks are modular), you don't actually have to deal with extra code that you definitely don't need (unless you really choose poorly) and there are ways to mitigate boilerplate (where needed). Also, if you do want to ditch it down the road for some reason, you're mostly bound to copy/pasting your non-boilerplatish code to some js and integrate that as opposed to devising a strategy to replace your rendering.
Even if going framework-less, I wouldn't go with SSR since it's way too limiting. SSR made sense in ye olde days (15 years ago, maybe), when large systems would have clients running that may not be able to do much dynamic rendering involving average JS. But today a given desktop can easily exceed even above average AWS VM's and a simple phone holds more power that the low-tier cloud offerings.
You'd be hard pressed to find a compelling reason to not seek to offload FE work down to the client.
The overhead from using a framework exists, for sure but still makes more sense.


Let me summarise.

I was following fashion trend du jour. Then I realised it was just fashion and maybe I should think for myself. When I did that, I liked the results because they suited my use case better.
What's the lesson here? Hint: it has nothing to do with framework choice, csr, SSR, or anything else mentioned in this comments thread.


I've been saying this for years. What you are saying is true but it's always been an unpopular truth. It might be less true if there weren't new frameworks to learn constantly but there are. I mean if you have the foresight to pick a winner like React then you're good for a while but if you pick wrong and have to relearn and your company uses some other framework then it just adds up to a dumb amount of time learning to do the same thing you could do yourself with just regular JavaScript.

Confession time, I didn't make a serious effort to learn any JavaScript frameworks for like a four year period. Instead I learned a ton of math. Well, that turned out to be an outstanding decision. No, I still don't know balls.js but ball.js is old now and no one uses it.

I'm learning react now and it's fine. I like components a lot but those too have been possible in regular JavaScript for a while. Well, at least with some shims.

Anyways, I applaud you for writing this article. It might not be popular but what's right isn't always popular.


Hi there, great article. That's really interesting to share your views and opinions about that subject. Personally, I already tried server rendering with EJS and yes I watched Brad's tutorial too back then. He is so good at teaching stuff btw! But I prefer to do everything on the client and leverage my server for APIs for instance. Most of the things that the popular Frameworks do are already possible to do in plain JavaScript without much pain. For instance, looking at Vue.js they even said that the VueRouter package is in the end a wrapper to the Navigation API native in the browser and if you know that API, you'll know how VueRouter works internally. Too bad people often rush into Frameworks without really understanding the underlying concepts.


I find intriguing your idea of letting projects grow toward needing a framework. I have a hard time imagining myself on such a path, but I should mention that the only framework I have tried to work with so far is Rails, and in the above article framework means front-end framework.

My first rails project was "duper," which was an attempt to implement a simple double-entry bookkeeping system as a Rails app. The reason I wanted to do this is because I had taken to using GnuCash for balancing my checkbook and the like. I love the precision, and I love the data model, but I hate the user interface. As someone with 20 yrs data entry experience (but shameless plug, gitlab.com/n8chz) I know a bad user interface when I see one, especially input interface. I thought to build a Rails app around GnuCash's data model (available as your choice of an XML file or a MySQL database) but all of the Rails tutorials were walkthroughs of crud apps from scratch, including building models ex nihilo. I could find no non-paywalled hints on how to build a Rails app over an existing data model. So I created my own model, incorporating sombunall features of GnuCash, which (if I may brag) a vastly superior user interface of my own devising.

But if GnuCash is overkill for balancing my checkbook (and it is), surely Ruby on Rails is massive overkill. I'm thinking maybe instead I should have written something in whatever language (they all have a MySQL library available it seems) that simply sends raw SQL statements to the GnuCash backend, but that would be so, what, 2004?

I also think brain wiring may be a factor. You say frameworks exist to abstract away the DOM. I remember reading somewhere (but alas I forgot where) that frameworks exist to abstract away SQL. Perhaps you're both right depending on whether it's front-end or back-end frameworks. But I think in SQL. I took a community college course titled "Relational Databases" where I was taught something called "relational algebra" (the data structures rubric that is the home of Boyce-Codd normal form) and I was like that's literally how I've been organizing information mentally for my whole life. I literally think in SQL (or the conceptual equivalent). So when I heard that someone invented frameworks as a way to abstract away relational algebra so developers can instead think in a (to me) clunky language called "object oriented," well, let's say I was blown away by a sense of how truly unfathomable neurodivergence can be.


This is a really interesting point, which I read as what the article was getting at - that frameworks always bring an overhead. Sometimes it's computing-related (memory, execution time) and others it's cognitive...having to understand the framework to do anything useful. The aim is that the gains from the framework exceed the overhead. In the case of ORMs (that is Object-Relational Mapping - translating SQL into objects) theres such an assumption (wrongly, often, and touted by OOP developers who don't understand SQL) that the gains are obvious and don't need to be explored. Writing stored procedures in a database and calling them directly is perfectly fine in lots of cases! Go for it, I say.

In the case of client-side frameworks though, abstracting the DOM is the reason to use one...any one. There really isn't any such thing as the DOM; there are multiple implementations that appear similar but vary according to the browser being used. In the case of web apps, the browser is a choice of the user, not the developer, and so the developer is encumbered with having to test functionality across all of the differing implementations. Client side frameworks do this for you. Knockout.js, for instance, has support for browsers going back to IE6 - try doing that with vanilla JS.

Server side rendering also has its challenges. Take a simple tick-box filter, for instance. The click in the checkbox doesnt trigger a post back, so you have to listen for it and force it through using JS (taking into account all of the differing browser subtleties), then figure out on the server what state your UI was in (HTTP being stateless, the server has no intrinsic "memory" of what this particular user saw beforehand so only has the data posted back from the client to go on).

In the case of client-side frameworks, therefore, the overhead is miniscule in comparison to the advantages, which perhaps explains why there are a) so many of them and b) why even in the smallest projects they are worthwhile.


In fairness to Rails, it is not intended to be used to build over existing data models. You can absolutely coax ActiveRecord to store PKs using non-standard conventions, but if you want to benefit from the ecosystem, you aren't likely to have much luck if you stray from the ORM patterns.

This is 100% by design. Rails is an abstraction from Basecamp. The creator of Rails has frequently stated that it hit critical mass the moment they used it to launch their own product. If anyone else finds it useful, this is a happy side-benefit.

For those of us who find it useful, a big part of the Rails value proposition is that we embrace the concept of convention over configuration. That is, there is a name, place and strategy for most things you want to do. You can absolutely step out of these patterns, but then you are violating what we call the principle of least surprise. The upside of this standardization of expectation is that an arbitrary Rails developer can join your project and intuitively know where everything is. They will be productive almost immediately.

By collectively deciding that bikeshedding is an over-rated time waste, we go from 'rails new' to serving authenticated pages that display data very quickly.

As a rule of thumb, if you cannot find documentation to support what you're trying to do, it's very likely that you're trying to make Rails do something against its own conventions.


You have landed on exactly the same decision I have. SPA's are only required for very complex and rich user interfaces. In reality, most web apps are not that sophisticated.

Maybe a sprinkle of Ajax here and there is as far as we need to go.

My personal project is written in Go for the backend, generating html server side like I used to before all the SPA hype took off.

And for the odd Ajax request, I'm using something called intercooler.js

Development is productive as a result


Loved this article as it's something I've been feeling for a few years now. Often times using a Front End Framework is the equivalent of using a semi truck to get a kitten across the street, when we all know a simple toss will do (That's sarcasm for all you feline lovers). I love Vue and React, and am a long time Ember dev, but they've been largely unnecessary for most of the enterprise stuff I've done over the last few years. The server is much better suited for the vast majority of it.

Good luck in the oncoming flame war you have opened yourself up to.


Someone who builds an interesting blog with just WordPress, is raking in $700,000 a month passively. Meanwhile, a developer with all the cool tech is still broke. Keep it simple when necessary period.


If only it was that profitable. The blogosphere doesn't pay anymore for plenty of people.


I'd just like to say a few things.

There is nothing wrong with using vanilla code instead of a spaghetti mess of frameworks and libraries. I'm saying this not as some old grandpa (not just because I'm a woman, but more specifically, because of my not-really-old age) that can't get with the times, but as a person who has seen the advantages of vanilla code firsthand. Also, there are other non-grandpas who back up the position of not using frameworks for every little thing. For example, dev.to/gypsydave5/why-you-shouldnt... . GypsyDave5 doesn't look all that old, either, and he's written an article here on the subject.

As for me, I created Blue Alphant ( chrome.google.com/webstore/detail/... ) using HTML, CSS, JS, and AngularJS. It wasn't too bad, as I'd broken the thing up into a ton of pages and created a complex menu to navigate it. It was a pain to update, as the database was broken up just as much as the pages, and some pages, especially CJK Extension-B loaded so slowly, it often timed out, leaving the user to select 'wait' when the page became unresponsive.

I got sick of using such a slow, complex beast, even if it was my own labor of love, so I refactored it. Now it's Azure Alphant ( sheilart.github.io/Azure-Alphant/ ), it supports more devices and browsers, the menu is much simpler now that I've been able to merge so many pages, updates will be far less of a hassle, and (this is key) it runs 76% faster. All I had to do is ditch AngularJS and build the whole thing as pure vanilla.

I had been led to believe that adding a framework like AngularJS improved speed and created more maintainable code. However, in practice, I found the opposite was true. Perhaps I should have gone with my instincts in the very beginning, back when I first questioned how adding more code to be fetched by the initial HTML would make my project run faster.

Frameworks are fine, when used in projects that NEED frameworks. Frameworks are NOT a one-size-fits-all solution for every web-based thing under the sun. No one should ever use a framework just because all the 'cool coders' are doing it; they should evaluate their own project's actual needs, just like OP did here.


it is fun because the first web proyect that i create was a 3D model viewer whit a acount management backend, and the app was a single loaded page where you create a user and you can create 3d weeding avatars as many as you wish and save them like a collection, you willb e able to purchase a 3D printed version of any avatar, i remember that the client got a hosting whit toons of addons of worpress alike overkilling tools, and they want to me to check what tools we gone to use, I really never made a web site before but all the features where covered whit native javascript code pretty basic logic, plain css and html, and some php for the backend, remeber that the topmost challenge was display dinamically a list of the avatars populating a panel, and just make a function that edits the inner html of a realtime crafted object, many of the html element just where reused in realtime just changing their values and styles with logic and state variables, the only reason because i am really learning frameworks is because currently many clients are making part of the requirements but at the end, the logic behind the code makes the magic, and while less tools you have more creative you got


I agree with what you say that you might not need a framework or library and you don't if your app and use cases are simple. That is what one of my team leads told me as well when I started out fresh as a Junior. That was the argument of all the team leads there at that startup. No for the bells and whistles of JS or Python frameworks right, right?! Guess what we ended up using those frameworks and wasted so much time writing throw away code, trying to reinvent the wheel. Don't do it at your job or your business. Frameworks are wonderful for juniors to get started and train them until they develop the curiosity and intuition to try and understand how things work. JavaScript is still a very badly structured language and there is no standard way of using it, yet. I would say only do pure JavaScript for educational purposes or if you want to become a core developer for that language or improve an existing popular framework. Don't be like these Linux purists, we don't need a another Linux distro or another JS framework. We just need one that does all the basics well enough.


Having working with Java servlets,jsp, Ruby and rails and other that serve static HTML with JS in it, when the SPA born there was a lot of benefits, as other comments mention here, specially in the speed of interaction for the user, the need of Ajax of update small portions of the page is still great, with SSR you always need to retrieve the entire resource. I agree that same foot does not fit for everybody, some times the oldest is the best, some times a mix is even better than any oldest or newest. Thanks for sharing your thoughts


I have built some sites using Next JS. You can use express on it which makes it really awesome. For me using this setup you get the best of both worlds.


That was my initial plan. But, I decided against it until I really need Next.js. I'm not doing anything crazy client-side--yet.


There is a project called inertiaJs: inertiajs.com/ which basically combines SPAs and server rendered apps


I'm going to have to check this out.


For me... using React helps me understand programming a little better.....I like jsx... I like that my components contain both the logic and the view....


You really don't need UI framework, especially with such things as EHTML(github.com/Guseyn/EHTML)