Source Maps, Transparency, and “spaghetti code”
Beginning in Mod 2 of Flatiron School, we moved from back-end concepts like MVC, object-oriented-programming, and relational databases, to the front-end for the very first time. At that point, most of us had only a basic understanding of HTML and CSS to style our index and show pages and crude forms, but everything we learned at Flatiron after Rails is focused on what we can see in the browser. Once I started learning JavaScript I began using Chrome’s built-in DevTools to inspect elements on websites I visited all the time, and mess around with fonts, colors, and DOM elements, as I now understood.
Chrome DevTools and View Source are crucial tools for learning web development. As Ruby on Rails creator David Heinemeier Hansson writes in a recent blog:
“I owe much of my career to View Source. It’s what got me started with web development in the first place. Seeing how something real is built puts the individual pieces of the puzzle together in a way that sample code or abstract lessons just don’t.”
DevTools and View Source allow users developers to read, compare, and copy code from the most popular web applications and experiment with their own projects in the browser. But, if you’ve used the DevTools on enough websites, you’ll come away with the impression that developing for the web has never been more difficult.
Because there are so many new front-end frameworks, libraries, tools, and techniques, front-end web development at the View Source level appears extremely opaque. There are countless blogs about how everything that was once easy in web development is now hard again, and how twenty years ago beginner web developers would make their own websites because they saw examples of HTML and CSS that they were able to actually read. Who today can actually read markup?
Most of the JavaScript, HTML, and CSS we see when we View Source or Inspect a website today has been compiled, compressed, minified, and bundled. I learned about minification by copying all 410 lines of my Mod 3 project’s index.js file into a basic JavaScript minifier, which removed all whitespace, and rendered my hand-wrought artisanal code as one line of pure function.
This is the way JavaScript is presented on most web applications when you View Source on a page, and it’s incredibly difficult, if not impossible, to read.
One of the hypothesized reasons for this problem is that JavaScript simply got too big. JavaScript frameworks dominate front-end web development, and increasingly powers back-ends too with Node.js server. But JavaScript wasn’t built, at least initially, to power the entire web. JavaScript’s forEach() array method, for example, wasn’t added to its library until December, 2009. If you’re writing current JavaScript for older browsers, you have to transpile your code using something like Babel, which is mainly used to convert ECMAScript 2015+ code into a backwards compatible version of JavaScript that can be run by older JavaScript engines. But what if Babel doesn’t transpile forEach?
Developers today are using highly complex toolchains of JavaScript transpilers, minifiers, and bundlers, to fix JavaScript. Developer David Rupert writes that:
“As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code. Tracking the differences between the input and output and the processes that code underwent can be overwhelming.”
After a block of code has gone through all this it’s no wonder that on the client-side we can’t make sense of what’s going on on the page.
A couple answers to this problem are tools like source map explorer and webpack bundle analyzer, which allow you to analyze and debug JavaScript code bloat through source maps, and visualize the size of webpack output files with an interactive zoomable treemap. But there has also been a movement towards building transparency into projects themselves. Source maps, for example, allow developers to see code as it was written by the creator, with comments and understandable variable names. Rather than keeping source maps as just a local development tool, developers could make them available on the client-side when they click View Source, as well as using readable HTML and CSS. Source maps are not only transparent, but would allow users to visualize, debug, and play around with code they see every day in the browser.
