When I first got into web development in 2017, the epitome of being a good developer (for me) was understanding jQuery and being able to use it efficiently. Little did I know that jQuery was almost "dead" back then, as this article shows.
After dabbling in WordPress for a while, I wanted more control over the inner workings of the website. I wanted to make good, dynamic websites. I was taken towards the framework road - and to be precise - down the Angular path. I didn't quite understand WHY a framework was needed back then.
"I can just do it with jQuery, no?" was a question I asked a lot.
The first "burnt" experience I had with jQuery was when I had to make a webpage with multiple forms that updated asynchronously and whose updates changed multiple parts of the DOM.
After a week of struggling with the code (and managing 20-25 element IDs and their linking in jQuery), I turned to my co-developer and said, "Let's use Angular please."
That was my first, important lesson towards becoming a better developer.
#1 Knowing something doesn't mean that it's the solution
The migration to Angular took a few hours and the form updates were effortless. We never needed jQuery. What we really needed was two-way binding.
The lesson hadn't quite sunk in though. Now that I understood the basics of Angular, I wanted to use it everywhere. jQuery wasn't really required, so what? Angular was the one-stop-shop. It could do everything!
My love of frameworks and the "magic" that they could do would be questioned soon. We had made a single page application with Angular. It had two forms and some lists that came on and off the page based on some conditions. The use-case was not really complex. We made the frontend using Angular but looking back at that project, I can see an important lesson in it.
#2 Vanilla JS is good enough for a LOT of things
Sure, Angular handled the 2-way binding and made form handling easier. But there were just two forms which weren't even dynamic. Just because Angular was available and we knew it, didn't mean that we had to use it. It may have sped up the process, but we could have tried a vanilla JS approach and it would have worked fine.
Over the past few months, I have spent a lot of time making tiny projects and learning from experience. Here are a few other lessons that are helping me become a better developer:
#3 Never underestimate the power of good naming
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
Writing
var ch
as
var clickHandler
can save you minutes, if not hours of going back and forth to understand your own code in the future. Keeping a habit of reviewing your code and assuming that you can improve it often helps in actually improving it.
#4 Learn Vanilla JS properly before diving into frameworks
More often than not, it helps to imagine how vanilla JS could play out instead of just jumping into a React, Angular or Vue project. Especially if you are just starting out - don't jump into a framework. Learn Vanilla JS first - it's very powerful all by itself, and even if you have made the wrong decision picking it for a project, it will help you appreciate why we need frameworks!
#5 Cut your veggies for later
It's a good idea to have a system in place. For example:
- If you know you're going to keep spinning up servers for MEAN projects, save an OS image on the cloud with all your pre-configured settings
- It helps to create code snippets and store them in a folder called "snippets" (very creative, I know). This can include stuff like database initialization, complex database queries, HTML templates, login, signup flows, CRUD operations, common CSS rules, etc.
I used to keep opening old projects and copy-pasting from them. Whenever you have to do that, just make a file in your "snippets" folder, name it appropriately and look there the next time!
This is just the DRY principle put in use across projects.
#6 Reading open source code helps. A lot
Many times we tend to get locked into our own world and our own code. It's cool to open some libraries we use and check out how the code has been written and organized. That can spark ideas, and even make us better coders in the long run.
For example, the often-used "_" before function or variable names in projects used to bother me immensely until I read up on what it meant.
We learn new things every day. For example, I learned this recently: The 300ms problem, where on small devices, the screen waits for 300ms before passing the event to the click handler. This was to wait and check if the event was a double-tap to zoom!
Although the article above says that the problem was solved, I could still see this 300ms wait behavior on button clicks when I resized my browser to less than 364px! The meta tag didn't help either, so I had to go with the html-manipulation trick from the same article. I'm still not sure why 364px was the barrier for this bug (and I'd love to have a discussion on it if you guys can reproduce the error).
I'd love to hear about something new that you guys have learned recently. Feel free to leave a comment below!
Top comments (0)