Great question. We'd look at Obsidian as a reference.
We think there are a lot of value added services that can happen when you need servers, but they should be user aligned & optional (Mobile app, sync, publishing, backups, remote jobs, collab).
We want Surf's client to be independent & open, but offer some of these on top -- for people who want them!
Surf is built entirely on editable WYSIWYG documents, NotebookLM's main AI is built on chat. Surf is built to be a bit more open, NotebookLM was a bit locked down for our taste.
An example I'd highlight is taking notes against a PDF.
NotebookLM will convert the PDF to simple text, and the chat responses are read only. NotebookLM also has a lot of strict walls between chat, artifacts & sources. You have to "save" responses as (read only) notes, and move notes to sources.
With Surf you can generate notes that deep link to specific pages in the PDF, and Surf will open those pages in the original PDF. You can remove the fluff you don't want in your notes. The intention is to be a little more open -- all notes are sources from the get go, you don't have to save or migrate anything.
The big difference UX wise between chatbots and Surf is that Surf is built entirely on editable documents that you can mold / craft into an output (vs chat).
We actually had a chatbot, but our explorations showed that notes were a more effective in many cases!
An example of local data is that "Applets" made in Surf can be opened / updated from your local code editor, they're just HTML files.
Yes great point. Photos are intended as a very important subset of media.
Not (yet) super usable, but for photos we have local OCR running, with Surf creating additional metadata (e.g. the link from where the photo was downloaded).
Can imagine some use cases -- off the top of my head, suggesting the right photos to embed in a note in response to a user query.
We took inspiration from analog notebooks as a tool for thought, but wanted something for multi-media. We also see NotebookLM as the closest mainstream product to Surf.
Related -- some people who have seen Surf's Applets feature have also called Surf "Jupyter for normies".
Basically you can supply input context and a runnable file will generate & run in your document. Useful for creating interactive charts or small applets.
Our philosophy is that if you want to update it, you should be able use your local code editor, not be stuck in Surf!
Hi — another co-creator here, thanks for the feedback.
With respect to your first question, I believe abdelhai answered it in another thread above.
We totally empathize with the experience of getting something to tinker and share rapidly up and running.
We actually started out our journey with our own cloud editor. It was essentially a worse repl.it or glitch but with a built in database and files. What we learned from our own talks with devs is that many of them really love their local development workflow and their own text editors. We decided or original approach was the wrong one for us but still want to provide the instant experience and rapid feedback that Glitch and repl.it do so well.
A couple USPs that might not be apparent in our marketing materials:
If you type 'deta watch' from the CLI, your locally saved changes will deploy in real time to your Micro(server). All you need to do is hit 'refresh' in the browser or make a new HTTP request.
We provide a real time 'Visor' which caches and logs incoming requests and responses. These can be replayed from within Deta against your latest code. Users have found this very useful for developing things like webhooks.
Hi, co-founder of DETA(deta.sh) here; we have a horse in this race, nonetheless are trying to make creating and hosting micro-backends super simple. Currently DETA ships with a micro-crud app based on a Flask-like router.
Auto-generated UI forms and data inspection are on our radar--we'd be more happy to give you access!
- For smaller apps, we think a lot of the difficulty in getting them working in the cloud is making many different tools play nice together. By bundling basic versions of everything and making them very compatible we think we can make this process smoother.
- For larger apps, we think it makes sense to have a lot of tools that are very customizable, because the time spent up front pays itself back over the course of the project.
I'm working with abdelhai on DETA. We want to make it super easy to create usable and sharable cloud scripts and data out of a toolbox of simple services.
One big distinction: we aren't trying to automate people's browsing / clicking, but augment people's thinking.
This creates a different feature set / model: tabs feeding into a document vs a chat going off and automating activity in tabs.