DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. The Battle of the Packages

The Battle of the Packages

Modern web development is horrible. Want to know why? Well, I guess it just 'depends' on your outlook, but to Nathan Rijksen, dev lead for Komodo IDE, the old school way of doing things wins out.

Nathan Rijksen user avatar by
Nathan Rijksen
·
Feb. 02, 17 · Opinion
Like (1)
Save
Tweet
Share
3.21K Views

Join the DZone community and get the full member experience.

Join For Free

In a way, I’m a very isolated developer. Not in that I work from home, which I do, but I work on Komodo, which comes with its own "stack" (Mozilla) and doesn’t have access to a huge package repository like you would with Node.js. This means much of the work I do is isolated within this stack, and I only interact with what’s happening in the "outside world" through integrations and side projects. You might get the sense that this is a negative, and certainly in some ways it is, but I consider this a positive overall because, frankly, modern full-stack development sucks.

In the Beginning... There Was Lamp

I’m still relatively young... at 31 years of age, I have roughly a decade and a half worth of programming experience. But things move fast in the software world, and I remember a much simpler time... the time of LAMP. This was a time in which that simple abbreviation encapsulated the entirety of what it meant to be a "full stack developer." Linux - Apache - MySQL - PHP. Of course, depending on your roots, your stack might have looked somewhat different but you’d likely have been able to summarize them in a similar short abbreviation. Of course, frameworks existed, but they tended to be far more barebones and since you didn’t have package management everything tended to be a lot more self-sufficient.

When I would start a new project, which was often, I was young and full of energy. All I would do is bootstrap my project with my framework of choice and start programming—all within the span of 10 minutes. By the time my project was finished, 90% of the code would contain the application itself. Now, I’m not necessarily saying this was "better" than what we have now, I’m simply trying to illustrate how "simple" things were then. Simple in the sense that it was easy to wrap your head around the "full stack."

Down the Rabbit Hole of Dependencies

I still like experimenting these days, and I often start small projects on the weekends to experiment with new technologies. Most of these projects never see the light of day, they’re experiments for me to learn from. But it really has made me realize how "full stack development" is basically dead these days. Today, when I start a new project, I easily spend half a day setting up dependencies, constructing my build system, setting up the foundation for unit tests, and installing some basic libraries my application needs. Usually, by the time I’m done, I’ll have exhausted my motivation to work on the actual application I intended to work on. I can’t even imagine how jarring this all must be for new developers.

Here’s the kicker though, when I start a new "full stack" project these days and I install everything I need for my project, I don’t end up with the sum of its parts. I might have a direct dependency on a total of 10 modules, but those 10 modules each might have a dependency on 10 more modules, and those might then each have a dependency too. It makes for a very deep rabbit hole and for you to truly be a full stack developer you need to know how deep that rabbit hole goes. My simple 500 line application might turn into thousands of lines of code worth in dependencies.

Komodo is very different in this regard, and it’s one of the reasons I very much enjoy developing Komodo. Komodo does not have dependency management. Old school! Now, it does have the ability to include dependencies, mind you, but there is no encapsulating dependency management system. This means any dependency we add to Komodo practically has to be self-contained because anything else would be both a nightmare to import and a nightmare to maintain. While it certainly shows its age in places (Komodo is over 15 years old), what you end up with is a codebase that is extremely navigable. We have full insight into any code that is introduced to the project and it doesn’t require us to review dozens of additional dependencies.

Web Development Evolution

As developers, we go through an interesting "growth" cycle. Starting out programming, the possibilities of what you can do are overwhelming. I remember when I was learning how to save, update, and delete database information based on user input; my mind was going haywire with the endless possibilities it presented me.

Soon after, we learn to contain ourselves and our focus shifts from the applications to the logic of our code. This is where things go really crazy, we come up with the most over-engineered and abstract code structures known to man… just look at any modern PHP framework (zing!). "Why make a basic to-do app with basic logic when that logic could also encapsulate any other app that saves, updates, and deletes." Abstract everything, test all the things, oh and maybe actually write the actual application.

Once we reach the final stage of our "growth" cycle, we’ve realized how pointless this over-abstraction is. Our code is in service of our application, not the other way around. If we’re writing a to-do app we create the basic logic required to add, update, and delete a todo item and call it a day. No time wasted developing the core logic, and more importantly, the resulting codebase is (ironically) all the more maintainable.

It often feels to me that the stage we’re in, as web developers, is the middle stage I just described. Everything is being abstracted away and to the point where it’s hard to tell what you were even doing in the first place. Personally, I’m done trying. I’ll continue to experiment with new technologies, but I think my future experiments will be relatively old school. And I look forward to package managers "growing up" to the point where they can provide their core functionality without being "exploited" for it.

dev Dependency application

Published at DZone with permission of Nathan Rijksen. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Upgrade Guide To Spring Data Elasticsearch 5.0
  • Deploying Java Serverless Functions as AWS Lambda
  • 5 Factors When Selecting a Database
  • The Quest for REST

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: