wibblewobble124 (u/wibblewobble124)

wibblewobble124 commented on Htmx Is the Future quii.dev/HTMX_is_the_Futu... · Posted by u/quii

"Frontend/backend" is neither new nor pointless. The people who pretend they are are usually backenders who are under the false impression that frontend is simple.

wibblewobble124 · 3 years ago

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.

wibblewobble124 commented on Htmx Is the Future quii.dev/HTMX_is_the_Futu... · Posted by u/quii

robertoandred · 3 years ago

Sounds like your backend devs are just bad at frontend.

wibblewobble124 · 3 years ago

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.

wibblewobble124 commented on Htmx Is the Future quii.dev/HTMX_is_the_Futu... · Posted by u/quii

wibblewobble124 · 3 years ago

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.

wibblewobble124 commented on Htmx Is the Future quii.dev/HTMX_is_the_Futu... · Posted by u/quii

dfabulich · 3 years ago

People were making this prediction ten years ago. It was wrong then, and it's wrong now.

This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side.

But Turbolinks is more than ten years old. React was born and rose to popularity during the age of Turbolinks. Turbolinks has already lost the war against React.

The biggest problem with Turbolinks/Htmx is that there's no good story for what happens when one component in a tree needs to update another component in the tree. (Especially if it's a "second cousin" component, where your parent component's parent component has subcomponents you want to update.)

EDIT: I know about multi-swap. https://htmx.org/extensions/multi-swap/ It's not good, because the onus is on the developer to compute which components to swap, on the server side, but the state you need is usually on the client. If you need multi-swap, you'll find it orders of magnitude easier to switch to a framework where the UI is a pure function of client-side state, like React or Svelte.

Furthermore, in Turbolinks/Htmx, it's impossible to implement "optimistic UI," where the user creates a TODO item on the client side and posts the data back to the server in the background. This means that the user always has to wait for a server round trip to create a TODO item, hurting the user experience. It's unacceptable on mobile web in particular.

When predicting the future, I always look to the State of JS survey https://2022.stateofjs.com/en-US/libraries/front-end-framewo... which asks participants which frameworks they've heard of, which ones they want to learn, which ones they're using, and, of the framework(s) they're using, whether they would use it again. This breaks down into Awareness, Usage, Interest, and Retention.

React is looking great on Usage, and still pretty good on Retention. Solid and Svelte are the upstarts, with low usage but very high interest and retention. Htmx doesn't even hit the charts.

The near future is React. The further future might be Svelte or Solid. The future is not Htmx.

wibblewobble124 · 3 years ago

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.”

wibblewobble124 commented on Thoughts on Svelte tyhopp.com/notes/thoughts... · Posted by u/naansequitur

pavish · 3 years ago

I agree with most of what the author says, except the part about reactivity. I attribute that sentiment to the author being less familiar with Svelte.

I do think that people new to Svelte find it hard. It takes a while to understand how the `$` reactive statements work, and when and when-not to use it. When I first started working with Svelte, I tried to do things the React way and shared similar frustrations. Now that I've been working with Svelte for smaller and bigger projects for nearly 5 years (yes, since 2.0), I find Svelte's reactive pattern simple and intuitive.

There are some aspects I find frustrating with Svelte. One example is being able to pass templates around. With React I'd just pass JSX, but since Svelte is statically compiled, I've had to create components for such scenarios. Slots don't cover all usecases. I can live with this though.

I have built a couple large projects using Svelte and haven't faced issues with scaling. I found Svelte to be quite flexible, which has enabled me to build fast, and maintain a performant codebase.

My recent project is Mathesar, which has a large frontend codebase in Svelte + Typescript [1]. It's also open-source so you can check out the codebase. We use pretty much all of Svelte's features and we even implemented a full component library. Here's an old discussion for deciding which frontend library to use for Mathesar, where we selected Svelte [2].

We have had to establish a number of patterns (including around reactivity) so that new contributors don't break things, which happens more often than you think.

