Introduction

My first real memory of engineering was in technology class, 1992. Georgia had just enacted a state lottery and as part of it's plendge to use it on education, we got a technology class. The old school woodshop teacher who now had to teach it didn't care much for the row of new Dell 486 Intel computers, the only computers in the school who were allowed to had Sim City installed. The kids were excited about the DJ booth that consisted of expensive looking microphones and a tape deck to record into. My eye was on the Robot arm, installed at one Dell in particular. That computer was reserved for the glistening arm's software, a simple BASIC like syntax that could be used to move it around.

All of that was off limits for the time. Instead, the old school teacher, Mr Judson, wanted us to focus on a thin strip of balsa wood. An exacto knife for cutting it, and a spirt of elmers glue. We were to build a structure in class, and using the least amount of material, build the strongest possible support. They would be tested the next day, after they'd dried. He showed us how diagonal placement meant strength in the least possible amount of wood. We got to work. Thinking back, I imagine a lot of what we were learning was angles and cutting small wood with something we could control and learn to respect when inevitably someone cut themselves at some point along the way. I think we all probably cut our fingers that day.

The next day Mr Judson brought forth a contraption to test the strength of our towers. Each about siz inches tall, by a coulple inches wide. He set each in and weighed them before turning a knob to tighten a vise-like crushing mechanism, making something of a drama of each turn, until the towers cracked somewhere, and he'd mark off the pressure for each design.

There was a winner that day, I don't know who. But I do know I wished he'd gone back and continued to teach about structural engineering and given us a real crack as improving our scores. We never built another tower using what we'd learned. We ran off to play Sim City, or noodle around on the robot and make it pick stuff up and the the essential lesson of using light sharp tools to create light yet strong structures failed to recall inself through much of my professional career. The physical and economic neccessity to keep our structures as strong, stable and simple as possible carries into the rest of the engineering fields. Not just structures. Less phsyical material involved always means less to maintain, less energy to move it, less that can go wrong. And the counter virtue of strength, ability to hold together under stress from many angles. We in software development rarely apply these fundamentals, feel they don't apply because we don't lift the code with our muslces. But lift it we do. Mental load for constantly switching between the old way of doing something to an entirely similar yet frustratingly more complex version of the tools. Add to that many of the "modern" ways of development look like a Rube Goldberg design. All these bells and whistles for the purpose of selling the open source software to the devloper who many want to use it.

Code elimination is liberating

"The difference between solving a problem and eliminating it is, the solution requires more complexity. Elimination reframes the system so that problem doesn't happen."

Web technology has broadened in the 24 years since I began my career. It will probably be broader still by the time you read this. By broad I mean the number of knowledge domains has increased along a logrythmic path along with the number of new participants in the industry. Knowledge domains being seperate systems or workflows someone would have to understand the workings of to use effectively. A language, with it's syntax and idioms is an example of a knowledge domain. JS is a language and JS developers don't take C++ develoeprs jobs usually. Even though the syntax is nearly identical, the idioms and workflows are different.

More participation is of course on net, a good, but not without important trade-offs. I'll argue in this series, knowledge domain creation without a historical perspective or training on existing tools, leads to a kind of broadening along a fractal landscape. And in some cases, charlitains. Someone doesn't understand how to square the fact that HTML doesn't have loops with the need to loop over data and display HTML differently, can easily be taken in by a charlitain promising to banish the perceived hardship with some new ideology in the form of a Framework or new language.

Companies and people pay the price for taking the bait. Hiring and learning difficulties lead to artifically inflated salaries. Domain-specific languages built on top of other languages is the largest aspect of this. But any software stack that layers abstractions on top of other open source tools will eventually become too expensive to maintan and need to be rewritten. The timeframes of the rewrite are much smaller than in days past. A few years maxing out at half a decade.

Enclosed software "ecosystems" cause factionalism among engineers, even ones doing the same work. Knowledge across even thin language boundaries is often not accessed by newcomers and anti-patterns in software emerge as they become senior and build their own way forward. If you build upon anit-patterns long enough, a generational lapse in the fundamentals occurs. And at least one such lapse has occurred already in web programming and we're only 30 years in.

I'll argue that simplicity is the only cure for this kind of fractally inward expansion, and simplicity brings with it not only more freedom and expertise in hiring, but also longevity of the systems we build and most importantly happiness of the engineers. Reducing the knowledge domain of your teams to one of softwares first principles, instead of new flashy FOSS products will fundamentally change how they will solve problems. Those products will always have more dependancies and will take valuable brain space from your teams while promising features that are only ever more than a software design pattern made standard.

Disclaimer

Simpicity is not an all or nothing argument about writing every little thing from the CPU instruction set by hand. Using other people's code or other people's APIs can be useful and a quicker development time, no question. It's not a call to go back to Assembly or C as languages built on virtual machines are useful. Those choices come with trade offs in complexity that developers must grapple with. I won't be talking about every level of complexity. I'll be suggesting ways we can remove entire areas of the software stack and replace them with something simple and sistainable.

