!rant

This was over a year ago now, but my first PR at my current job was +6,249/-1,545,334 loc. Here is how that happened... When I joined the company and saw the code I was supposed to work on I kind of freaked out. The project was set up in the most ass-backward way with some sort of bootstrap boilerplate sample app thing with its own build process inside a subfolder of the main angular project. The angular app used all the CSS, fonts, icons, etc. from the boilerplate app and referenced the assets directly. If you needed to make changes to the CSS, fonts, icons, etc you would need to cd into the boilerplate app directory, make the changes, run a Gulp build that compiled things there, then cd back to the main directory and run Grunt build (thats right, both grunt and gulp) that then built the angular app and referenced the compiled assets inside the boilerplate directory. One simple CSS change would take 2 minutes to test at minimum.

I told them I needed at least a week to overhaul the app before I felt like I could do any real work. Here were the horrors I found along the way.

- All compiled (unminified) assets (both CSS and JS) were committed to git, including vendor code such as jQuery and Bootstrap.
- All bower components were committed to git (ALL their source code, documentation, etc, not just the one dist/minified JS file we referenced).
- The Grunt build was set up by someone who had no idea what they were doing. Every SINGLE file or dependency that needed to be copied to the build folder was listed one by one in a HUGE config.json file instead of using pattern matching like `assets/images/*`.
- All the example code from the boilerplate and multiple jQuery spaghetti sample apps from the boilerplate were committed to git, as well as ALL the documentation too. There was literally a `git clone` of the boilerplate repo inside a folder in the app.
- There were two separate copies of Bootstrap 3 being compiled from source. One inside the boilerplate folder and one at the angular app level. They were both included on the page, so literally every single CSS rule was overridden by the second copy of bootstrap. Oh, and because bootstrap source was included and commited and built from source, the actual bootstrap source files had been edited by developers to change styles (instead of overriding them) so there was no replacing it with an OOTB minified version.
- It is an angular app but there were multiple jQuery libraries included and relied upon and used for actual in-app functionality behavior. And, beyond that, even though angular includes many native ways to do XHR requests (using $resource or $http), there were numerous places in the app where there were `XMLHttpRequest`s intermixed with angular code.
- There was no live reloading for local development, meaning if I wanted to make one CSS change I had to stop my server, run a build, start again (about 2 minutes total). They seemed to think this was fine.
- All this monstrosity was handled by a single massive Gruntfile that was over 2000loc. When all my hacking and slashing was done, I reduced this to ~140loc.
- There were developer's (I use that term loosely) *PERSONAL AWS ACCESS KEYS* hardcoded into the source code (remember, this is a web end app, so this was in every user's browser) in order to do file uploads. Of course when I checked in AWS, those keys had full admin access to absolutely everything in AWS.
- The entire unminified AWS Javascript SDK was included on the page and not used or referenced (~1.5mb)
- There was no error handling or reporting. An API error would just result in nothing happening on the front end, so the user would usually just click and click again, re-triggering the same error. There was also no error reporting software installed (NewRelic, Rollbar, etc) so we had no idea when our users encountered errors on the front end. The previous developers would literally guide users who were experiencing issues through opening their console in dev tools and have them screenshot the error and send it to them.
- I could go on and on...

This is why you hire a real front-end engineer to build your web app instead of the cheapest contractors you can find from Ukraine.

When you build a beautiful set of Sass files with grunt/gulp tasks, hand it off to another developer who makes all their changes in the compiled css.

I recently joined this big MNC after shutting down my own startup. I was trying to automate their build process properly. They were currently using grunt and I favor gulp, so I offered to replace the build process with gulp and manage it properly.
I was almost done with it in development environment and QA was being done for production.
In the meantime I was trying to fix some random bug in a chrome extension backend. I pushed some minor changes to production which was not going to affect the main site. That was in the afternoon.
This Friday my senior rushed to me. It was like he ran six floors to reach me. He asked, did you push the new build system to production, I refused. He then went to the computer nearby and opened the code.
It was Friday and I was about to leave. But being a good developer, I asked what's the problem. He told me that one complete module is down and the developers responsible for them left for the day already and are unreachable.
I worked on that module multiple times last month, so I offered my help. He agreed and we get to work.
The problem was in the Angular front end. So we immediately knew that the build process is screwed. I accidentally kept the gulp process open for anyone, so I immediately rebuilt using grunt and deployed again, but to no success.
Then I carefully analyzed all the commits to the module to find out that I was the one who pushed the change last. That was the chrome extention. I quickly reverted the changes and deployed and the module was live again. The senior asked, how did you do that? I told the truth.
He was surprised that how come that change affect the complete site too. We identified it after an hour. It was the grunt task which includes all the files from that particular module, including chrome extension in the build process.
He mailed the QA team to put Gulp in increased priority and approved the more structural changes, including more scrutiny before deployment and backup builds.
The module was down for more than 5 hours and we got to know only after the client used it for their own process. I was supposed to be fired for this. But instead everyone appreciated my efforts to fix things.
I guess I am in a good company 😉

It was when I ditched React. I replaced it with raw JavaScript, with frontend being built with Gulp and Twig (just because HTML has no includes). Here are the results:
1. Previously, a production frontend build took 1.5 minutes. Build time became so fast that after I push the code, the build was done before me going to Netlify to check build status. I go there, and it’s almost always already done.
2. In a gallery with a lot of cards, with every card opening a modal, the number of listeners was reduced from N to one. With React, I needed 1000 listeners for 1000 cards. With raw JavaScript, I needed just one click listener with checking event target to handle all of the cards.
3. Page load time and time-to-interactive was reduced from seconds to milliseconds.
4. Lighthouse rating became 100 for desktop and 93 for mobile.

