Despite the large number of languages and tools that will get thrown at you if you mention web development (Ruby! React! Node.js! AngularJS! Gulp! Python!), the simplest web application you can create includes HTML, CSS and a bit of JavaScript for the interactivity. You don’t even need to setup a web server: just open it in your browser or host it with any cheap shared hosting and it just works.
Anyone can maintain this application with just a text editor, a web browser and some experimentation. It’s a great way to learn how the web works, and it is a good solution for a few pages showing static information or a little JavaScript calculator.
Unfortunately, it all goes downhill from there as soon as you need to save the state of the application or introduce some other form of server-side logic. Also, your application will soon turn into an unmanageable mess if you have to update many pages every time there is a small change.
Once you get started on this path and have chosen a web development stack, you’ll end up depending on many tools, technologies and frameworks for your developments process. In many cases, you HAVE to do this: most stacks don’t include everything, and you have to choose libraries according to the needs of your project. Unfortunately, every new bit that you add needs to be updated and can break on you. You need to find a balance between the time saved now by using a tool or automating a process, and the time waster further down the road if it breaks.
It’s easy to add dependencies, but you have to make sure it’s worth it for your project (see the left-pad debacle): a good dependency is something that doesn’t make sense to code yourself. You should never trust logic that is core to your application and that cannot easily be replaced to a third-party tool. That means that using a framework for two-way data binding or even just for handling AJAX calls is the proper thing to do, but a chat application that would outsource the chatting part is taking on a lot of risk.
The same goes for the code itself. When you’re thinking of trying out a fancy new language feature, you need to ask yourself if the immediate productivity gain is worth it. Will it make maintenance and readability harder for everyone working with the code (including you in 6 months)?
You don’t need to use each and every feature of a language. If you come up with a new way to do things at every possible occasion, it’s going to be very hard to introduce new people to your project. Using a small subset of the language makes it easier to understand what’s going on, even if it’s boring. You can experiment in your own learning projects, not in code meant for production.
Likewise, I like to keep my IDE as simple as possible, and work with a small number of tools. Many plugins are a great boost to productivity, but you don’t want to depend on all of them working perfectly to be able to do something. Also, if you deviate too much from the standard working environment for your technology or at your organization, it’s a lot harder to collaborate with other people. A simple environment meant you’re able to start working quickly, without spending hours reinstalling software to setup your environment.
If you’re just working on projects for a few months and handing them off to someone else to maintain, or if you’re just doing small projects to learn, it may not be as obvious, but those are all things that can come back and bite you. Your code will most likely be around for many years, and your tools must last that long or you’ll find yourself scrambling to find an alternative quickly.
| Reference: | Simple code is beautiful from our WCG partner Cindy Potvin at the Web, Mobile and Android Programming blog. |