I wholeheartedly recommend using libraries/packages/binaries/other people's code in general, to further your objectives and I trust you'll assess the trade offs. The argument I'm making is specifically about not using web frameworks or much of any boxed-software professionally.

The critique does bleed into a larger look at the culture of how other people's code has been marketed and product-ized to our collective loss. But web developers have to make a living in the world as it is. So, apologies if I bleed into something you're passionate about. The main argument is what I hope you focus on in this code as we go course.

Web development culture is consumerism

The trade-off with choosing yet another framework that might solve your frontend development problems, is by placing our sphere of knowledge in the hands of various frameworks likes, React, Angular or Vue. Incompatible methods for creating effects with the browser, we create a giant downside that we seldom discuss. It's a stool that stands on 3 legs.

1. Web Search is splintered, making it very low quality

Most of the problems we encounter in web development are not new. Because we use so many tools, the solution to making X work with Y, like say, E-Commerce work on Wordpress, is often Z, some glue code plugin with a very specific interface for it's feature set.

So when we search, how do I do something on the web, we find what is the non-professional, or at least the non-coder answer up top, with a few keywords we get sites optimized for these kinds of, how do i questions. The question is straight forward and the answers tend to depend based on the tools you're using. Just posting a snippet that might work is often considered the best answer.

But even the best answers that consider common frameworks and tools

2. Web Culture is splintered further.

3. Web Knowledge isn't about the the web anymore.

When you learn the ins and outs of a templating language for the web or some new library about how to handle data on a page, it can feel like you're learning about the web. But those concepts include code. Code to do the thing on the tin, code to write it to other libraries and files, code to maybe deal with a bunch of options you're never going to use and code to maybe deal with a plugin system that hooks in and does some, god knows what to you code.

The web is over here. The framework at the end of the day, will always have to just call some browser function that you could call and save all this code. All these lines of code, often is just hiding some useful coding pattern that you might like to know.

I'm looking to uncover those patterns.

If we're going to ruin modern web knowledge, splinter web development culture according to some idea of how to parse the templates, we should at least get something for it. Faster websites maybe?

[ Shots of load times and loading animations]

Load times? What about faster development. Lots of, free stuff, good productivity?

[ React, massive code to do simple stuff]

Well surely we get a more automatic, streamlined, efficient build experience than anything we could craft ourselves.

[ Shots of build times in the 30 minute mark ]

Someone else's playground

Often when developing in a framework, the task is different. The question becomes, how can I get feature X to work in this framework. Does it come standard? No? Okay, plugins? Mmmm.

When developing a framework for yourself, your choices are different and your references are different. You don't refer to Google or Stack Overflow. Instead you revisit your code and add the feature as simply as possible. Possibly you steal code from other people's projects. Knowledge, but more importantly, freedom is a byproduct of reading the code. The freedom from the idea that any of these products is doing anything that you couldn't do with your own twist on the idea.

These idea twists, the forking of other people's code and modifying it is what open source is all about. When the core team is the only one to add to a framework, the downstream (unintended) affect is boxing the developer's creativity in. Some do a better job than others, but in order to be a framework, it must prescribe ways to do things. The "Angular way" or formerly, "The Rails Way". There have been enough generations of this phenomenon to draw some conclusions about the tradeoffs.

Using "someone else's playground" is a opportunity cost on a lot of levels. We lose the feature space around where the framework directs us. Complete frameworks do not offer every feature, so we're consigned to seek out what's the best practice plugin (that everyone else is also using, that could all have the same exploit, possibly caused by the code at the boundary of the 2 systems. Also, this plugin was developed by one grad student. Who will stop supporting it.

How do I know these things will happen? They happened exactly like that in the Rails community. They happened exactly like that in the node community.s There's also only one way to make money off these playground.

Making money off open sourcing your framework

The best example came from Rails, where the application was Basecamp, and it was the SaaS they made money from. The framework brought them much fame and dividends in the Web community. As new frameworks tried to emulate this success, they didn't have apps made from them that paid. But they did scratch some developer's itch. So something like Meteor or Gatsby or Next would start to sell hosting that made deployment a one liner. Which is great for a demo, but not terribly configurable. Of course the hosting also solved the biggest problem for developers. These javascript frameworks were too slow to build and hard to scale. Why not let the people who made it solve those problems? Not sure how profitable that is but it does take money or manpower to fix all these bugs in all their releases and keep the framework afloat. Money and manpower we wouldn't need if the framework wasn't trying to be everything to everyone, or a "platform". If it wasn't trying to have a plugin system for instance, or be compatible with a variety of databases. This is all extra code, someone somewhere has to maintain. And your start up depends on them.

Of course, the other way to make money is with conferences, and the perks of starting a conf, is you get to be keynote speaker. And then everyone will listen to you. Seriously, this is a big incentive to start a cult, I mean conf and invite everyone to learn from you, in sessions, on a retreat.