How I suck at javascript and how I managed to avoid it as much as possible.

or How can a lonely backend developer survive in the ever changing landscape of frontend tooling ?

I have been writing code since I’m 10 years old. At that time (late 80’s) all I had was a pocket calculator with some obscure basic language full of line numbers and goto’s. After that, Turbo Pascal, then Delphi, then Php, then Python with Zope (who knows Zope nowadays?) then back to PHP for the ease of hosting anywhere (I made my own cms like everyone at that time) then added Drupal to the stack, then Laravel for the real enlightenment (and back to python and C for hardware stuff on raspberry and arduino). But enough about my programmer’s path, this was just to say I’m not against learning new stuff :-)

Why do I suck at JS ? Biased arguments follow :

• Debugging in the browser is painful for me, I never know which file and line number is giving me problems. Or is it because some npm installed package dependency broke it all? Or is it because I’m too old for this sh*** ?

• I always fear doing a npm update (even installs sometimes give problems if you don’t have the correct npm version), I understand that’s because I don’t use it enough, but I told you I’m biased.

• I really dislike closures because I don’t fully understand the syntax and it looks ugly to my eyes.

• I can’t fully wrap my head around the concept of promises.
  Async programming is not my cup of tea either.

• I probably dislike the node run model but I don’t even know for sure, it’s too obscure.

• I love the backend. I love PHP.

A few years ago, I started a project called “Agorakit”, it’s a groupware (communication & organization tool) for citizen collectives. It is developed/maintained mainly by one (me) but used by thousands of users on several instances. It is open source and available at https://github.com/agorakit/agorakit (feel free to star it or dare I ask, contribute :-)). You can test a live instance on https://app.agorakit.org

In this world of ever changing frontend tooling, one might be tempted to use the latest and greatest stack. Speaking of stack, I’m not sure it’s really possible to be a “full stack developer” : I feel this is overrated and you can’t be a jack of all trades, but when you work almost alone on a project, you need to touch a lot of areas including user support, feature prioritization, mobile support, security, ease of use, etc. I really can’t be a jack of all trades.

For frontend work I still needed to find a way to provide the kind of user experience javascript allows, and at some point, since this is not my job (Agorakit is a side project), I choose to limit my scope to Laravel, and needed a way to avoid “feature creep” my brain if this is a word. Javascript would not play a big part of this strategy.

How can a lonely backend developer survive in the ever changing landscape of frontend tooling ?

With all this said, Vue, React, SPA’s, even trusty Jquery or new Alpine are out of reach for my quest of simplicity (and my love for the backend).

One of the emerging solutions is to rely on third party tools that hide complexity (but are themselves very complex) : Livewire is one example. I like the fact that it does a lot for me, but I also don’t like the fact that it does so much because then I rely on a big stack I don’t fully understand and when something fails you get to dig deep down to fix the bug. Back to Zope days it was the same problem : smart abstractions, but when they leak, they break badly, and you are on your own to fix the monster you just created.

Since I’d prefer to keep the complexity low and not rely on a (imho) very specific toolset, I decided to go the opposite way : HATEOAS

HATEOAS is HTML over the wire (or more properly “Hypermedia as the Engine of Application State”).
It is advocated by htmx, turbolinks (now hotwire/turbo). The idea is that you send html to the client and the client can directly use it, no need for complex json->html transform on the client using javascript. Html after all is a structured language that can be used, queried, injected, transformed if needed and finally rendered by the browser.

HTMX is a big proponent of this method, although it’s not strictly progressive app enhancement (you can’t remove it once you use it).

But there is another hidden gem which is my secret weapon : Unpoly JS.

Unpoly JS takes that philosophy one step further :

• you create your server rendered html application as usual including links, forms, navigation, etc.
• When everything works “old style”, you just add a few html attributes to links and forms to magically, progressively transform your web application to a lookalike single page app.
• At any point you can even remove unpoly from your tooling, your app will still work!
• Dare I say your app will still work with javascript disabled in the browser? (except for those js libs you use for fancy calendars, maps, dropdowns...)
• your testing toolkit does not even need to be JS aware for testing forms and links since your app does not rely on them. This means you can use a fast testing framework (no need to spin a complete headless browser for testing the app)
• This is what I call progressive app-feeling enhancement. OR progressive spa-fication of a server rendered app.
• You can optimize your backend to return only the html part that will be updated, unpoly will take care of parsing the html and inserting it in the page. Since “premature optimization is the root of all evils”, and since this is mostly needed for write operations (that are much less frequent), I almost never optimize the code.

Here is a small commit on Agorakit that enhances a classic server-side search page to a lovely, as you type, search page : https://github.com/agorakit/agorakit/commit/0247f0c760dad2ccd27fb49aff60b615260f35b6#diff-c7eb4cf5ffcca2f641738388b14862d88e6f02ab38805afc957d9f4ad27fb1f6

Test it live here : https://app.agorakit.org/groups

Notice how only a few attributes are needed to make it work flawlessly. What those snippets do :

• up-autosubmit allows the form to be auto submitted on user change
• up-delay defines the delay to wait after keypresses to avoid overloading the server
• up-target defines which part of the page must be updated
• up-reveal=”false” disables scrolling to the updated part of the page.

Unpoly recently released V2 of the library, I didn’t upgrade yet, but it seems quite easy to do and will provide very nice “infinite layers” support (create a company while creating a project kind of interactions).

While this strategy will not work for all projects, in my specific case it really pays.

Check out the git commits I mentioned, try Unpoly on your next project, trust the HTML, this might be the new-old way of the future.

Originally published on my almost never updated blog (but I’m willing to write more articles like that if I get feedback) at https://123piano.com