📐 Web development as its commitments

There are many paradigms of web development, and many have acknowledged this. In many cases, software may be built out of web APIs, and web sites may depend on software components; but generally, the web is not software even if it depends on software; software can exist without linking. The main entry points of web development involve certain domains (in no particular order):

• Design principles: [less components] MVC vs MVVM vs MOVE [more components] vs … (which might implement any number of design patterns, best fit for the “layer”: data layer as Observer pattern vs controller layer as Delegate pattern), but I guess now we just live in the age of Model-View-* anyway (Angular Components are Classes, React is basically Components/HOCs as Classes, when they’re stateful, and Functions, when they’re stateless) while various reducer/action/proposal/whatever strategies have made it more intuitive to break up God Controllers and Sumo Models communication patterns
• Design patterns: like most items listed here, it’s a matter of fitness to the problem at hand (communication between code constructs, code reuse, data privacy, etc). General types are: Creational, Behavioral, Structural
• Planning principles: all the different variations of Model-driven Engineering (DDDD, MDA, ABSE, etc)
• Stating (or state management) principles: SAM (TLA+, loose coupling of actions) vs Redux (coupling model mutations and intent logic)
• Debugging principles: console.log vs everything else (sure, there’s debugger, pryjs, etc), but the objective fact of the matter is that console.log is the greatest debugging tool ever conceived; I don’t make the rules
• Reporting principles: Code coverage, Static code analysis [1] [2], etc
• Logging princples: interfaces (e.g. HTTP), services (e.g. DB), whatever “layer”, etc
• Consistency principles: ACID vs BASE (addressing CAP theorem)
• Schematizing principles: Relational (MariaDB, SQL) vs Non-relational (MongoDB), as far as Databases go these principles can set problems for servicing and scaling depending on complexity; then there’s the ORM discussion, which further breaks down into whether or not to use a graph database which is a kind of tree-structure (all related to depth-first vs breadth-first search)
• Separating principles: CQRS (separate models for reading/writing to separate databases) vs CQS (ignores the model, separate services for reading/writing)
• Technique principles: microservices (and therefore choosing when to do choreography vs orchestration of containers, best practices for CI/CD) vs monolithic
• Protocological principles: agent-centric (DHT) vs data-centric (blockchains)
• Compute principles: I/O bound (Node.js) and memory bound vs CPU bound (lots of languages will be better fit for one of the other, just as they’ll probably have answers to any of the principles above and below in this list)
• Scaling principles: Multi-Process vs Multi-Thread (JS is single-threaded, e.g., and calls on C++ to do CPU-bound heavy work)
• Serialization and Interchange principles: basically, BSON vs CBOR, JSON vs XML vs …, which has relevance in discussions about performance as far as HTTP/3 and CoAP are concerned (webbing up the IoT as it were)
• Styling principles: Object-oriented, SMACSS, (A)BEM, utility classes, Organic CSS, a mix of all (sometimes there’s technology wedding that enables new principles which probably always should have been part of the base language, hence HTML and CSS are often considered “living” standards); and generally this is where “responsiveness” (responding to platforms like Desktop versus Mobile) becomes a kind of Design problem as they both can involve a “capabilities testing” approach where fall-backs are used in a mix of progressive enhancement and graceful degradation
• Markup principles: HTML vs the rest… (this just centers on readability, as programmatic templating and one-way or two-way or three-way data-binding are expressible no matter what you choose, but it’s a different matter as to whether an ecosystem will support Pug or Jade, etc.)
• But wait: not just readability, semantics, information architecture and accessibility: server-side rendering becomes a question and how to ultimately render HTML for the search engines: committing to shared understanding vs closed and then also the question of producing machine-readable tags: disabled users, non-disabled users, machines are all readers of your documents.
• Paradigmizing principles: object-oriented (is it really about inheritance, is-a relations vs has-a relations, or message-passing?) vs imperative (procedural, how-to-process; of which dynamic processing is a subset) vs declarative (what-to-process; of which functional programming is a subset); SOLID can be implemented probably better under functional programming (Objects-linked to other objects) than object-oriented programming (with its taxonomic classification and encapsulation problems); as much as you try to go inheritance based, the closer you’ll come to the diamond problem.
• Typing principles: basically, typed vs non-typed (TypeScript is not sound)
• Verification principles: FISL versus the rest (Turing Complete Gang, or at least those who judge themselves relative to TC: Bitcoiners call Bitcoin “Turing Incomplete” but that doesn’t necessarily mean its scripting language is context free)
• Testing principles: TDD, E2E testing, BDD, AAT, RT, IT, Accessibility testing, Penetration testing, OWASP, Vulnerability testing, Build testing, Performance testing, Spike testing, Smoke testing, Installation testing, and the list goes on…
• Scraping/automation principles: basically, server side vs client-side
• Profile/Documentation principles: Docs-as-code/auto-documentation (jsdoc)/self-describing (again, REST)/ALPS vs (effectively) Centralized docs (in wikis, etc.), though Sphinx, Gatsby, etc. could be wired up to consume generated docs
• Architecting principles: REST (stateless) vs stateful (recall that blockchains are, depending on your audience or concern, not stateless, though some will say they have “stateless verification”, obviously in some sense the “state of the chain” drives it, but we might not call “it” an application, as Bitcoin in a certain sense has yet no “killer app” or really any “app” except wallets, where “state” takes on perhaps an unrelated meaning; but is it really, though? does REST not ultimately touch, and make absolutely visible and plain, on a political intersection that technology makes with the world and its “states”? Should we apply REST’s flatness, opacity, decentralization, statelessness as a principle to politicking as such?); anyway, REST can achieve features of GraphQL but GraphQL can’t REST. REST can be implemented over WebSockets, gRPC, etc. REST is about: is the “control” inside the resource state or is the “control” inside the server: “application state” is nothing but the sum total of resource state directives, hypermedia controls; that is, application state is a virtual state machine, not actually embodied (i.e., centralized or hierarchical)
• (authn) Credentials principles: Session vs Tokens (like JWT), Location + Risk
• (authz) Permissions principles: Role (see ODRL) vs Capability vs Org vs Attribute
• Identity principles: Attribute, Relationship, Spacetime, Capability, Presentation (which might overlap with Security, Privacy, and Personality: Openness, Conscientiousness, Extraversion, Agreeableness, Neuroticism; yes, many calls for GDPR talk about “must-know” principles, but they ultimately reflect these five “mental models” and are mere derivations/applications from them)
• Crypto principles: basically, should I roll my own or not? You shouldn’t; figure out what your needs and requirements are. You’re almost always going to hashing, salting, and encrypting something whether it’s personally identifiable information (PII), passwords or events (decisions and relations). Choose the crypto algorithm appropriate to scale and the task (e.g. searching or writing Red-Black trees, Merkle trees, etc). Blockchains only relocate trust to the protocol and do not eliminate trust: you almost certainly can do whatever it is you need without a permissionless blockchain, unless your goal is to develop an ideologically- and narrative-bound ecosystem which will privilege accumulation and pollution, and develop enclosable carriers of communication: all the preconditions for undoing any claims to decentralization because market elites will politically influence the “cryptoeconomic” dynamism of the cybernetic system (“there’s no politics in our meritocracy” is a political stance). There will always be mediators, purifiers and translators, just as real as buyers, sellers, shareholders and investors, no matter how much you cannot see them or define them outside of the system. Cryptography is a technology and does not in and of itself become “more real” and at the same time “inaccessible” because of our arbitrarily defined national borders or market formations: nation states and markets are factors in the life of protocological matter and their liberatory potential. Crypto protocols might enable local financial freedoms, even though non-crypto and non-fintech seem to be doing a better job at that, but they’re not going to enable an international revolution just because they enable black market transactions (security by obscurity is still a security hole), unless they first address their underlying economic principles.
• Economic principles: stock flows (cryptoeconomics is largely a stock-based system no different from orthodox economics; labor, resources, externalities, nature, etc. all treated as “stocks”) vs temporal flows (where does “gift economy” fit in?)

None of this is to say that, under some domains, principles necessarily are to be implemented to the exclusion of others. Under testing, principles are expected to be concerned with layers and do not undermine other layers. Usually code boilerplate generators by frameworks like Angular produce unit tests (TDD) as well as E2E tests (based on tools which could just as well be used for BDD).