Today, I looked at a friend’s web project written in Angular 2. I had visited his web app the day before, and it was a relatively simple web app where a young child could do basic arithmetic problems. I opened his repository and immediately was greeted with the most obnoxious number of files possible.
There were dozens of .ts file, which I’d never seen before. There were also several folders, each with more of them. I tried to glean what the purpose of the files was from the file names, and this did not help at all. They used dot notation in the names, such as ‘app.component.spec.ts’. Using dot notation for a file name is obnoxious, since it is already defined in the context of object-oriented programming. This mismatch between the commonplace definition of dot notation and a specialized one prevents and irritates programmers. Dot notation indicates the name of a module (ie. the file) and demarcates nested calls to functions and access to properties in multiple modules. One file cannot be a property or function call of another file, as this violates the modularity construct in programming. First impressions aren’t everything, but they still count, so I was immediately unimpressed.
I opened one of them and was greeted with a few dozen lines of inscrutable code.
What could possibly require so many lines of code? In just one of the dozens of files? The app was incredibly simple to conceptualize, so what could require a cryptic line like
import (TestBed, async} from '@angular/core/testing';? Does his tiny program really need test cases? If so, then this framework can’t be all that productive to work in.
Furthermore, why does this framework require such a noisy directory structure and such noisy code? Who thought this was a good idea? If their goal was to raise the barrier to entry for beginners and give the rest of us eyestrain and a headache, they succeeded!
Frameworks are supposed to make web programming more intuitive, streamlining the design process, eliminating boilerplate code, and allowing a programmer to write once and deploy across many devices and formats—that is, assuming that the programmer knows the metaphors used in the framework and is aware of the concerns they were designed to address. However, this added layer of learning puts a burden on anyone beginning programming, requiring them to arbitrarily choose between design philosophies, without understanding what it is they are choosing. The philosophy of “what they don’t know won’t hurt them” is just a bad idea. Programming is explicit and the tools and languages need to be conceptually concise to avoid bleeding into every other area of computer science.
The Future is Wasm
The future of web development will likely have little to do with the current toxic frameworks. Web Assembly (Wasm) is a bytecode language (an intermediate language between the programmer and machine language) that allows compilable programming languages, like C, Rust, Haskell, and others to run in a web browser. More specifically, it is a compile target for these languages. Normally in these languages, the programmer writes his code, then opens the terminal, navigates to his code’s directory, and compiles the code to his choice of binary encoding that is supported by the compiler–usually his own personal machine’s code–by running the compiler on his code files. For a C (code.c) or C++ (code.cpp) file, this might be
Example developer workflow for Wasm:
- Develop in C, C++, Haskell, Rust, etc.
- Compile to Wasm language.
The compiler for C to Wasm is called Emscripten. A very in-depth tutorial for Wasm can be found on Marco Selvatici’s Github.
Angular Router needs to die
Being new to Angular, I spoke with my friend, and he explained to me what various parts of the Angular framework do. I found an explanation of what a “Router” is in the context of Angular, and very quickly I picked up on the fact that it is an ad-hoc solution to a problem created by the inadequacies of the HTTP protocol. HTTP was never prepared for the modern requirements of interactive web apps.
Ad-hoc crutches are not solutions to failures in design. The entire industry has wasted every new developer’s time and effort, placing a burden on them to understand why these pieces exist and what inadequacies they compensate for.
Once upon a time, software engineers knew how to develop protocols, and they would do so liberally (ssh, telnet, ftp, ssl, webRTC, torrent, Usenet newsgroups). Now we just have a bunch of reactive (no pun intended) software solutions that are virtual band-aids for gunshot wounds in the software profession’s side, which have created worse problems.