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.)
Latest comments (70)
Great post Brian. I have been coding web applications since 1996 and have used everything under the sun including the new "fat" client side javascript frameworks and couldn't agree more. There is a web page component framework actually readily available to everyone that is easy to learn. It's called HTML, ha ha. Use cases like Facebook using React are extreme examples. Most businesses don't need a web page with 20 different interactive panels on it that are all asychronously and independently talking to multiple services. 90% of business interactive website needs can be met with a simple form with 5 fields and a submit button. Want to search up available flights on your favorite airline? That web page requires only a couple fields plus a submit button for example. I could write the UI part of almost any major airlines booking site in a matter of weeks all by myself using 10 jsp or php pages and a java backend which would be way way easier than creating a complicated component tree in React, and dealing with a massive NodeJS dependency hierarchy. The one big drawback of full page rendering though is the loss of state between pages on the client side. There are ways to have the best of both worlds and that is why I wrote my own framework. You can find it at WebRocketX. Happy coding.
I'd take it a step further and say you don't need react. you can just use vanilla js. webcomponents are pretty dank, that shadow dom renders fast, and all the css stays with the component. you could legit make a component framework and eliminate wrapper code. express is terrible. i personally use koa, but i'm finding that plain node.js works great out of the box too.
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
renderdoes.Stop harassing me. You are welcome to your opinion. Please voice it elsewhere.
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.
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)
"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.
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
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"
Some comments may only be visible to logged-in visitors. Sign in to view all comments.