- Can someone who's adapted HTMX for a larger app report about front-end-server costs?
HTMX serves fully baked HTML that needs to be created on the back-end (or front-end-facing servers)
That is more processing than sending the raw data to the front-end and baking the HTML there.
It is also more bandwidth (unless the JSON is more verbose than the HTML generated).
Lastly, I can generate different HTML fragments on the front-end from the same client-side state with the data only being transported once. How is that working out?
- AI - as a discipline - has been around forever (1956), essentially since the birth of Lisp - both with staggering successes as well as spectacular failures that ushered in 2(3?) so-called AI winters.
The author probably just means LLMs. And that's really all you need to know about the quality of this article.
- One could get the impression that the only really really important non-functional requirement for such a thing is to absolutely ensure that you can only call the "good" functions with the "good" payload.
- Know the consumer of your API.
If that is just your team, use whatever tech gets you there quick.
However, if you need to provide some guarantees to a second or third party with your API, embrace standards like JSON, even better, use content negotiation.
- This is the first wave of a new generation of Apps which has the potential to replace/enhance the majority of e-commerce websites.
I wouldn't underestimate it - it's the hammer can break up the information silos we've built up around websites/apps.
Why prompt Gertrude(tm) on Ramazon for a specific thing you need, if you can ask ChatGPT to find you said thing along with UIs to purchase it across all e-commerce platforms that agree to play in this market?
- when PayPal tells you that they already know you and don't require you to log in: that's fingerprint.com behind the scenes.
There are pros/cons.
It should be obvious by now that using any free service of scale is being paid for by your interactions which are made more valuable through fingerprinting.
Trying to circumvent that just makes it more expensive for the rest of us.
- The Clojure (or any Lisp) journey is very different, not because of the language per se, but because of the developer experience.
In Clojure, there's no appreciable compilation time. During my work week I barely, if ever, restart the application I'm working on: I'm working inside of it via a REPL connection.
It's an entirely different ball game and if you just compare language features you are missing out on an incredible interactive coding experience.
- > 60.7%
Why would anyone trust the output of an LLM, if it is barely better than guessing and much much worse than humans?
GPT-5 shows more impressive numbers, but for that particular task, the precision should be 100% - always. No matter how large the data set is or in which format. Why are we doing this?
- TLDR; Use regex if you can treat XML/HTML as a string and get away with it.
- Can I finally redo the Star Wars sequels with this? :)
- If you opt for non-human-readable wire-formats it better be because of very important reasons. Something about measuring performance and operational costs.
If you need to exchange data with other systems that you don't control, a simple format like JSON is vastly superior. You are restricted to handing over tree-like structures. That is a good thing as your consumers will have no problems reading tree-like structures.
It also makes it very simple for each consumer/producer to coerce this data into structs or objects as they please and that make sense to their usage of the data.
You have to validate the data anyhow (you do validate data received by the outside world, do you?), so throwing in coercing is honestly the smallest of your problems.
You only need to touch your data coercion if someone decides to send you data in a different shape. For tree-like structures it is simple to add new things and stay backwards compatible.
Adding a spec on top of your data shapes that can potentially help consumers generate client code is a cherry on top of it and an orthogonal concern.
Making as little assumptions as possible how your consumers deal with your data is a Good Thing(tm) that enabled such useful(still?) things as the WWW.
- You can get basically all variations of async coding with Clojure a la carte.
- They are hallucinating word finding algorithms.
They are not "empathetic". There isn't even a "they".
We need to do better educating people about what a chatbot is and isn't and what data was used to train it.
The real danger of LLMs is not that they secretly take over the world.
The danger is that people think they are conscious beings.
- It is tempting, maybe a good first step, but often not expressive enough.
Especially and particularly attributes/fields/properties in an enterprise solution.
You want to associate various metadata - including at runtime - with a _value_ and use that as attribute/field/property in a container.
You want to be able to transport and combine these values in different ways, especially if your business domain is subject to many changes.
If you are tempted to use "classes" for this, you will sign up for significant pain later down the road.
- You need a REPL to truly read Clojure code. Could be a weakness or could be a strength. In my day to day work I consider a strength since I’m working at the REPL the whole day anyways
- I always urge software architects (are they still around?) and senior engineers in charge of APIs to think very carefully about the consumers of the API.
If the only consumer is your own UI, you should use a much more integrated RPC style that helps you be fast. Forget about OpenAPI etc: Use a tool or library that makes it dead simple to provide data the UI needs.
If you have a consumer outside your organization: a RESTish API it is.
If your consumer is supposed to be generic and can "discover" your API, RESTful is the way to go.
But no one writes generic ones anymore. We already have the ultimate one: the browser.
- I think that's a prime example showing that token prediction simply isn't good enough for correctness. It never will be. LLMs are not designed to reason about code.
- I wish people would be a little bit more precise.
There is no type safety.
There must be data validation on the endpoint but anyone can send anything and if you rely on your front-end to send you the right data shapes and valid values without checking, you are in deep trouble.
Using a schema/spec/type library at runtime that is even more powerful than ADTs is a better investment - or to be less controversial - is an additional investment on top of types.
Yes, it means the compiler can't help you as much, but who has time waiting for a compiler anyways ;)
I find the "make illegal state unrepresentable via types" idea great for software that needs to fly a plane, but for enterprise software not so much. The cost/benefit is not justifiable.