can3p

I think build systems are a very big reason for the mess javascript is in nowadays.

- Typescript is very light from the code transformation point of view. If anyone remembers the output of babel especially for async/await + the way module imports are implemented generates a really hard to read code and the "best practices" about hiding the state make things a lot harder. Just think about the fact that back in the days (tm) it was common to inspect the state of the app and change it full lisp style and now the js console can mostly be used for quick code tests and looking around when execution is stopped at breakpoint and you can't see that much anyway because of how the code is generated. - The whole babel thing still feels like a madness to me. Yeah, you're getting some new language features but for the price of non obvious code transformation that makes you need source maps (and you need to make them work and maintain that) and all the rest - Build step + npm results in on controlled bloat of the js bundle. `npm install <random-component>` may inflate you bundle by 500kb easily - And with all that there is still a quite big trouble with requiring necessary modules for the use on frontend. Just think that there is still no simple way to require all css provided by a library from npm

Another big problem on my opinion is the propagation of "write once/use everywhere" approach. It works sometimes yeah, but you need to sell your soul for that: you'll have to use something like next.js and that implies that you're bound to use node.js and then you either do all your development in node or have another service doing stuff in the language of your choice and then have a node service as a templating layer and then you need containers and orchestration and so on which makes it a technically challenging project for something that almost for sure can be done in some trivial set of technologies if this requirement had been dropped.

One could argue that we need a different approach with libraries that acknowledges that frontend is distinct world and aims to provide ready made components specifically for the web with an easy setup and no/minimal dependencies. Maybe even with a vendor folder like approach, since the won't be too much code anyway. That should be enough for 99.999% of projects and the rest can use the full scale approach and embrace complexity if they really need it.

Great news! I'm not using the full feature set (e.g. hyperscript) but really like the general approach as opposed to usual suspects like react or svelte. One of my last projects runs just fine on htmx + 3-4 stimulusjs controllers for all interactivity

Is it considered a stable version? The amount of unnecessary breaking changes is really frightening.

I mean, why would one ever need to change standard module names or demo.json structure?

Maybe it looks a bit better, but I’m sure it invokes a lot more pain for all developers, who need to watch out carefully with every release.

I consider this a JavaScript curse to be honest. Every webpack version breaks apis in random ways, react native is notoriously hard to upgrade because of this etc

Why isn’t it considered a problem in the community?

I've built two projects that I'm very happy with.

I'm still using livejournal.com social network nobody cares about today and when I was really into common lisp I decided to build a cli client to it. What makes it cool is that it's just markdown files locally and the client works almost like git, you can even pull and push posts. After I wrote it I was able to pull all my posts since 2007 or so from the service and have them locally as markdown files, any updates would be synced.

The other thing I've built mostly for my self is a notes taking service https://dabdab.org which allows to take notes the way I want it. What was cool about it was that I was able to almost reinvent django or rails but in go, so everything is fast, but still compile checks. From the product side I've managed to get to the same level of comfort one would get with github issues (markdown, image upload etc).

Both things have 1 user at the moment (me) do I think that counts :D

Ruffle looks really cool as well as flash and especially flash studio did, since it was a truly simple way to get complex interactions out. I've been even toying with a thought to at least try to prototype a similar tool, but nothing happened so far.

One question that I have though in case anyone has insights: how would you imagine a platform like flash to work on mobile?

With html it's solved with query expressions and css which solves the problem there - html is not a gaming platform anyway, more like a place to use canvas and webgl on.

With vector graphics and timeframes I don't see an easy way to do the same

I think every programmer that tries common lisp eventually comes to the same conclusion, however none of the new versions of "standard" libraries got any traction to my knowledge. Usually it's used only by the author who created it which makes their code unique in some sense, like a recent post from Ron Garret [0].

The spec is really valued by cl community and I guess I'll tell an unpopular opinion now, but I think there could be a place for an ecosystem built around one of the compilers like sbcl with all the old cruft removed and a really good all purpose standard library (similar in capabilities to the one of go for example). What that will achieve is that it will allow new developers to write the code without reading on why the things were designed is a certain way 40 years ago because of now forgotten os or hardware limitation.

