So for this week i've had a chance to use Electron - a framework for building desktop applications using the languages of the web. Setting up the boiler plate wasn't too difficult. I think the struggle was choosing the right build tool for the project.
During this time i started to dig deeper into the different npm modules.I also delved into learning about the different build tools such as Gulp, Babel, Webpack, and some other things. I discovered that there is an endless ecosystem of those frameworks, libraries, and build-tools out there. And then i realized that these are the exact jargon words that i have seen listed on many job postings. It seems like those build-tools are just variations of each other. Electron is no exception. In addition to the main framework, you also have tools like electron-builder, electron-packager, electron-forge, and some of them recommend other dependencies such as webpack to integrate. As an intern web developer starting out, this all seems intimidating because you don't necessary know what to choose. Apparently this is a documented phenomenon that exists in the field called "javascript fatigue" felt by many developers, both new and experienced.
I am an inquisitive person when it comes to code and I always want to understand how the code integrate and work under the hood.I want to catch a glimpse of the big picture of the system i am working with. This is one of those times where i felt that my curiosity is working against me. I ended up going down the rabbit hole of learning about tools, watching tutorials, and reading in-dept documentation about a bunch of different tools to see how they're connected. Even though i learned a lot, this ended up being somewhat counter productive because these things aren't related to the task at hand (yet).
So after a few days, i decided that i had to change my approach to learning new things in this vast ecosystem of technologies. I felt that things are more manageable when you're learning just enough to accomplish certain tasks at hand and then moving to the next task. I don't necessary try to remember the exact APIS of certain tools or framework but only high-level concepts of what they do. You can always look up syntax, and if you work with them long enough you'll just remember by heart. Ultimately, i am trying to avoid the pitfall of learning too many new things at once just because they're popular. I find that the field is more exciting and manageable if i learn new things in moderation and find a way to apply them. This way, i have a better chance of remembering what i learned.
Top comments (3)
What you've just learned is exactly the right approach, in my not-so-humble opinion. Back when I started professionally programming 25 years ago I would deep dive for years into specific technologies. The only time I had to make a major shift was changing jobs.
With the explosion of open source over the web you've got millions of people sharing ideas and trends coming and going.
When people ask me how I keep up I tell them what doesn't change: the fundamental concepts such as proper architecture and best practices. Along your journey pick up and maintain the best ways to solve certain problems. The language, the syntax, and the details of each framework will change, but the basics of good software design rarely do.
That fatigue is real, and it's why we push toward build-less / native / web standards as opposed to web compiling conventions. Keep digging into conventions that reduce the knowledge tree and always be willing to shift parts of the toolchain in any project if better alternatives arise, but never be atfraid to use what you know instead of immediately jumping to what's popular. JS is ephemeral, standards are eternal.
I would recommend you to try smart server and build tool hqjs.org that will help to remove configuration and building pipeline and speed you up with whatever technology you chose.