Svelte's primary issue is a lack of established patterns, which makes it easy for new Svelte developers to get things wrong. React has a number of such patterns due to it's massive community. I believe as Svelte's community keeps growing and more projects choosing Svelte, this would be tackled.

[1]: https://github.com/centerofci/mathesar [2]: https://github.com/centerofci/mathesar/discussions/55

wibblewobble124 · 3 years ago

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

wibblewobble124 commented on <3 Deno matklad.github.io/2023/02... · Posted by u/scraptor

obblekk · 3 years ago

Interesting to see a different side to the benefits of Deno.

Personally, I find direct Typescript interpretation to be one of the best features. Typescript is not necessarily a simple type system, but it is an expressive one:

- It has great type inference avoiding Java style codespam

- It has gradual typing, enabling "risky" type casts

- It has fully functional types, enabling the productivity and readability improvements from functions as data

- It is 10 seconds away from having dependent types

Typescript took most of the best programming language research from the past 20 years and popularized it in a way that actually makes js hackers more productive without getting too much in the way.

The only hard thing has been that js interpreters don't understand typescript, requiring an awkward transpilation step with weird symlinks and other hidden complexity that works 99% of the time, but wastes a lot of time when it doesn't work just right.

If Deno could just solve that, it would be a great improvement. If it's also faster (as claimed) that's even better. This article shows a lot of other ways in which small, simple improvements add up to a much better product.

Can't wait until it's production ready.

wibblewobble124 · 3 years ago

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

wibblewobble124 commented on The future (and the past) of the web is server side rendering deno.com/blog/the-future-... · Posted by u/lambtron

mal-2 · 3 years ago

htmx glosses over the difficult part, which would be keeping track of the relationship between all these hx-post and hx-target attributes, when they're all just strings in markup. That glossing over is why you don't see any well-established backend libraries on the server integrations page. (https://htmx.org/server-examples/)

Elixir solves this in a much smarter way, because the bindings to reactive values can be validated at compile time, inside the HEEx templates. It's all located together, but you still get the diff passing behavior. (https://hexdocs.pm/phoenix_live_view/assigns-eex.html)

wibblewobble124 · 3 years ago

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.

wibblewobble124 commented on What’s so great about functional programming anyway? jrsinclair.com/articles/2... · Posted by u/redbell

bob1029 · 3 years ago

FP is only part of the equation when working with meaningfully-complex systems. Having a clear data + relational model is the other big part.

I would strongly recommend reviewing the functional-relational programming model described in this paper - http://curtclifton.net/papers/MoseleyMarks06a.pdf

The overall theme goes something like: FP is for handling all your logic, and RP is for arranging all of your data. Some sort of relational programming model is the only way to practically represent a domain with high dimensionality.

For real-world applications, we asked ourselves: "Which programming paradigm already exhibits attributes of both FP and RP?" The most obvious answer we arrived at is SQL. Today, we use SQL as a FRP language for configuring our product. 100% of the domain logic is defined as SQL queries. 100% of the domain data lives in the database. The database is scoped per unit of work/session, so there are strong guarantees of determinism throughout.

Writing domain logic in SQL is paradise. Our tables are intentionally kept small, so we never have to worry about performance & indexing. CTEs and such are encouraged to make queries as human-friendly as possible. Some of our most incredibly complex procedural code areas were replaced with not even 500 characters worth of SQL text that a domain expert can directly understand.

wibblewobble124 · 3 years ago

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

wibblewobble124 commented on Common Lisp Wiki: Naming Conventions cliki.net/naming+conventi... · Posted by u/susam

wibblewobble124 · 4 years ago

Scheme also abbreviates:

call-with-current-continuation

To

call/cc

The forward slash serving the purpose of “with”.

wibblewobble124 commented on John Carmack's new AGI company, Keen Technologies, has raised a $20M round twitter.com/ID_AA_Carmack... · Posted by u/jasondavies

imposter · 4 years ago

What's the difference between moving around and picking up a document, to say hitting an API endpoint to fetch the content of the same document?

wibblewobble124 · 4 years ago

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.