Comments on The Tedium of Managing Code

9 Reader Comments

Back to the Column
  1. This article just proved for me that I can no longer call myself a real web developer.. but I feel your pain

    Copy & paste the code below to embed this comment.
  2. I love this column, Lyza. You’ve expertly summarized the frustration inherent in our increasingly varied and oft-changing workflows.

    I’m curious if you also see this as a side-effect of increased modularization of build tools? As modules become more focused and specialized (which I’m not at all convinced is a net negative, but bear with me), the scope of problems they can solve on their own is narrowed, requiring additional modules that combine and repackage common concerns (babel-loader, cssnext), complimentary modules for different scenarios (watchify versus browserify) or modules that extend one another (gulp + gulp-if). It’s no longer enough to understand the build tasks we’ve written ourselves or borrowed from boilerplates; we must also spelunk through numerous interdependencies and middlemen to truly grasp what’s going on.

    Copy & paste the code below to embed this comment.
  3. Thanks for this article, Lyza. The last few years have introduced many components to our workflow that make it increasingly complex just to manage elements like dependencies. Pointing it out makes us realize how much has changed so quickly.

    Copy & paste the code below to embed this comment.
  4. A very good article Lyza.

    I started my IT carreer 44 years ago, there were no PC’s then and certainly no internet and I learned Cobol, RPG and Assembler.
    When the PC’s came and the internet was opened for the public, I did my own things on the PC and worked in my job on a terminal as we had mainframes and no PC’s in the companies. The rest of the history can be found anywhere on the web.

    My first web pages I coded in a simple editor like blocnote.
    My first documents (like doc and docx in Word) I wrote in WordPerfect using the horizontal split-screen to manage my layout.
    Later I used “HotDog” to create my web pages, great tool then.

    Word can be used very simple today because everything you yourself needed to do before, is done for you automaticly (+-) now.
    Also we have seen a great evolution in HTML and CSS.

    My point is that we need to focus on HTML and CSS and not on the multiple (how nice and helpful it can be) front-end and back-end tools and frameworks because who can manage them and who can maintain frameworks etc. The forest of good but un-manageable tools (modules ea) keeps growing and this will force us into a central managed direction.

    This all for the sake of our profession as web-site builders who love their work.

    Copy & paste the code below to embed this comment.
  5. The variety of tools available is quite overwhelming. But what can be done to bring it under control?

    Copy & paste the code below to embed this comment.
  6. @davidshq

    That’s a good question. I don’t have a solution now.
    It is possible to organize this in the same way as how the process and contol upon HTML and CSS has been organized. The WHAT question will be more difficult.
    Browser developers (what more? Providers?) should make clear what they accept (less can be more) and what not.

    We need to organize a discussion forum first. Let’s think together.

    Just remember that website development is unnecessary expensive allready and will be more expensive in the future because more and more specialists are needed in the development process. This means bad bussiness for everyone.

    Copy & paste the code below to embed this comment.
  7. @davidshq I tend to just learn a few new tools that provide me with a simpler way to do something that I already do (or should be doing). If the tool looks too complicated to learn in a couple of days for marginal benefits I leave it. Eventually they’ll get simpler or die off.

    The other thing to bear in mind is a lot of these tools do the same thing. Pick one and stick with it. If after a couple of months it’s not working for you, move on. You don’t need to know multiple ways to do package management for example - just one.

    I think a lot of people get wrapped up in thinking they need to know everything. Backbone, React, Angular, Grunt, Gulp, Require, Bower, Sass, Less… the list is endless but you probably only need around 5 core tools. One or two JS frameworks. One task manager. One package manager and one preprocessor.

    Copy & paste the code below to embed this comment.
  8. Yes, JavaScript on the client-side is more complex than programming for Node.js in the server-side. However, there’s a nice package manager out there for the client-side called JSPM (http://jspm.io/), which is built on top of SystemJS. It doesn’t solve all of the problems you’ve mentioned. However, it solves at least some of them.

    Copy & paste the code below to embed this comment.
  9. Thanks for this article, Lyza.we need to focus on HTML and CSS and not on the multiple (how nice and helpful it can be) front-end and back-end tools and frameworks because who can manage them and who can maintain frameworks etc. Harga Sepeda Gunung

    Copy & paste the code below to embed this comment.
  10. Sorry, commenting is closed on this article.