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!
Frameworkitis
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.
Frameworks are there to abstract away from designing in Javascript, in an attempt to make Javascript actually viable. Because Javascript was never up to the task of translating ideas into a piece of functionality without undue pain and trepidation, there is a mess of frameworks to document its failures. Frameworks are toxic and cause an inflammation. Inflammation is “A response of body tissues to injury or irritation”. In this context, it is a response of abstract cognitive tissue to injury or irritation. Frameworkitis is a real thing, and it’s a problem.
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
clang -targetarchitecture, or gcc mycode.c -o myexecutableprogram if using the GNU compiler collection. Once the code is compiled, the resulting bytecode is transferred over the internet and then either run directly on the machine or compiled to machine code with a JIT (just-in-time) compiler. This technology is developed by the W3C (World Wide Web Consortium). Wasm cooperates with Javascript and the existing framework ecosystem. It is currently required to run inside of Javascript. This is not a necessity, long term, but it is there for compatibility and to ease the transition over to Wasm-powered technology.
Example developer workflow for Wasm:
- Develop in C, C++, Haskell, Rust, etc.
- Compile to Wasm language.
- Call Wasm functionality from Javascript. The nested call structure is HTML→ Javascript → Wasm, or HTML(Javascript(Wasm)).
I have questions, myself, about how much Wasm will be able to control the DOM. It would be nice to eliminate Javascript entirely.
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.
Likewise, Javascript and HTML are inadequate for modern web needs. The decision to make Frameworks was a kludgey after-thought that was designed to make up for a protocol and languages that were never intended to handle the workload. Instead of building these crappy work-arounds, engineers should have modified the protocol, or ditched it and created a new one that is intelligent enough to handle modern web needs. They still can, and they should.
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.