Similar to what was done with neovim project

[0]: http://blog.rongarret.info/2023/01/lisping-at-jpl-revisited....

I'm working on a notes taking service [0] that behaves the way I want. All notes are organized in the (potentially nested) streams, messages can also have metadata attached which makes it easy and natural to keep track of any observations, be it travel notes, reading notes or exercises tracking. The big idea is to make it a place that would accommodate for any types of notes and any steaming messages in general, e.g. data from your smart home weather station.

Public streams have RSS, you can follow my dev and product streams if you like.

Landing page is rubbish, api is not there, but I hope it's good enough to present the idea. I've recorded a video [1] to showcase the features

[0]: https://dabdab.org [1]: https://www.youtube.com/watch?v=GJURq8PH_d4

As many commenters pointed out, the ability to revert deletions is a highly desired feature. I cannot remember how many times our customers have deleted records by mistake and while deleted_at solution makes a revert trivial (update .. set deleted_at = null where undo_condition = true) it's much more complicated with the proposed condition. Why?

In any living system db schema is something that continuously evolves. New foreign keys, new columns, dropped foreign keys, dropped columns, new indexes. If soft deleted data remains in the tables it evolves with the rest of the system, but that's not the case if it all went into a json blob. Are you sure you want to remember all changes made to your data while trying to restore it?

The problem with queries is there, but I'm wondering about the scale of the problem. From my experience, tables do not go from hard deleted to soft deleted often, hence it's more a matter of habit to check the structure of a table you see for the first time and take deleted_at into account in case it's there.

As the author says, it's all about trade-offs, I would use an audit log for debug purposes (deleted_at does not answer who did it, adding deleted_by to every table adds a risk of split brain - what if deleted_at is null, but deleted_by is not?) and deleted_by to enable quick reverts to accommodate mistakes users and developers do.

A more problematic pattern for me is to trace the changes for different columns. Let's say you tag your uses as being a superhero. The moment you introduce this prop, analysts will immediately ask you who, why and how many times has changed this field and what was the value of the field at the time X. One can say that it's not necessary for all the fields, but I do observe that I have much less trouble in the development if I accommodate for it from the start rather then add hacks to support it later

gymzaal = htmx, autocorrection lol

Hi, thanks for the libraries!

When I started using them, one of the hardest parts was to actually have it imported and built with webpack, since the site focuses on cdn and webpack example is really brief. Same goes for hyperscript

Do you see cdn as a preferred way of usage?

I like gymzaal and hyperscript - they solve few cases but those cover something like 99% of what a average app needs.

My biggest pain point lies with the docs, there are not many of them and it takes time to figure out what’s happening

For example, there was no simple way to understand that both libraries are loaded correctly, also it wasn’t immediately obvious where to use htmx and where to start using hyperscript

It’s not hard to have it imported from node modules and built with webpack or similar

This article makes an assumption: you know how to build the application better than framework developers do, which is not the case in general. Django docs are tremendous and you probably do not need most of it but in reality many of them cover real-world cases and do it in a good way. Sure, it may be a question of minimal code to implement it in go, but you have to know that you need this specific feature and you need to know how to implement it.

I've been doing small projects with go for a while and while I enjoy doing it in go (I like the predictability that types bring to me and the fact that I do not need to go through the tomes of docs to figure out something) I still feel every single time that I'm reinnventing the wheel.

The task is simpler with SPAs since all you need from go is a json api, but if you want to build something complete with htmx you'll have to deal with many questions yourself. E.g.

- orm / db access

- Signup / login flow

- Emails

- Static assets versioning

- template helpers

- CSRF?

- Routing and reverse routing

