Open-source has many technical advantages over closed-source, in addition to the moral ones (which are quite powerful themselves).
Being able to inspect the software you use makes you able to trust house it works, and fix it at points where it's not working; those were the first motivators for creating the FLOSS movement.
There's also the advantage that in the long term you don't depend on the company developing the software; if the company goes under, or simply stops supporting the software, you can hire a different batch of developers to carry on maintaining it. That's the reason why many big contracts require that the software vendor puts the source code under escrow.
In reality, closing the source of software only benefits the seller; everybody else benefits from having it available. With FLOSS, you get that for free.
Notion's competitor Coda was acquired by grammarly a year ago! It was surprising because the two markets don't overlap at all - but then it makes sense when I realized all data in Notion/Coda/etc are just food for AI companies.
So I won't be surprised if OpenAI or Anthropic or some AI company buys Notion and makes it their playground to launch AI capabilities.
I helped bootstrap a company that made an enterprise automation engine. The team wanted to make the service available as SaaS for boosting sales.
They could have got the job done by hosting the service in a vps with a multi-tenant database schema. Instead, they went about learning kubernetes and drillingg deep into "cloud-native" stack. Spent a year trying to setup the perfect devops pipeline.
Not surprisingly the company went out of business within the next few years.
This is my experience too—there’s too much time wasted trying to solve a problem that might exist 5 years down the road. So many projects and early-stage companies would be just fine either with a PaaS or nginx in front of a docker container. You’ll know when you hit your pain point.
Yep, this is why I'm a proponent of paas until the bill actually hurts. Just pay the heroku/render/fly tax and focus on product market fit. Or, play with servers and K8s, burning your investors money, then move on to the next gig and repeat...
The moment I sign up for a PaaS the bill hurts. I can never get over the fact I can get 1000x more compute for the same price, never mind that I never use it and have to set everything up myself. I’ll just never pay to lock myself in to something so restricted. My dedicated server allows me to do anything I want or need.
That’s only true if you still have to learn how to deploy to a server. I have the opposite problem. I need to learn how to deploy to these wonky services, and it never seems to transfer from one to the other.
I moved from Heroku -> to Render.com in a day, then later Render -> Fly in a couple hours because everything was already dockerized. I’ve never really have to think about my servers on any of these providers, they just run.
> Or, play with servers and K8s, burning your investors money, then move on to the next gig and repeat...
I mean, of the two, the PaaS route certainly burns more money, the exception being the rare shop that is so incompetent they can't even get their own infrastructure configured correctly, like in GP's situation.
There are guaranteed more shops that would be better off self-hosting and saving on their current massive cloud bills than the rare one-offs that actually save so much time using cloud services, it takes them from bankruptcy to being functional.
Does it? Vercel is $20/month and Neon starts at $5/month. That obviously goes up as you scale up, but $25/month seems like a fairly cheap place to start to me.
(I don't work for Vercel or Neon, just a happy customer)
Like, you keep your server running for a month and you need to pay $255 pricey? I can get about 64 cores of dedicated compute for the price of a single neon compute (4c/16gb) unit.
And how much time are you spending babysitting all of this? What’s your upgrade, deploy and rollback story? Because I don’t have to even think about these things.
Yeah, same. Vercel + Neon and then if you actually have customers and actually end up paying them enough money that it becomes significant, then you can refactor and move platforms, but until you do, there are bigger fish to fry.
This touches an important debate on user interfaces. Chat/human language based AI vs GUI augmented AI.
OpenAI started with chat based AI but have since then realized "text only" doesn’t scale for serious business needs. We see openAI pivoting towards richer interfaces like "Canvas" that offers richer editing interface (GUI) with AI as an embedded collaborator.
There’s even news floating around that OpenAI is building a Google Docs / Microsoft Word competitor.
Now, take Microsoft. Microsoft owns some of the most serious business products ever like Office Suite. Microsoft however is working back towards a chatbot experience to an extent that they’ve even renamed their entire online office suite as Microsoft Co-pilot 365 - which makes little sense as a name for an office suite :)
But the bigger question is which approach is right? Maybe there isn’t a single right approach. Maybe that’s why Google is being Google and travelling both ways.
They’re building Gemini, Gemini Canvas as well as already owning an office suite and working towards integrating AI capabilities into their office editors.
This will scale when you have a single/a small set of document(s) and want your questions answered.
When you have a question and you don't know which of the million documents in your dataspace contains the answer - I'm not sure how this approach will perform. In that case we are looking at either feeding an enormously large tree as context to LLM or looping through potentially thousands of iterations between a tree & a LLM.
That said, this really is a good idea for a small search space (like a single document).
Building a rendering HTML/CSS rendering engine is no easy job. Congratulations! I'm curious how were you able to pull this off? What documentations were helpful and what was your inspiration? I'm in awe and wat to learn more about this initiative.
Thank you for your kind words and for noticing the work behind this. Building an HTML and CSS rendering engine has been a long journey with many surprises. I have been maintaining https://github.com/sammycage/lunasvg for years, so I was familiar with interpreting specs and rendering engines. That experience gave me the confidence to tackle HTML.
At first, my plan was simple. I wanted to make an HTML rendering library. But soon, I realized it could be even more useful if it focused on paged output so I could make PDFs directly. C and C++ do not have an HTML-to-PDF library that is not a full web engine. I started coding and thought I could finish in a year by working a few hours each day. But reality came fast. HTML and CSS are much harder than SVG, and even small things caused big problems.
I studied KHTML and WebKit to see how real HTML and CSS engines work. The official specs were very helpful. Slowly, everything started to come together. It felt like discovering a hidden world behind the web pages we see every day.
The hardest part has been TableLayout. Tables look simple, but handling row and column spans, nested tables, alignment, page breaks, and box calculations was very hard. I spent many hours fixing layout bugs that only appeared in some situations. It was frustrating, humbling, and also very satisfying when it worked.
I am still learning and improving. I hope other people enjoy PlutoPrint and PlutoBook as much as I do.
3. Yes, I did come across this. Fragmentation logic is as difficult as it sounds. Right now PlutoBook works with a single, consistent page size throughout a document and does not support named pages, which simplifies things a lot.
Feel free to contact me via email if you have more questions.
This looks promising - thanks for open-sourcing this. This addresses the gap that most work happens in browsers while MCP assumes that work happens with AI clients.
I have a fundamental question though: how is it different from directly connecting my web app's JS APIs with tool calling functions and talking directly with a LLM server with tool-call support?
Is it the same thing, but with a protocol? or am I missing the bigger picture?
This is technically a CRDT. It's just that the "order of operations" to apply over the doc is now resolved using a central server. For context, this is exactly how Google Docs and Zoho Writer works currently. Except that, they use OT with central-server based reconciliation and the proposal uses CRDT-istic approach.
I agree this is more practical if your service anyway run over centralised servers (aka cloud)
> This is technically a CRDT. It's just that the "order of operations" to apply over the doc is now resolved using a central server.
This is not true. One of the most basic traits of CRDTs is that updates are performed without coordination. Relying on a central server to coordinate conflict resolution rejects two of the main traits of CRDTs.
ELI5: Why not use typescript and an embedded v8 engine or deno to run them? What kind of advantages will I miss if I go for typescript as an embedded language for my application?
Also by using v8, I open up new possiblities via wasm (write in any lang and run it here?)
Be warned that V8 is a behemoth and adds 100+MB to your binary size, is quite slow to link, and is not practical to compile from source for most projects. If you want a lighter weight JS runtime there's quickjs, if you want WASM there's wasmtime.
Personally I don't think it's a good choice for what it seems Roto is used for (mission critical code that never crashes) since TS doesn't have a sound typesystem and it's still very easy to fuck up without additional tooling around it.
I think QuickJS wins over Duktape for ES5 compliance, though it's been a few years since I was evaluating embedded JS. They're both extremely easy to integrate into an application, in contrast to V8
Fair, I'm not quite as familiar, but always like to bring up alternatives in case they're helpful. My favorite HN comments lead me to new alternatives for programming.
You are comparing a general purpose scripting language (TypeScript) to a DSL (Domain Specific Language) essentially. They built theirs with a specific purpose.
sounds like it's not fast enough for their use case. plus, have you ever tried to integrate v8 into a project? Deno is fine for building binaries, but to date doesn't really have good support out of the box for bundling a script into a library, which this application seems like it would need.
A lack of universally recognized richtext format is really a problem. Why? practically any rich-text that needs to be rendered across platforms (web and mobile devices) are now being stored as html or markdown or app-dependent json.
HTML was never envisioned as a cross-platform richtext format and markdown lacks almost half of all formatting features. Specialzed json is even more evil because the content becomes unrenderable when the parent app goes out of existence.
op's suggestion (accomodating formattings as unicode bytes) might not be optimal however I'm happy at least somebody thought of this as a problem to solve.
