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.)
Top comments (70)
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.
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.
github.com/basecamp/trix
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.
news.ycombinator.com/item?id=20717886
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:
1.
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.
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.
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 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.
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.
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.
Do you even lift, bro?
Looking forward to that big list.
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!
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.
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 ;-)
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.
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.
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.