There are Many Ways to Build a Wep App - A Poem
There are many ways to build a web app, as you will come to see.
Not all are suitable for what you may need.
With proper care and attention you might discover
one approach more favorable than another…
Let’s build some apps, it won’t be too hard;
though some techniques may seem bizarre.
Just open an editor and start to type:
<html></html> (don’t forget <!DOCTYPE>!)
Let the <p>’s and <ol>’s and <div>’s and <span>’s
flow from your keyboard through both your hands.
When you are done, open it and behold -
in a browser your document unfold!
“Let’s make it pretty!” I hear you say,
That will be easy with CSS today.
Create a new file, save it and <link>,
inside the <head> – styles before you could blink!
But what of <a> or some other page?
I click on a link, but I’m caught in this cage.
I have an index but I want more,
like /about, and /contact, and /shop, or /store!
An app cannot be one static page,
we need an HTTP server to complete our maze.
We can spin one up with any language fast.
With the help of a terminal it’ll be a flash:
We start ruby -run -ehttpd
and give the port -p8080
we serve the directory with all our files
. or /www, whatever makes you smile [*]
Now we have a perfect example
of a static site - for many use-cases ample.
But what if we want to change some of our links?
Maybe all /blue should change to /pink?
We could manually edit each of our pages,
inside our text editor, but that would take ages!
Maybe this works, if our site is small,
or maybe an alternative is better after all?
If we could track every link with a name,
and reuse templates wherever markup is the same…
Then we could just simply generate
our whole static site, wouldn’t that be great?
Hugo and Jekyll and Gatsby and more,
oh there’s static site generators out there galore!
Even more powerful, especially when collaborating,
are CMS tools that make things less frustrating.
Most of the web runs with CMS systems,
don’t ignore their power, you just might miss them.
Wordpress is the master of this domain -
43% of internet pages play by their game[*].
“But we’re building apps!”, I hear you exclaim,
I will not use Wordpress, that’s super lame.
Well fine, that’s fine - if that’s how you’ll be,
let’s venture into a world of greater complexity.
“These templates are nice, but my app is dynamic.
There’s too much data for one page, I’m starting to panic!”
Relax, my friend, lucky for you I say,
“There’s AJAX to help keep that data at bay!”
We’ll serve smaller elements with no data inside,
A placeholder sits where it will eventually reside.
When users interact - like clicking a button -
Javascript will ask our server for data to shove in.
Most folks use JSON, a simple notation,
Easily understood, facilitating creation.
So our server changes its primary role,
from templating HTML to serving JSON, on the whole.
This way can work well, and has for many years,
with JQuery a standout among all of its peers.
But imperatively updating different parts of our pages,
can soon prove nightmarish when apps grow through the ages.
I know what we’ll do! I’ll share you the news…
Our UI is a function, from Data to Views[*]!
So React comes along, and has not yet stopped,
to declare a tree structure where data flows from the top.
JSX is not templates, when used in our projects,
It’s builds a virtual DOM, plain Javascript objects.
These objects are then rendered, by ReactDOM,
and diff’ed on state changes, imperative updates be gone!
We can write our whole app in this functional way,
and our sad HTML almost completely goes away.
Just have one div, with an id such as root,
a tiny HTML file and a Javascript bundle to boot!
Just one single page, no routes needed here,
when the URL is in state, the right things will appear.
Routing is done client-side, with so much more,
but this leads to issues, many things become chores.
Client-side routing can be a hassle,
and history navigation, things the browser should wrestle…
Bugs arise from how state is assembled.
Everything on one page with shared state? Developers tremble.
Projects like Redux promise organization,
of all client-side state, but can cause complication.
Data is duplicated, on two different systems,
synchronizing one and the other, becomes a tough mission.
Other issues also come into play,
like SEO, where pages must have data right away.
Let’s get to work, taking React to the Node runtime,
so we can render things twice, not just one time!
NextJS is an example of a framework,
That tries to make this server-side game work.
Render as much as possible in the initial HTML response,
which will then be hydrated on the client-side once.
“But wait, we’re rendering HTML on the server once more?
Didn’t we use to do this, in the days of yore?”
Why yes we did do this, I’m glad you can tell!
But we have extra client-side powers, when we need those as well.
Other server-side frameworks are joining the mixer,
One excellent tool is LiveView in Elixir.
Screw client-side React, Javascript is icky.
We can react using websockets, it isn’t that tricky.
Then there’s HTMX, a darling of mine,
the simplicity is tantalizing, I think it works fine.
Why should just <a> and <form> issue requests?
Shouldn’t any element act at our behest?
I’ll share an arcane secret, my young acolyte…
HTML is hypertext, HATEOAS gives it flight[*]!
An ancient idea, gaining traction fast,
while hypertext standards are stuck in the past.
The web is a beautiful, wonderful thing,
these myriad styles make my heart sing!
I hope you see just how lucky we are
that our apps can reach anyone, those near or afar.
I want you try each web app approach too.
It is all great fun, it’s been a pleasure to coach you.
Now go forth and build, in whichever way you may choose,
make marvelous apps, and no one will lose!
(P.S. Sorry Angular, Svelte, Vue, etc. etc. etc. etc.)