Dev Log #2
Now that a foggy winter has descended, and we still carry the glow of the nicest Berlin fall in recent memory, we’re taking a pause to share some updates on what we’ve been working on and a few things on our radar.
In this note we cover:
- Launching MietWucher
- Experiments in PenPot
- A year review of svelte
- Experiments dry-freezing server data
- Call for projects & proposals
- List of links
Launching MietWucher
With rents in our home city of Berlin reaching astronomical rates, we launched MietWucher, a web-based app that helps people in Berlin, Leipzig, Freiburg, and Hamburg find out if they are paying fair rent or if their rents might qualify as usurous.
In collaboration with Die Linke im Bundestag - we parsed and digitized over 100 pages of city laws, regulations, recommendations, and tables to create a simple pathway and formula for users. This takes into account factors including residential area to construction year to apartment quality. It wasn’t easy – different cities have vastly different standards (ranging from PDFs to surprisingly usable APIs) and processes for calculating rent limits.The process included grappling with Qgis, PDF extraction, multipolygons, poorly formatted data, and the biggest boondoggle of all – learning how to navigate German bureaucracy!
Our eyes are tired from looking at tables, but it was worth it to get such a tool out to the public. Check out some of the press coverage that talks about our work.
Side note: as a digital agency, we also rediscovered the joys of printing – our office now looks like a detective’s whiteboard from a Krimi.
Experiments in Penpot
We recently embarked on a design ideation process with our client Security Force Monitor to create a publishing platform for their datasets. For a while, Miro was our go-to for collaborative thinking and design. But as we moved forward with re-usable components and unified design elements, we decided to give Penpot a try – a new open source tool written in our favorite programming language(clojure) - that’s quickly gaining traction.
After spending two weeks experimenting with the tool, and countless hours of tutorials, we decided to migrate back to Figma. Despite Penpot’s active developer community, we ultimately found it too unintuitive and too buggy (pasting elements outside of the viewport?!) to use in its current state. We’re glad we gave it a go, but not every decision pans out – it’s always worth trying out new tools, but pivoting tools is best done early. And here’s hoping PenPot evolves into the open source Figma competitor we all need.
Svelte ♥‿♥
While PenPot didn't quite make the cut, our decision to switch to Svelte this year has been a game changer. Svelte consistently ranks high in developer happiness, positioned under only Phoenix and HTMX on StackoverFlow’s 2024 Developer survey, we can only add to the echo that sentiment.
Svelte has done something magical: taking reactive dataflow and making it intuitive for JS developers.
$: a = b + c
// or now, in svelte 5,
const a = $derived(b+c)
This is reminiscent of derived atoms in Rum.
Sure, no JavaScript framework is perfect – JS doesn’t make tracking and comparing objects cheap – but Svelte’s compiler works well, the syntax is legible, the docs are great, and it suits our thinking and approach to how we work.
Special thanks to Basile for introducing us to it!
Rehydration Experiments
At DOT • STUDIO, we love static sites. Not only are they more sustainable, they also make maintenance simpler. In our experience, we have found that most of our clients, both in corporate and human right contexts, rarely update the data on their pages. When data rarely changes, a static page does the job perfectly. Why should a server re-do a calculation for each visitor when we could save the result to the page?
One issue is the expected dynamism of modern websites: if you display a table, it should be searchable and filterable. This means a JS framework needs to be involved. Next.js for React, and SveteKit for svelte both allow for this to be done at the page route level, serializing data used on the page somewhere (magic!) to be re-used by the frontend JavaScript.
These are useful tools, but we wanted even more control - we’d like to do it on our own terms: in a subcomponent that is built and requires server information, not beholden to the page/route that called it. RUM allows for html to be built on both the server or the client - on the client through react and on the server rendered in clojure. This would allow us, in the case of Security Force Monitor, to use Datomic’s fast relation queries to generate data necessary for components. We serialize data directly into html elements data-attributes.
(defc dry
"freeze-dries a components arguments into
div [data] attributes, along with the symbol
of the component needed to hydrate it."
[component-sym & args]
[:div {:data-hydrate (serialize args)
:data-component (serialize component-sym)}
(apply component-sym args)])
(defc app []
[:div (dry #'counter "First counter")])
Anything with a data-hydrate gets hydrated on the frontend, with a key to its component and the data to render it. Is this a good idea? We’re honestly not too sure. Is it working great for us? Absolutely.
Projects & Proposals
As we continue to grow, we are always on the lookout for new exciting projects and partners, especially in German digitalization, human rights, and green & civic technology. If you’re seeking a skilled and reliable development and ideation team to tackle a complex problem, don’t hesitate to reach out!
Until then - happy holidays and a warm winter!
What we are excited about
• The dawn of datalog in JS
• Not all graphs are trees
• Incredible writing about data formats by Jamie Brandon
• The new prototype fund call for applications: https://new.prototypefund.de/
• A new report, about social media platforms for social justice organizations