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] (https://media.giphy.com/media/xIOCCvqZ9kYEg/giphy.gif)
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.
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.
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.)