There once was someone I worked with – who knows, he may read this – who said software engineers are ruining the web. I think the comment was motivated because he was showing me a page that was rendered with javascript and I asked him how it loaded, performance-wise.

There are some pretty smart people writing some pretty smart plugins for some pretty cool interaction patterns and also for helping to hide the complexities of cross-browser javascript. For me, in my prototyping role, I like that. I like that a LOT.

But here’s what I don’t like. Where I once was able to download a set of files and plop them in a directory, whole install / build processes have been created to do essentially the same thing. And I’m not sure why. To me, that’s like handing control of your project over to someone else who has decided for you how you should set it up. And when developer of x plugin installs dependencies that conflict with developer of y’s plugin and with your version of Gulp, then you are screwed. Now you need to spend time untangling the mess. And if you’re like me, and you aren’t into writing your own build tasks, you are pretty much in a pot of hot water.

Here is an example. I just want that minimized js file. That’s all. Only it comes with all this other stuff…

Here’s the workflow I prefer.

1. Buy Codekit. The developer has done some pretty terrific work here and answers support questions and keeps things updated. Your browser auto-refreshes with each change you make. You can make use of autoprefixer, minimizers, syntax checkers. It really is a great piece of software. (There is also Prepos, which runs on Windows. I used to use that before another developer pointed me to Codekit.) Also, as someone who has used a gulp/watch task that a developer set up for a project, Codekit is much more robust. It doesn’t exit if you run into a syntax issue – and it is way easier to read the error log. Save the files in the wrong order when using Gulp and BAM! The process comes to a screeching halt and you have to restart your server/build tasks.

2. Download javascript files for the plugin you want to use, and link them into your files via a script (and sometimes a css) tag. It’s really not that hard. Sometimes these javascript files are hosted on CDNs (content delivery networks) but I’ve had stuff stop working on me, so I prefer to download my own versions and make sure things don’t start breaking as time goes by.

And number 3 is for the plugin developers.

3. KEEP IT SIMPLE! Don’t create stuff on top of other dependencies. Don’t require a certain compiler. Make your stuff work with Codekit and maaaaaaannnnnnnyyyyyy more people will be using your plugin. People like me, who prototype, who live in the design world more than the developer world. Make it easy for us. Please! Don’t complicate the web! You aren’t making it better with your complicated processes. You are only making it better for a small subset of people. Other front-end devs like you. And there are a lot of people that can benefit from your brain and your creations if you’ll KEEP IT SIMPLE!

Thanks for listening.

Yes, I know, it shouldn’t take a developer 10 hours to spin up Node and Mongo on Heroku, it just feels like it when you’re striving for simplicity.