HN user
Arity explanation: https://en.wikipedia.org/wiki/Arity
From the blurb you quoted, it sounds like Lua doesn't check function argument arity natively, and fennel can. This means that fennel applies a runtime check to validate if a function was called with an expected arity, and if not, propagates an error (however Lua does that, I do not know), hence why arity checked functions are not as performant.
Your point about underlying data structures is spot on, in my view.
Last quip to reflect on. "What's true of every bug found in the field? ... It passed the type checker. ... It passed all the tests. Okay. So now what do you do? Right? I think we're in this world I'd like to call guardrail programming. Right? It's really sad. We're like: I can make change because I have tests. Who does that? Who drives their car around banging against the guardrail saying, "Whoa! I'm glad I've got these guardrails because I'd never make it to the show on time."
I've been avoiding bringing up this point/example, but this is what prompted me to start thinking more deeply about types and their tradeoffs. Great talk, IMO.
Are you familiar with the idea of "making illegal states unrepresentable", and "parse, don't validate"?
I haven't heard of those concepts/ideas before. Thanks for linking the article to define those concepts. With your example, and the article mentioning that "parsing should take place at the boundaries" (paraphrase), I can see how types (a la ML families) can be defined and composed give internal coherence once an external input has been parsed and hence validated.
Really interesting approach which I haven't considered before!
I wouldn't say it's "extreme", it's very normal and natural. You just stick everything in the types and it works.
Ah, then I seem to be missing the point/intention. Thanks for illuminating that it should feel "natural". I think I need to spend more time with ML/Haskell families.
... the vast majority of the time you can construct your types in ways that force your logic to be correct because you just don't offer the ability to do the wrong thing
I think that is where I haven't had experience, nor much exposure to, when it comes to "static typing" in the true sense/intention of making a program correct. More so (which I think I loosely alluded to), is that the type system was being used to "model objects in the real world".
what kind of logic errors are you seeing that you think wouldn't be eliminated by using types?
Classic "logic" stuff. Forgetting to modify and return a map given some other information. Accidentally returning the inverse of a boolean (i.e. !isSomething(x) vs isSomething(x)), incorrect adds or bit shifts, concurrent access to shared data structures (shared memory may be a more apt term), reconciling two different pieces of data into a shared one, algorithmic implementations (though I think you touched on this being less likely when using a type system designed to encourage correct algorithms by applying type theory, so it may be moot).
To maybe give some clarity to what I mean by correctness, I mean does the program match the expected behavior of the programmer. In playing around with F#, I've written buggy F#, but the types all matched up. I had a guarantee that my program would run in a non-faulty manner (bar any system fault), but the program was not correct.
and found types to be very effective
I'm very curious where you've seen this be very effective (if you're able to share), and with what language/technology.
---
Also, as a last quip, I am enjoying learning about your perspective with type systems. There are some points you have brought up which have caused me to think harder and in more depth about the concept and it's application, and want to voice that I appreciate you putting in the time to have this exchange. Want to this up before I forget, since it is getting late in my neck of the woods.
Types validate whatever you use them to validate, which can certainly include what we usually call "logic".
I'd love an example of this! I concede that I could be wrong on the point's of ML/Haskell families, however, it relies on the practitioner correctly using the type system to the extreme (at least, that is my impression). C++ and other similar OO's, the type system isn't as compelling as a correctness measure.
On the contrary, they're still the most effective technique we've found for improving program correctness
In which domain are you working in where this has been the case? It may be my experience, but types as I have seen them used in industry have been more as "data containers with some behaviors".
I'd appreciate some examples of where you think I may be getting types wrong or missing the point.
In OO languages (Java, C#, C++, etc...), and functional ones (F#, Haskell, OCaml, etc...) types do not validate the correctness of logic, they evaluate the correctness of data structures and their access/mutation as they are manifested in the language.
OO languages consider data correctness as access patterns of encapsulated primitives (or other data structures) through defined behaviors on a "class".
Functional languages consider data correctness as access patterns which preserve previous version of data which a caller may still need to reference, or another part of the system references. Functional languages (in most cases) disallow direct mutation without some sort of immutability or persistence.
Types have little (or nothing) to do with program correctness, or data correctness as it relates to external storage engines and their concurrency guarantees (i.e. FoundationDB, PostgreSQL, MySQL, etc...).
Therefore, in this scenario, what matter's most is the correctness of underlying storage (including the rigor of validating expected behavior) and the event sourcing/messaging systems, not on the internal data structures and their idioms conveyed by the language.
polylith ftw.
Been learning some of the idioms of a polylith architecture using the `poly` tool + clojure. Really enjoying the idioms/practices it encourages.
This is cool! Small and no magic.
cough azure...
To the OP (if you read this), I appreciate your candor, and you're not alone. Heal well. Heal with your family and loved ones. Lean into them. I sincerely hope you move onto greener pastures.
its basically doing a react-ish way of UI changes without a full page reload (which thymeleaf would have done).
Interesting, I missed that in my scan of the thymeleaf docs. I haven't used that library at all (and tend to shy away from Java land in general, unless it's Clojure).
And for my purposes, yes. I may be missing the point of the library, but that is how I've tended to use it.
so what happens if i click something that needs to go to another "page"? do you "swap" the html out with the html of the other page ? or do you trigger a full page reload. For SEO reasons, im kinda putting the requirement that every interaction must have a unique url
I'd say pick your poison. You could go either route and it would most likely be roughly the same code.
No worries, good questions!
Taking clojure out of the equation and only looking at htmx, I would say it buys you is simplicity, and for most use cases that is the difference between a shipped thing and a dead one (thing in this case is project, product, etc...). Granted, htmx isn't a silver bullet, as you have to learn some of the idioms of the library. But it may be worth it to some (it is to me), to not have to bring in an entire JS toolchain to get a thing bootstrapped.
im not able to figure out what is it that htmx is saving you in the example above. with clojurescript, wouldnt you have written very similar code ? i mean all you are doing is calling an api. is it automatically doing conversion of JSON to ur DTO/business object. that cant be right can it ?
It can kind of be what you need it to be (if I am interpreting the API provided by htmx correctly). The way I have been using it is to partially update my DOM based on some user interaction (either a POST, PUT, DELETE), by returning html. This makes updates html -> html vs json -> frontend framework -> html.
As far as ClojureScript code, the above example would resemble the equivalent ClojureScript code almost 100% (with some slight differences). The example above was a little contrived, in that it is so simple. However, if you think about a larger use case (i.e. 100's of elements need to be rendered from a db), it doesn't become contrived.
With a Clojure backend + htmx, all I do is write my business logic, define my html via hiccup (Clojure vectors w/ a convention similar to html) and return the html to the client, which I can ship without needing to coordinate different pieces. In addition, the hiccup I hopefully defined is broken up into functions that'll allow me to partially update the DOM for different user CRUD operations.
With a Clojure backend + ClojureScript SPA, its the same-ish business logic on the backend to return results from a JSON API, some more logic on the front end to validate said JSON, some additional logic to add said data to a global store, then finally my view can update. Then in order to get you're app out there, you'll need to figure how to get you're application deployed. There has been a lot of work in ClojureScript land as far a build/packaging tools, but they can still be rough around the edges, which results in headaches sometimes between dev/prod. After you've gone through that and put your app in an S3 bucket/object store (for the sake of example), you'll need to get your API deployed (which should be same steps as above backend + htmx).
So while it may seem the same, there is a lot more complexity that comes with ClojureScript SPA.
Also, as a final thought for this section, even if you went with vanilla ClojureScript + html, you won't get much for free. You still need to compile your ClojureScript, which still requires DOM API's, which you'll still need to call from ClojureScript to handle updating the DOM from the ClojureScript which still needs to call AJAX/fetch, which still needs to resolve promises in order to get your JSON data (or html data), which still needs to translate your interchange format (in this instance JSON) to html. At this point, are the layers of abstraction worth it?
my mind is telling me that it is some kind of lifecycle management - like before/after hooks. make sure that the html loads after server is loaded, etc. is that what it is ?
Sort of. I like to think of htmx as filling the role of sync-ing my web view/page/app with backend state without all the ceremony and fuss of a frontend framework. I can handle all the logic and UI definition on the server and defer http requests (GET, POST, PUT, PATCH, DELETE) and DOM patching to htmx. Kind of like how a user of a frontend framework defers that same patching to the underlying virtual dom implementation.
Personally, when I first saw htmx I thought "well... that doesn't seem useful. I can get a React (or Vue, or Solid, or Svelte, or X) spun up w/ a cli command and do all my things there. But then I used it and couldn't have been more wrong on its usefulness. I encourage you to play around with htmx, try implementing the counter example in your preferred language, see if you come to the same conclusion you had previously.
There are cases where a SPA is appropriate and merits the investment, but I think they should be the exception not the rule, due to the complexity brought about by a frontend framework.
In conclusion, I hope I answered your questions. I am happy to continue this discourse if you still want to chat about it. At the end of the day though, all we're trying to do is render web pages, so do whatever makes sense to you to accomplish that.
Thanks for calling out some gaps in my explanation! Appreciate your perspective :)
After a quick glance, it seems like htmx would complement thymeleaf, if the web page/app you're writing doesn't need any sort of eager client (eager as in, treat and interaction with a remote service as "successful" and resolve the error in the background somehow).
W/ htmx + clojure, you can define your ui like so:
(def counter (atom 0))
(defn partial-count-markup [c]
[:span (str "Pressed: " c)])
; Handler for /partial/count
(defn partial-count []
(swap! counter inc)
(partial-count-markup @counter))
; Handler for index.html
(defn handler []
[:button {:hx-put "/partial/count" :hx-swap "innerHtml"}
(partial-count-markup @counter)])
Also if it isn't clear, you can also keep all your markup as Clojure data structures, which means you can write an `html` function which has the common styles/scripts/etc.. necessary so you get a ton of re-use with an already similar syntax vs needing to learn a new templating syntax w/ its own conventions.
W/ clojurescript, to get the same behavior you need:
- clojurescript toolchain w/ some configuration of how you'll bundle/package it
- an idea of how you'll distribute your application (serve spa from same API service? S3/Object store? another web service? How to reconcile state?)
- an idea of how you'll reconcile state between local/server, if you want to go that route. If only local, nbd. If server, you add a handler and fetch data once SPA or cljs has loaded.
- and idea of what format you want to consume (JSON, HTML, XML,text) and then write the translation between that format and your markup.I hope the above answers your question, or at the very least offers another perspective.
As a quick postscript, I think it is underestimated how convoluted templates/templating engines are, given they have the tendency to implement their own language/semantics outside of the PL you're using. I have much respect for the authors of template engines/spec, the engineering that goes into them is impressive, however, most I have come across tend to be a leaky abstraction. Once I experienced writing markup as Clojure data structures, it ruined me for templates permanently. I don't want to go back to writing templates, and doing an assessment of "what language does this template engine implement, and is it simple/easy to learn?" is an exercise I do not miss.
Note: I've been Clojure/ClojureScript developing professionally for almost two years now and have debated most of the above internally during that time. Done some templating w/ JS, Go.
I will say, the :advanced flag for the closure compiler has caused us some real headaches in production, enough to where we needed to migrate to only the :simple flag.
The reason being, is we needed to do some code gen of Svg components in React Native, and in the build process (via shadow-cljs), the closure compiler was munging the definitions in the.
Off the top of my head an svgr component which looked like: // generated component import React from 'react'
function SomeSvg(props) { return React.createElement(..., ...merged props..., ...children...) }
was getting "optimized" to be used as: function $SomeSvg(props) { return $R.$c($$..., $$...merged props..., $$...children...) }
The above is psuedo-ish code, but I think covers the point. There were also some edge cases where not includeing a ^js reader macro before using js values caused crashes, due to the symbol being munged in the background. As a result, whenever we used any sort of js, we needed to mark it w/ a ^js reader macro, which began to get really noisey and error prone if you forgot. :simple has made the code based more stable. Could be user error on our end, but the fact that we ran into so much with :advanced and our application stabilized significantly after that one configuration change, it makes me think using :advanced can be too involved.
In addition (to an already winded comment), cljs needs to include the cljs runtime. I haven't benched the size, but it is no negligible (think in the 100's of KB), on top of what react/reagent/re-frame may bring in, you can easily end up w/ a compiled cljs app of > 1MB.
Yes!
I'd say it's more complementary, from my experience. Alpine serves the purpose of local state and rendering logic for user interaction in a manner similar to a SPA, whereas htmx services integrating w/ your backend service and handling DOM patching for updates/data oriented interactive bits.
Doing something similar with janet. Really does simplify so much, and being able to not have to worry about always translating json -> html via { insert SPA framework here } is a breath of fresh air.
There’s nothing close to chasing a toddler in a circle for an hour.
amen
legend
Just bought one, and it is a great piece of kit. It is limited in a very intentional and intuitive way.
Only downside is the screen can be inaccurate at time, but that is a small thing which doesn't detract from its usefulness.
+1
Bartosz, you're a legend! Thank you for these amazing articles!!
I thought I was the only one...
To answer point 1: Maybe to start out, but in the long run, having only social logins may cause your app to lose a segment of the market (I don't know how much). If you're fine with that, then by all means only support social logins.
However, I strongly suggest having it (or some way for someone not to use a social provider) if you want to have as many users a possible.
Personally, I don't have a google account, I'm wary to use my Apple account for non-Apple sites, and I don't have facebook, instagram, new gen z hotness app, etc... And I can confidently say I am not alone in choosing to use apps which don't require a social login.
At the end of the day though, password auth isn't a non-trivial problem. It is a solved problem of which there are numerous articles/papers and many libraries for most languages/frameworks. For example, the Phoenix framework for Elixir has a built in command which scaffolds auth, and it works really well (I have used it in a personal project): https://hexdocs.pm/phoenix/mix_phx_gen_auth.html. For JS, you can use something like passport: https://www.passportjs.org/packages/passport-local/. If you want a separate service entirely (even though it would be more complex to have a separate service to start out), there is GoTrue: https://github.com/netlify/gotrue. These are just a few suggestions of tech I have come across. There is so much more out there, I encourage you to research options to see what may be a best fit.
If you're worried about password auth, maybe give one time passwords a try. They don't require any password reset flow, and are generally secure when implemented correctly. As an example, I don't have a password for my craigslist account. Every time I want to login, I can choose to get a magic link/otp which gets exchanged for a session. In practice (and this is my personal opinion), I prefer magic links. They are one time, hard to guess (again dependent on implementation), can be time limited, and most likely won't be intercepted in transit (though it could be in a rare circumstance).
---
To answer point 2: yes.
If your app is to order things (I use things in a general term) it sounds like eCommerce. And if you're in eCommerce, you better have a way for a user to track what they have ordered and how much they have paid for it at a minimum. Otherwise, your site may come across as a scam, even though it uses Stripe. Sketchy sites can use Stripe to get your money (albeit, it'll be a one time payment).
---
In conclusion, auth for your application seems crucial. Email/password auth is still relevant for applications. While not necessary for an MVP, there is a segment of the market you will lose if you don't have an email/password option, or even an email/OTP/magic link option (I don't know how much, really going off an educated guess).
Best of wishes in building your app! I genuinely hope it is successful and safe for people to leverage :)
--- Edit 1: You may not need auth after all.
After thinking a bit more about some UX from different ordering services (i.e. airlines, doordash). Maybe a way to circumvent is to send that order number w/ an order summary via email, which of course you have stored in your db. You may still need to store an email (depending on the complexity of an order number), but it wouldn't require a full on auth solution to start out with.
It would make my points above moot, and may be lowest friction way for you to get your app off the ground while still giving a user the ability to have access to their orders/order history.
This is really well designed!
The only bit of feedback which can potentially give a better first time player is a small tutorial on what/how to click.
Great work, and thanks for sharing :)
Cool stuff on there, Yury!
Nothing there, haven't posted in ~a year. Kids will do that to you.