wibblewobble124

if you’ve been writing HTML since 1999 like me then it’s newfangled. in 2008 when i got my first paid job writing ASP and PHP at a web dev shop, nobody was “frontend”. there was the content person, the designer (photoshop wiz), the builder (convert design into HTML) and the dev. we still had to support IE6 or our manager would yell at us. i wrote my first SPA at work in 2011, and that was radical—everyone thought it was a bad idea. some people thought backbone.js might be a cool approach. took ages for react to appear.

took until maybe 2015 before i remember seeing any job ads of “frontend” positions, it takes a while before a job market develops around a technology.

i didn’t say it was pointless. i said the stratification of “dev” into “frontend dev” and “backend dev” is newfangled and arbitrary. you could also split devs into other classes (DB only, CSS only, etc.).

it is funny when people who don’t know you accuse you of incompetence because you don’t like their tools or methods. dogmatic. i prefer some other tools and methods and i am delivering value to customers. pragmatic.

this is a shallow and dismissive comment lacking any basic charity or nuance: dijkstra was just bad at “goto.”

this doesn’t worry me, though. those in the react crowd that insist on this arbitrary and newfangled “frontend/backend” stratification and are dogmatic about it are by definition going to stick with what they know and won’t come and bother us who choose tools based on real experience and their practical merits. better off they make themselves easy to spot from a distance.

we’re using htmx at work, migrating away from react. the technique we’re using is just rendering the whole page, e.g. we have a page where one side of the screen is a big form and the other side is a view on the same data but with a different UI, updating one updates the other. we’re using the morphdom swapping mode so only the things that changed are updated in-place. as a colleague commented after implementing this page, it was pretty much like react as far as “pure function of state.”

our policy is that for widgets that are like browser components e.g. search as you type with keyboard shortcuts, we just use the off the shelf react component for that purpose and use it from htmx like it’a browser input element. for all other business logic (almost all of which has no low latency requirements and almost always involves a server requets), we use htmx in our server side language of choice.

our designer who knows a bit of react is not happy, but the 12 engineers on our team who are experts in $backend_lang and who are tired of debugging react race conditions, cache errors, TypeScript front end exceptions, js library churn, serialisation bugs, etc. are very happy indeed.

it doesn’t fit every app, but it fits our app like a glove and many others that I’ve considered writing that I didn’t feel like bothering to do so before discovering htmx.

we’re using htmx at work, migrating away from react. the technique we’re using is just rendering the whole page, e.g. we have a page where one side of the screen is a big form and the other side is a view on the same data but with a different UI, updating one updates the other. we’re using the morphdom swapping mode so only the things that changed are updated in-place. as a colleague commented after implementing this page, it was pretty much like react as far as “pure function of state.”

I think if something is intuitive after 5 years then it wasn’t intuitive, you’ve just adapted.

TS has terrible type inference. At work I collect a list of the failures.

It’s not a difficult part if you already have a powerful web framework. We’re using Htmx with Servant which has type-safe URLs built in. For the targets, automatic name generation is fine.

I prefer the unopinionated, language agnostic simplicity of htmx, just like HTML, over more tightly bound language specific frameworks. It provides a vocabulary that will translate across backend languages and probably endure over competitor frameworks.

SQL is not functional. But otherwise I support the desire for an FP and relational language.

Scheme also abbreviates:

call-with-current-continuation

To

call/cc

The forward slash serving the purpose of “with”.

Human and animals interaction is all physical. Babies and early children spend most of their brain development on physicality. By depriving a mind of having a body, that mind cannot have empathy for the human condition or animals, the idea of living in a body will only be abstract. Have you seen the movie Johnny Got His Gun? It’s one big statement that being disembodied is hell.