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.
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.)
Oldest comments (70)
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.
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 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
WebWorkerandCacheAPI. 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.
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.
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.
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.
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.
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.
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.