- Page structures (you want to have the same field to look up page title, right?

- Partials for your templates (how do you do form validation in a nice and generic way)

There is a lot of stuff like this. None of this is impossible to solve, it's quite easy in most cases actually, but it adds up and as I said, you have to know how to do it write

One thing for sure is that if you implement the concepts yourself you don't need to abstract them away too much (or maybe you do if you want to reuse all the nice things in your next project). For me the most compelling thing is types and the fact that I'm not dealing with django/laravel magic with long stacktraces that are meaningless to me, but I still return to thinking about doing next project with rails from time to time, just because I've implemented form validation hundred times already.

One good point about frameworks is about limitations - they are there and this is something that's quite hard to overcome at times. Rails framework does things the certain way and if you want to do it differently you have to fight with the framwork or make an attempt to push things to upstream which I'm pretty sure is not the main goal of your project.

(edit: made list a list)

So far I prefer this approach to any other. I know this type of discussion happens under any go submission, but still - need in generics is overrated, there a ton of code written for all sorts and purposes and scales and it works just fine. And all that without a gigantic marketing push which means that developers simply like it that way it is.

Go is about compatibility, being able to control your code base and being confident about results and I'd really prefer them to take their time thinking through a non-critical feature rather then rushing it and exploring all sorts of unexpected side effects down the road.

Excellent post, thanks for sharing! A couple of comments from a person not in django camp.

First of all, if we're talking about apis I wouldn't go with django in a first place. Of course, familiarity matters, but django requires a person to pick up quite a lot of concepts (forms, models, serializers, views etc) together with rather confusing multi app structure, which takes time to get used to and it's clearly visible from this post given the amount of things to be aware of.

Second, the rule on types clearly highlights how much pain does it bring to do a big project in a dynamic language. I mean, just stop for a second and think about it - you need to do special tricks to help yourself to understand even whether a variable is a list or a scalar value and I'm not even talking about mutable classes where you can't be sure about which fields are legit and which are accidental / monkey patched.

After doing a smaller project in django I've decided to try to do it in go only to be amazed how much faster it was, precisely because of the absence of problems mentioned above. It's not much harder to code (on the same level actually), type system doesn't stand in the way all the time, but at the same time you're in total control of your code.

There are few more points I would like to add:

- control inputs and outputs of your api. Sometimes I see people just passing an object with input data down the stack even without enumerating all the fields, because of reasons. Aside for the obvious security risk it also brings a lot of uncertainty in what the downstream code expects. It's the same antipattern as with javascript where functions are often defined as `function abc(params)` where params - is just a hash of unknown nature. Why is it bad? Because it's impossible to say what the code expects to find in this object without reading the full code. Same goes for the output. Sometimes people simply dump a model to the json and assume that's fine. Here there is the reverse trouble - maybe you know what's being sent but you have no idea, whether it's being used or not and can't deprecate/remove fields without checking all the client code.

- Sometimes you can write the code in a way that prevents you from messing it up. E.g. sqlboiler in go land. It generates the model against the database instance, which means that it's not possible to add business logic to them and that limitation makes it completely safe to work with them from anywhere in the code without a fear that there are some side effects there

- Be suspicious to REST paradigm. It sounds nice in theory like many other things do, but in fact it's really limiting, especially when you're doing an api for an spa. It'll very soon need an endpoint that won't map into any resource or should be a combination of several of them and by strictly sticking to REST you can soon find it really hard to implement even innocent demands from the frontend.

- Use minimal amount of dependencies. This is particularly painful in node land where you get 300mb of node modules just to get started. Every new dependency is something that can potentially break and/or bring security risks and/or get abandoned. If some functionality can be written in a couple of hours it's worth just doing it rather than depend on a random thing from github.

- Write your decisions as comments in the code. The code should be self descriptive in what it does but it won't tell why it does that and in many cases that's the most important thing to know.

- Be aware of ssr and spa combo. It's pretty popular nowadays and for a reason, but it also brings a load of complexity, since ssr is done with libraries like react which means that in addition to your django application you'll have to run a node app somewhere and think about syncing state back and forth or duplicate data access layer. The same goes for spas - it's worth thinking hard about whether there is a real need for it, since it immediately brings more complexity

- Maybe I've misread it but I strongly disagree on saving sanitised input in the database. Any modern orm will make sure that you won't get an sql injection, most of templating systems either escape the data by default or can be tweaked to do so. In return you get the flexibility of adapting the output as you need it in a specific case. Also, just think about the case when you sanitize user input only to realize months later that you need to do it differently. What will you do in this case?

- Something not mentioned there - I think as a general rule developers should try hard to avoid getting more external dependencies like queues, storages and so on. For a really long time a postgres instance can easily cover all needs and is super robust. With every new external dependency things will quickly get more and more complicated

- Structure your dployments to make it easy to spin up new services / cronjobs on the same code base. Complexity lies in centralization. If there is one huge app to do it all that's being deployed as a single unit, it'll very quickly become quite scary to deploy it. If it's possible to separate individual chunks of work to run independently it's almost always beneficial to do so. If the code independent and can be deployed in separate units, it's million times safer to develop and deploy compared to one monolithic superservice.

Edit: the book => a book

I've read the book on ada language recently and it looked interesting, but the developer experience is a mess. IDE that' s provided got kicked out from ubuntu repositories due to complicated build process. Language server is there, but there is not much documentation in the wild and the community is quite small and the whole situation with gpl compiler affecting compiled programs is poisoning.

I think ada as a language is in a very similar place to common lisp - there are few commercial vendors (one in case of ada) that sell compiler(s) and support to companies with a lot of existing code, but not much new stuff happening apart from few enthusiasts.

=It's just my anecdotal experience tough.

SPAs obviously have some positive sides, i.e. state management, but that goes with a price of increasing complexity, especially if server-side rendering is required.

In majority of cases, especially when building tools like back offices it's not what you want, you just want to be able to render forms, tables and save them in a convenient way.

I've found turbolinks + simulus.js combo to work surprisingly well. Actually, I use the only one stimulus.js controller in majority of cases - one that makes an ajax request and reloads the page (with the help of turbolinks) on success. If page load time is fast enough, the use experience is the same as if you would change the dom with js manually. Of course the requirement is that reloaded page reflects the changes.

Other stimulus.js controllers are there for the cases that don't fit into aforementioned pattern. That sounds primitive but can take you a really long way without turning your js into a a monster.

In addition to that you don't need to care about the routing, html validation just works, you can wrap existing html components and even inject react apps here and there if you really need to.

[EDIT] Forgot to say - this approach does not force any language or architecture on the server-side

I tried roam research and org roam only to find out that the overhead of managing notes quickly started preventing me from taking notes in the first place.

Why? Because now instead of just writing down a note I started thinking about what terms do I want to make links and maybe go through previous notes to do the same. Of course you don't have to do that but the whole promise of the system is that the more you connect the more value you get.

I've dealt with this problem a lot (for example it's the same with going through lot's of rss feeds to categorize articles for later reading) and it's always about book keeping taking more time than an actual action.

After that I started thinking what was the most important about note for me. Actually it wasn't connections it was about the sole fact of taking a note (it has a higher chance that I'll remember it) discovery and ability to take a not from any where. A laboratory journal of sorts.

