My framework is HTML, CSS and JS served from a web-server of your choosing, and holy smokes it's good. In fact, it reminds me of COBOL. Grace Hopper, who wrote Cobol, understood that all communication took place across multiple channels. A COBOL program has several different streams of code happening throughout -- parts to manage memory, parts to execute commands, parts to comment. HTML, CSS and JS offers us similar multiple streams of information to express an idea.
Right now I can extend HTML to do things like:
<geo-map> <map-location>Content Here</map-location> </geo-map>
And I can put together cinematic maps like this with it: https://lindseymysse.github.io/sunken-city-graffiti-park-proposal/proposal.html
This uses my component geo-map-component: https://map.garden
There is a certain type of programmer who thrives in this environment. They love writing large amounts of code. They just LOVE setting things up. Oh, they'll have you spending money on servers soon (the executives are going to love it! shows movement!). But then adding features, pivoting features that don't make sense anymore, just gets slower and slower. Why? Because you've used a software framework to abstract away a business problem (how do we make decisions as a company) and then you keep adding to an ever more ornate set of commands to it.
Look at this beautiful thing:
That is several millions (perhaps billions?) of dollars of computation from the Baroque era.
You know why? It's a model of the solar system that doesn't account for arcs. Ol' Newton was still in Diapers when it was built, hadn't even begun to contemplate calculus
Certain frameworks pride themselves with reducing HTML, CSS and JS to a single conceptual thread to reason with, which at first glance sounds like a great idea, but it ultimately is the mathematical equivalent of looking through your front door's peephole instead of going outside. (literally here -- 1 thread, vs stereoscopic vision + time) .
I don't have a problem with a highly automated deploy chain necessarily, but I've seen enormous amounts of servers and setup used for things that needed a $500 desktop and a public ip address to run well. Heroku is awesome, Amazon GovCloud with an EC2 instance that takes git hooks is beautiful. The thing I don't like about docker is that spinning up a VM to read documentation isn't normal, but on Docker it is. There is something about this idea (I'm not going to name the software project) -- that would ask me to spin up an entire server just to read their documentation, that says it hasn't been fully thought through.
Tests aren't ever going to replace someone who acts like a copy editor for a website. A lot of the power of using JS, HTML and CS directly is you find the edges of your architecture choices a lot sooner. A large complex architecture with lots of padding around sharp edges removes those quick, loud, app-crashing bugs for those silent, intermittent appearing and disappearing bugs. My philosophy: crash sooner.
Any senior engineer is going to see 20 problems with this code. It doesn't run script tags, which would be the primary one. But what I like about this code is it doesn't run script tags. That means you can only reason about an HTML partial as a bit of <xml> or .css. With extensible HTML this lets us generate HTML that does a lot more than show a website. It's a snippet of Business Intelligence. For illustration, look at this page:
With the new method of HTML extension we can do things like have a details tag:
<details> <last-revised> Tue, Sep 14 2021 07:46 </last-revised> <author>LNSY</author> <tags> <tag>grampa</tag> <tag>two stroke engine</tag> <tag>tree gas</tag> </tags> <qr-code value="https://lnsy.studio/grampa-shmidt-on-garbage-collection/two-stroke-engine.html"></qr-code> </details>
When this is written I'm not just generating a pretty picture: I'm giving you a snippet of business intelligence. No JS to parse a
But by forcing our business communications apart -- there is the public face, there is the internal communications, here is where the programmers talk -- we are losing enormous amounts of labor to replicated, disjointed, often conflicting work.
My preferred corporation would not be one where I built a website, but one where everyone in the corporation was building the website -- internal and external pages -- at every moment. I think a snippet of HTML code served in a bucket can run something as complex as a global bank more efficiently than the fastest COBOL server. As long as you reason about the HTML and intellectual labor properly as an organization.
A markup approach to entire business communications allows for distributed reasoning througout the entire organization. Already when we talk about document store databases like Mongo, we are talking about similar data structures. Parsing XML is a solved problem, so that information can be incorporated into the whole database and generated again easily. But most importantly: it is readable by human beings who can use their creativity and intuition to reason through certain problems a lot more quickly than any computer can.