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.
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.
Top comments (19)
Ultimately there will never be just one way to do front-end JavaScript because everyone brings their own opinions on solving computer science problems, heavily influenced by the language(s) they use on the back-end (or that they learned in school). Java, C#, and C++ developers will always fiend for some syntactic sugar that makes them feel like they're writing object oriented code in their "preferred" language. Ruby developers like their Emberjs and/or Coffeescript. PHP laravel developers tend to love Vue. Haskell devs love Purescript and/or Elm. And the list goes on and on.
If you're thinking back-end JavaScript is lacking this kind of churn you're mistaken (or just missed what's out there). Sails, Nest, Feathers, Nodal, Polka, Fastify, Hapi, Restify, and Express are all different, and mostly they are drastically different from each other.
It takes longer than a year to "learn JavaScript". Kyle Simpson brings this up in the intro to one of his books in the "You don't know JS" series that the fundamental flaw is that it's easy to get started with JavaScript and easy to hit a plateau with it and not realize how broad and deep journey into JavaScript mastery will take you.
The key point is not to over simplify or give up on learning the variety of dialects that are possible. JavaScript is still the most widely used programming language and when so many other brains are all doing a thing together you're inevitably going to see complexity, but you'll also find a ton of innovation and elegance.
If you choose to be a career JavaScript developer there's no escaping that, as you'll rarely get to decide how you get to code in JavaScript at a given employer. Becoming versatile and fluent in a variety of dialects is much wiser than searching for a sliver bullet. And that goes for front end as well.
I know there's backend churn. It just seems slower and less frantic.
I think that's also because some libraries like Express are so low-level. It's just begging for a controller implementation or something else so you aren't working at every project as a middleware-oriented, request-based boilerplate extravaganza. And then from there, you realize how much responsibility is in your controllers and start layering down that responsibility. The building blocks have more or less all been agreed upon, whereas it seems like every front-end framework focuses on how to reinvent the wheel. Everyone talked about all the possibilities these frameworks would bring about and how it was going to change development forever, and now most companies are scrambling to build a reusable component set so they can get out of the game.
That's ONLY because there are far, far fewer coding back-end JavaScript than front-end.
I'm not really sure what the point of this article is. I feel like I see a lot of people taking shots at front end, and I don't think there are any better solutions than what we've been doing. Backend sits on top of tech that hasn't really changed in who knows how long. Meanwhile front end has had to grow to support all kinds of new UI/UX's.
Frontend is dreaming up new easier ways of doing things. That causes a lot of churn. Yes a big problem is backward compatibility. I can tell you now that web components, while great, still aren't the solution to the constant learning that we must do. There are lots of problems with web components that have yet to be solved. Styling is a sore point for one. For two you're still using a library to develop web components. Polymer had 3 major versions with big breakages between 1 and 2. Ultimately Polymer was superceded by lit-element. There are also a number of other competing libraries. And to top it off web components only solve the component aspect. They don't manage state, handle routing, work as services, do form stuff, etc. All things that frameworks would still be useful for in a world where web components are king.
There are lots of questions we have to answer on the front end and the consequences of those choices extend into areas we had no idea they could. You could have a negative outlook on the whole thing or you could stand back and marvel at the fact that we've done some impressive as hell work over the years. There's still more work to be done, and we'll get it done.
The point was me to share my thoughts and ideas. That's what blog posts are for.
Fair enough. Apologies if that came off harsh.
As someone who started writing core javascript 20 years ago, I can say that JS frameworks and libraries have saved me far more time than they've wasted. Yes, there have been headaches along the way (I'm looking at you, AngularJS), but they have unquestionably enabled me and my teams to get to market more quickly than without them.
That said, JS has definitely evolved -- as you mentioned, ES6+ makes life much easier for us, and the language continues to evolve in ways that are helpful. It'd be great to have the language progress to the point where frameworks feel unnecessary, but that's a looooong way off.
I have followed the same path as you when i started "re-inventing" myself as a JS engineer. Started on React, ES6, ES7 and a lot of different packages and then slowly started moving on towards back-end, NodeJS, Express, etc.
Noticed same exact issues, backend and way more stable and even fun place to be also IMO even more easier to work with.
On FE simply there is just too much to worry about and too much to learn and FE is less standartized then backend.
Not saying that we shouldnt update our knowledge, we should update our knowledge but its another thing learning new stuff and putting them to practice and another thing being afraid to update a simple dependency because it could break your whole app.
That's why I love backend. Tricks from old and obscure PHP blogs/forums can still be valid today.
You really only have to worry about the server your code is running on, instead of any browser+os combination the user can have.
You should really look into Aurelia. Unlike most frameworks and libraries, it has a small learning curve and doesn't have a virtual DOM either and can be used without a compiler. It has also regularly beat Angular and React in numerous benchmarks. It has also been around since 2015 with a v2 around the corner.
My only question regarding your ideas is what about enterprise grade applications?
I totally agree that with small-medium size applications & businesses, this is totally applicable. But when you have hundreds or possibly thousands, or even more developers all working within the same ecosystem, surely then you'd have to agree that utilising such frameworks makes sense? Not to mention the extensive documentation stating all associated risks around using a stated ecosystem or set of technologies.
Talking about constantly learning, even with the back end we need to think about the browsers that customers are likely using. An example being how in one of the applications my team has been working on, a HTPP only cookie that was being set server side wouldn't persist on the client device when using IE... All because it had the secure flag.
But talking about frameworks & reinventing the wheel, personally I think that the vast variety of technologies to handle application state is getting a little obscene, I've personally been using my own solution for personal projects which is essentially just a wrapper around using custom events. If you're interested at all, by all means take a look at the repo.
Nice, I'll take a look!
Checkout my project.. nimble-ide.com
If you like Svelte, try Riot JS. It's much the same and has been around for years. Currently at v4
Solving problems, that's what a Full Stack Dev defined. Nice thoughts by the way. Keep up the great works, Dude.