In my particular case discovery is easily covered by git grep and since I use plain markdown files I can always edit it offline with vim or online via github/gitlab web ide. Since it's only one file I don't even need to think about file names. The structure of notes is pretty well defined so it shouldn't take too much to write a script that would generate a digest for some term.

It doesn't always work like this. In the Netherlands you can find big parts of the cities built by housing corporations with people renting them for decades, yet very few of them you can define as ghettos

Is it possible to see any blog or real page without signing up? And is there an api to read/write/manage blog?

Thanks for mentioning Amsterdam lisp meetup. We're very small at the moment but constantly looking for new members and speakers to make it more interesting and attract more people to explore lisp languages.

Thank you for the comment! It's definitely not your fault, but more a community fault and general lack of momentum.

Common lisp implementations indeed lag behind mainstream languages in many occasions, and it's really hard to justify it as a choice for something like straightforward web app compared to other combinations like python + django that provide a lot to get up and running very easily + lots of robust libraries.

What's necessary on my opinion is to create a community effort to pinpoint all missing pieces in ecosystem regarding practical applications like webservices and address them by creating corresponding libraries event if it means direct port at the moment.

A really wish the topics with clickbait title like this were banned on hacker news

Great release!

Is kdbx format supported by any iPhone app? I'm stuck with KeepassX for that reason.