As I learned Javascript over the past year, I was focused mostly on the front end. I think that tends to be the direction that most learning materials and new developers go. That’s what Javascript is notorious for. Also, everyone wants to make badass interactive websites.
The past two months or so I’ve taken a sharp detour to study more of the back end. For me that means delving into Node.js in earnest, rather than just using it to transpile my front end and run a dev server. I also learned Apex, the back end language for Salesforce–which I’m involved with during my day job.
Ultimately, the goal is to be able to call myself fullstack. Not even just for the job title (and pay), but for my own self interest. I have dozens of project ideas, and to be able to code them all from start to finish, back to front, is a very enticing notion.
One huge thing I must admit, is that I’m loving the back end. There’s something fun and addicting about handling requests and data, formulating responses and interacting with databases. Maybe I’m just a nerd. I can’t stop thinking about all the cool things that the back end lets me dream up. In fact, I’m flooded with creativity because of it.
That’s ironic because I got this impression at first that back end development was this stuffy and non-creative place. Sure, the front end makes pretty and flashy things. The back end is where plenty of magic happens and the power of an application is generated.
There is also one other huge advantage I found on the back end.
Stability.
In searching for resources, I found blog posts and articles Node.js from early 2010’s. They are still relevant for the most part, except for minor things. For example, having to include the bodyparser module with Express. It’s built in now and you don’t have to import it separately
Compare that to the front end. If I look up articles from that era, I’m suddenly in foreign territory. I’ll find stuff about JQuery and Angular.js, or possibly early React.
The front end is an ever shifting landscape, filled with chaos and uncertainty. Mind are some advantages there, for newbies, as you can easily “catch up” your knowledge to the industry standards. And you will be having to do that continually.
I recently watched a very good video by Cris Hawkes, one of my favorite web dev Youtubers.
{% youtube iRo18pUs61Q %}
This video helped me realize why I liked Node.js so much, for its stability. I have nothing against React in particular. The video is shooting at it, because it’s the big dog. However, I feel the overall message is about framework hell in general.
The wheel keeps getting reinvented on the front end.
I don’t know what the solution is, but do have some thoughts.
As I said before, I work in Salesforce development and they built their own front-end framework based on Web Components called Lightning Web Components, and follows all of its rules. Except, it also integrates with the platform to make querying and inserting data much easier. Thus, it would kinda pointless for outsiders to use unfortunately.
Svelte is awesome, without the virtual dom, and is much smaller than React. The fact that it has to “compile” Javascript into older Javascript shows that there is fundamental problem. That problem is backwards compatibility and browser support.
I think eventually, we will probably use Web Components instead of these virtual dom frameworks.
Still… Hasn’t compatibility always been the big elephant in the room with web development? There really is no easy solution, other than the passage of time as more people adopt newer browsers. Those browsers will then introduce newer features and the cycle repeats itself. We are always on the bleeding edge as developers, and we don’t want to wait for the rest of the world to catch up to us.
So, we take shortcuts with our frameworks. At what cost?
Our own sanity more than likely.
I know personally, I am going to look into things like Polymer for future front end projects. Maybe I could get ahead of the curve, and future proof some of my own applications.