But there is one more thing that is way better than all of the above: cognitive complexity.

Tasks that took days now take hours. Tasks that took hours now take minutes.
Tasks that took thousands of lines now take hundreds. Tasks that took hundreds of lines now take tens.

In real business apps, it is common to build features and then realize it’s not needed and should be discarded. Business is volatile, just because the real world is volatile too. With this kind of cost reduction per feature, it became way less painful to discard them. Throwing out something you spent time and emotional resource on doesn’t feel good. But with features taking minutes to build, it became easier.

I hate Sass.

When installing all NPM dependencies with npm i, it's always quick, but not with sass. Ooooh myy goood. It starts compiling. It always misses something. Your node version is always not what sass needs. It pulls out gyp which requires some native shit. The build is never reproducible, it always fails with some horrible two mile long poorly-formatted stacktrace that is just gibberish.

More than that, sass is just poorly designed tool used by frontend fuckboys to write imperative, nonstandard, non-maintainable styles. If you know shit about css, you don't need sass.

I'm so happy it's going to die along with gulp. Webpack and css modules are here.

Yes, css-in-js that has a runtime penalty is also shit. If you like its syntax but dislike everything else, use Linaria. It has no runtime penalty and looks just like other css-in-js solutions.

-$ gulp test

*30 seconds later*

SUCCESS

[oh wait, for got something... Typety type... Fixed. I don't need to rerun gulp test, right?]

-$ git push

*email from CircleCI: BUILD FAILED*

😊🔫

Fuck ES/TS 😐

Been trying for hours now to get ionic 2 to work with either generators or async functions. Doesn't work because async for ES 5 is only supported with TS 2.1 which breaks the angular compiler. Also can't use generators (not supported for es5 at all by TS).

Also can't really change the ionic build process to just take es6 output instead of es5 and transpile because it's a convoluted mess in a separate node module instead of just a gulp file like with ionic 1.x.

Why is the JS ecosystem such a fucking mess?

So CRA(create-react-app) v2 rolled out.

> started new project with my own boilerplate
> little did I know, I am accidentally doing int CRA2
> gulp-sass fails.
> Internal screaming.
> Bulma React Components fails to compile due to one type, IDK how they missed in previous build.
> fixed by removind browserlist array from package.json
> Guess what, it comes back as you close it.
> So, now I've to keep it open while gulp-sass is running, which is almost always, in order to compile.

Thank you and Fuck you facebook

Once upon a time I spent a week writing down a "Coding Conventions" document, setting up linters for JavaScript & CSS based on those rules and put the call to the linter in our gulp build task, only to figure out the next day it was commented out by some guy because "the build task was throwing errors" due to his shitty coding style...

When gulp build (expressjs + browsersync + browserify + uglify + gzip + gulp-zip + gulp-tar) perfectly compiles your code, minify and concat all js, gzipped them, minify images, package the files into a .zip and .tar... and refresh your browser 😍

you begin to have faith that its gona be a nice day ahead

When gulp takes 30 seconds to build... And you have to re-serve on every change.

Ready for webpack.

Looking at vacancies and the JS build tools asked (Babel, Gulp) and then visiting their websites I notice that I don't understand what they are going on about.

"Leverage gulp and the flexibility of JavaScript to automate slow, repetitive workflows and compose them into efficient build pipelines."

What the actual corpo fuck?

The "get started" page expects you already know npm, typescript, and when you look at their pages, well... Where does the circlejerk end and the actual Javascript start?

I've been out of the corporate loop for a few years, seems it's all about build tools these days. I need to get out of this industry pronto.

Damn I'm tired of js build tools. Having just converted my build scripts to make is really making my day. Damn it's fast.

Trying to create my own gulp build process since two days now...😖 Want to get the right folder structure and perfect build process on the first try, but that is exactly what is hindering me and I can't get any shit done...😟

I just had a ptsd (not real ptsd) attack cause I remembered in one of my first jobs we had gulp, grunt AND webpack to build our angularjs project.

Did I fix that mess? Sure!
Will the memory of it stalk me until new year? Absolutely.

When the projects repository has node_modules/, and you need build styles:

rm -rf node_modules/*
npm install
gulp compile
rm -rf node_modules/*
git checkout node_module/

I'm in middle of fucking moronic, most incomprehensible situation.
So primarily I work for a project which requires Node 6.11.5 precisely and now I've been assigned another developer's half asses'd work without any documentation about how to set up gulp, long story it took me a week to figure out it's an ant build with node dependencies oh and I nearly forgot this developer is using node 0.12.1, Can you fucking believe that?

Now when I'll need to compile/build for primary project i'll need to reinstall 6.11.5 and god knows what will happen when and if that half asses'd project comes back

This idiot has style.css / style.ie.css / style.min.css in .gitignore so every time I pull I'll need to re-build oh and the worst part I spend my weekend fixing this shit then sass compiled and shit is still crazy, CSS is written from SASS but not reflecting on server ¯\_(ツ)_/¯

While I'm writing this I'm waiting on my boss who is also trying to fix this.

JS + Gulp + Browserify is the slowest build experience I've ever used.