eliasdejong
Joined 1 year ago
Karma
182
Submissions
41
Member since
Sep 6
Recent submissions
Comment · 2 months ago
Comment · 2 months ago
> FWIW I have a potential solution: to show live data in my app I use an SSE stream of OOB swaps.
You might be interested in Datastar [1], which is like htmx but centered around Server-Sent Events. You don't have to do diffing yourself in application code because it's already handled by the framework under the hood through the "idiomorph" DOM morphing algorithm.
Comment · 5 months ago
standby, server is taking some load. should be back up soon
Comment · 5 months ago
Creator here,
For those interested:
- ZERO CLIENT-SIDE OR INLINE JAVASCRIPT except Datastar & Datastar attributes
- real-time multiplayer powered by CQRS
- 45x45 characters chunks stored in LMDB
- all characters are read & written through FULL ACID TRANSACTIONS. no shortcuts. no relaxations
- chunk-based viewport culling
- LZ4 compression on chunk-basis to remove white space and repeating chars
- runs on a 5,52 euro/mo VPS in Germany, cheapest tier in public cloud
Stack: Datastar, Python/FastAPI, LMDB
Comment · 5 months ago
check info tab on the top
Comment · 5 months ago
Read your blogpost, I will need a code editor soon so I might have a stab at hacking something together.
> but this doesn’t really work in mobile and it messes with the selection
I haven't tested it personally, but on the OverType they claim "excellect mobile support".
Comment · 5 months ago
CodeMirror is great, but still requires a lot of clientside JavaScript. I wonder if it would be possible to create a code editor in the same style OverType[0], where the editor is basically just an HTML textarea. You would need 70% less JavaScript code to do exactly the same thing, and it supports syntax highlighting out of the box[1].
Comment · 8 months ago
Checkout DataStar, it's also a hypermedia web framework but it subsumes the functionality of htmx, is faster, more efficient and fits inside 11 KiB. It uses SSE + brotli streaming compression to achieve compression ratios up to 4000x. It makes the web client completely stateless. Building a webapp cannoy be simpler really.
Comment · 8 months ago
To me this sentiment is silly. Programming was never about the act of writing, but about making the computer do something. Now we can ask computers to helps us write instructions for them. Great if you ask me. And no, your job is not going away because human maintainers will always be required to review changes, communicate with stakeholders and provide a vision for the projects. I have yet to see a chatbot that can REDUCE entropy inside a codebases rather than continuously increase it with more and more slop.
Comment · 9 months ago
Very cool project! Being able to replay history is huge and makes it possible to look back in time without having to make full copies of the database. This is something that is very much lacking in many SQL systems where you need 'temporal tables' to achieve the same effect, but those are really limited as they have to be setup specifically and often duplicate data unnecessarily. If you are interested in this topic, I suggest you study Datomic and the EAVT data model. This is likely where database architecture in the future will be headed.
> The database is stored in memory. So it must be small enough to fit in RAM, and the full journal has to be replayed from scratch when opening a file.
For larger datasets, you really want disk support. Using something like SQLite or DuckDB as an append-only store is another way to achieve this effect.
Also lack of a proper query language will be a problem for long term serious use. A simple hand-rolled program API can only get you so far, until you need more advanced querying.
> Unlike XML or JSON, joedb is a binary file format that does not require any parsing. So, joedb files are much smaller, and processing data is much faster.
Some time ago I created a JSON-compatible serialization format that is zero-copy (no parsing required): https://github.com/fastserial/lite3
It doesn't do transactions or history versioning, but it is also very fast in memory. Something like jq or JSONPath on a disk-file version of this format could be interesting.
Comment · 9 months ago
Performance of Protobuf is a joke. Why not use a zero copy format so that serialization is free? For example, my format Lite³ which outperforms Google Flatbuffers by 242x: https://github.com/fastserial/lite3
Comment · 9 months ago
See also, RUM Conjecture: https://www.codementor.io/@arpitbhayani/the-rum-conjecture-1...
Conceptually similar to CAP, but with storage trade-offs. The idea is you can only pick 2 out of 3.
Isn't type validation already in SQL with `CHECK` constraints? I don't see what the language is adding here exactly.