Ask HN: What tech stack would you use to build an open-source Google Keep clone?

[mud_dauber]

I'm sick of waiting for Google's Keep team to improve their app, or even to respond to feature requests. (Crickets.)

So I'm going to attempt to build my own - despite being a real noob when it comes to JS-based tech stacks. What would you use as a starting point for a tech stack, if you want:

- public/private/sharable card options - import/export to a couple of mainstream alternate formats - reasonable response times - an improvement over downloading the entire DB upon page load - markdown-capable cards - sort/filter/tag options

I'm assuming this is going to be some flavor of Angular/Vue/React. Suggestions?

[saulrh]

If you want people to keep their notes in it, it's going to have to advertise stability and longevity. Ruthlessly cut dependencies/requirements and avoid using features that may change under you as time goes on. Use a simple data-store built with common tech (json, sqlite, straight text files, etc) so people can get to their data even if your code disappears off the face of the Earth one day.

For the frontend, then, we're talking tables and forms. Really simple lowest-common-denominator stuff. Design the API before touching any of the code - that's the only place where "without pulling the entire DB at page load" can happen. Build the backend in something with a safe, stable standard lib or core ecosystem, python or common lisp or the like.

Of course, those are ultimately stretch goals. Like another commenter here said, use whatever you're most comfortable with. On the vast majority of software projects the biggest obstacle is the programmer. I can't really help there because I don't know what you're familiar with. Sorry. Good luck.

[insomniacity]

You sound like you're describing https://standardnotes.org/ !

(Not linked, just a happy paying user)

[tmpfrosreponse]

Maybe contrib to : https://github.com/paperwork/paperwork (JS + Docker) https://github.com/Laverna/laverna (JS) https://github.com/keybits/permanote (Python) https://github.com/Azeirah/brainstorm (JS)

[tga]

At its core, Google Keep is a relatively simple web app. Especially for a low traffic scenario, literally any web framework/library and combination will be good enough. You need storage, a backend, and a front end, either all from the same package or talking to each other.

I suggest you figure out what looks interesting to learn and go with it. You can also “outsource” parts e.g. getting storage and backend as a service from something like Firebase, so you can focus only on building the front end.

[brobdingnagians]

I'd use Kotlin for several reasons:

1. good ecosystem for Java libraries on serverside (and mobile) for parsers with Markdown, etc. you could re-use the parsers between mobile & server to reduce dependencies

2. Code re-use on apps for Android & with multiplatform projects you get a lot of re-use for iOS (and swift is pretty similar, so you'd have an easier time porting)

3. Code re-use between the apps and the Javascript front-end for web (kotlin transpiled to Javascript). One language for both front-end and back-end (similar to why a lot of people use npm for serverside), which I find to be way more maintanable

4. You get similiar ease of programming as Python, etc. but with better performance

5. Kotlin can be used with React, Vue, & Angular and can integrate with existing Typescript annotation files by a conversion tool

6. You can use ktor to easily setup a server without having to setup a full Java servlet container

[wtmt]

I'm going to throw this one back at you:

> "I'm sick of waiting for Google's Keep team to improve their app, or even to respond to feature requests. (Crickets.)"

Choose a stack that:

a. has many developers using it on GitHub (since that happens to be the most popular platform for hosting open source code)

AND

b. is easier to use or fork as well.

Life will take over at some point after you develop some version of a Keep alternative. It may be the same as Keep today or lacking a lot comparatively or better than it. In any case, you'd need something that others can contribute to (sending pull requests), fork and create different/better versions of, etc. If you go with some relatively obscure stack or a dying stack because it promises to be fun or promises that you'll learn something new or promises something very fancy, then you'd either not get many users for your application or would have people in the future screaming the same sentence you started with above.

In other words, try not to do to others what you imagine the Google Keep team has done to you (or not done for you)!

[sitkack]

I second this. Build abstraction ladders. Built platforms, and build it such that you don't have to build everything, something users can extend to meet their own needs.

Application developers need to open their platforms. Had Keep made their application open and layered, your new features would be locked behind the Keep gate.

[spinningslate]

Warning: this is deliberately not following mainstream convention/fashion. It's hopefully useful, but feel free to ignore if you'd prefer not to explore beyond more conventional options.

First off, a few requirements I inferred from your Q:

1. Performance (response time + concurrency)

2. Simplicity (you're a noob, but it's always a good thing anyway)

3. Stability + ease of maintenance/evolution (you don't state this explicitly - but if you're building on your own, I'd guess you'll have limited time to do this).

Based on those, here's a suggestion.

1. Write you back end in Erlang, using Cowboy or WebMachine to expose RESTful services. Simple, performant, robust, scalable, proven, stable.

2. Start with the premise that simple term/text storage (i.e. no DB) will suffice. Only move from that if you disprove that premise

3. Ask yourself how much of your front end can be handled with straight CSS + HTML. Probably not all, but you'd be surprised how much

4. Instead of a javascript framework, have a look at Elm where you do need client-side behaviour.

I fully accept that neither Erlang nor Elm are mainstream choices. Certainly not for everyone. But they're both well-designed, robust and pretty stable (Erlang more so than Elm on the stability front admittedly - the Elm language is still evolving).

I'll also freely admit that I really dislike the javascript ecosystem. I say "ecosystem" deliberately; I'm not crazy for the language itself, but it's the infuriating instability of packages, frameworks, build tools etc that means I avoid it as far as possible. It seems to take more time just keeping up with with the ecosystem than actually delivering meaningful functionality. I don't find that with Erlang or Elm. Yes, Elm 19 introduced quite a few breaking changes. Though I didn't find porting too painful given the tooling is so good.

YMMV of course.

[mud_dauber]

Interesting. I just spent a couple of weeks learning Elixir & really liked it. Any disadvantage to doing the backend work in Elixir instead?

[gglitch]

I’m learning the Elixir/Erlang/OTP ecosystem now. How would you do the term/text layer? ETS with frequent writes to disk? Mnesia?

[PascalW]

If you're going to build an open source product that you want people to host on their own servers then a few things are really important:

- Ease of deploying.

- Amount of resources required to run it.

I've been building an open source notes app recently and I picked Rust + ReasonML and React in the front end.

It's super easy to deploy; it all compiles down to a single native binary that contains both the server and frontend.

It's super easy to deploy this, with or without Docker. It consumes almost no resources at all. The binary is 12 MB and consumes around 5 MB of RAM.

On the frontend it's a PWA, so it's available offline too. This is the most important part. You could build the PWA in other frameworks as well.

[Klathmon]

This might be off topic, but how are you liking reasonML?

I've been meaning to pick it up for a while now and keep reading over the docs but still haven't done much. Would you be willing to talk about some of the pitfalls and rough edges you've hit or things you would do differently?

[yarinr]

> I've been building an open source notes app recently and I picked Rust + ReasonML and React in the front end.

Could you share a link to the repo? I'd love to take a look :)

[rco8786]

The answers in here are just going to be a big mish mash of people promoting whatever bespoke languages/libraries they’ve recently discovered.

Use what you know. Choose stability over cuteness. The app you’re building doesn’t dictate any specific stack.

[lbacaj]

So for something like this I would go Mobile first and I would use this new open source technology from Google called Flutter, you can avoid JavaScript all together and go with Dart, even if you’ve never used it it’s incredily easy to learn. In my opinion is far superior technology to react native. You could get out a cross platform app with some of the basic things you describe in a few weeks.

I would use AWS Lambda or Azure functions for the entire backend for something like this. You could make it incredibly scalable and do it incredibly fast. Both AWS and Azure have great managed Document database you could use to power the features you mentioned. It has never been easier than it is right now to build some incredibly things.

Shameless plug, this is exactly what I did with a recent app I built that can take any article and convert it to Audio. Check it out https://Articulu.com got it out for iOS and Android incredibly fast.

[hwc]

I indirectly contribute to Flutter (via one of their dependencies), but I would still say to make a web app first, so you can always access your app from a desktop.

[scabarott]

This is interesting. How long did it take you to do this? Do you manually curate the articles in the app or are they randomly pulled from the web?

[pizza]

Start by making mockups in Balsamiq. Then pick a single screen/view of your mockups to start picking up the basics of React Native (just use the Expo framework (which is a React Native framework) for rapid prototyping).

React is hard until your understanding of it finally 'clicks' - and having a wireframed visual reference of what your app is supposed to look like actually makes it easier to think about how it should be layed out in code, imo.

I actually just started learning React Native and I re-wrote the first iteration of my app's home screen many times (and kind of aimlessly) until I had something that actually made sense and was easily maintainable - still re-factoring it into something even simpler, tbh. That said, I think that was mainly due to me not knowing what was in the library or having approached the UI components properly in the first place, so I think I will be prototyping quite a bit faster over time.

re: state management/backend, I'm also confused as to what stack would be best for what I want to do. I'm guessing Firebase with some minimal manual state management? All the state updates my app needs to do is essentially record the user ticking some checkboxes, and some timers updating in the UI, and those persisting on a user's phone but also optionally associated with their account online if they so choose.

edit: I might actually go the PouchDB route

[goloroden]

For the backend I'd use wolkenkit, a backend framework for JavaScript that lets you build backends very quickly: https://github.com/thenativeweb/wolkenkit

To get started, you find everything you need in the documentation, see https://docs.wolkenkit.io/3.1.0/

There is also an existing sample application that you might use as a starting point: https://github.com/thenativeweb/wolkenkit-boards

For the frontend I'd use React, probably, just because it is the UI library / frontend I'm most familiar with and the one I value the most.

PS: Please note that I am one of the core developers of wolkenkit, so please take my answer with a grain of salt.

[rakoo]

I'd take inspiration from tiddlywiki (https://tiddlywiki.com/). It already has much of what you need and is open-source. No need to start from scratch

[paulirish]

+1. tiddlywiki is exactly what I was about to recommend.

[mud_dauber]

Downloaded. This is promising, TY!

[joshmn]

The one that you're most productive in.

[mud_dauber]

That's Rails. Which I love - but I have my doubts.

[developit]

Preact and Hoodie/PouchDB. Frontend hosted on Netlify, backend on literally anywhere ($5 Dokku one-click installation on a DigitalOcean VM, Heroku, whatever). Hoodie/PouchDB gets you a pretty easy fix for the "whole DB on page load" issue and pretty good realtime sync across clients.

[pier25]

Front end: You could use anything you wish, heck even jQuery. Svelte is lightweight and powerful. If you prefer a React/JSX flavor I'd go with Inferno which is faster and more lightweight. Vue is probably the easiest one to use of the bunch.

Back end: You could certainly do that with cloud functions without a database. Store encrypted JSONs somewhere. It would scale effortlessly. Use Auth0 for authentication.

Another option could be hasura.io which provides so much out of the box and can be installed everywhere with docker.

[LeanderK]

I would go for a PWA! Easy sharing & collaboriation for notes without having to install an app would awesome!

I also think all the available APIs would be enough for a note-taking app. iOS improved it's support massivly in the latest beta.

You just need to keep it snappy! I take notes quickly and often.

[bobbydreamer]

Well i think eventually every programmer will build their own personal notes app and start to use it. That's the easiest thing to do if you want to learn a programming language or framework - Home projects. Why I did this ? I used evernotes between 2008-2011. Then bought Nokia 920 and windows Phone at that time did not support evernotes so switched to OneNote and been using OneNote next 7years(same Nokia920 strong phone). Last year switched to Nokia 7Plus Android still use onenote it doesn't have features I want. I basically want to take quick notes and bookmark links and I need a timestamp to say when I did it. So in the process, wrote an app for personal use. It suits my requirement as of now - https://stash.bobbydreamer.com

Feel free to try it out.

What I used is JavaScript, bootstrap for menus, Firebase for storage & authentication.

Next phase for learning ofcourse, 1. Option to write Notes in Markdown 2. UI look like Outlook 3. Not fully load entire db in homepage.

Below items I have already in my todos, I am sure I will never do it as I have other personal apps in mind. 1. Export/Import 2. Mark a note as public or private. If public anybody can comment on your notes. Suggest changes.

[platz]

Google Keep is an interesting because it's hard to exactly categorize exactly what it is, or exactly what use case it attempts support.

It's kind of like a crossover between a private Pinterest, a bookmarking app, and a note taking app.

So it's multi-paradigm.

But of you know your use case better, you can tailor your soltution to fit.

You can then make better decisions on online/offline, where to store state, web vs native etc.. this is the benefit of simplyfing and clarifying your use case.

For example, I am a heavy bookmarker (~70k bookmarks), so I built an open-source, self-hosted (I don't want to own your bookmarks) bookmarking web app (https://github.com/jonschoning/espial). It is pretty minimal, but it is tailored to quickly bookmarks while browsing. I didn't bother with native because I am already in a browser context when I want to bookmark something.

But maybe I am just biased towards web hosted tech. I just don't see the value add for native unless it's doing something intimately connected with the physical device or physical user.

[mud_dauber]

Your crossover comment is a good one - especially the "private Pinterest" angle. I attach a pic to every card, because I find it much easier to scan a home page that way instead of trying to read every card's title tag. (Of course I'm killing my page loads, but I guess that's the price I pay.)

And I'm always in a browser context too. Thanks.

[jnskw]

Your app reminds me me of Pinboard.

[tmaly]

I had the same issues.

After reading GTD, I ended up switching to the Things 3 app. I think I paid a one time $10 or $20 but it has been worth it in my opinion.

The one app I have not found yet, is one that can help me organize all the knowledge I discover online. I end up using favorite on HN and had a bunch of links in Google bookmarks. Still, its hard to find the stuff once it gets in there.

[thwave]

Partly OT: I've checked a whole lot of note-taking, personal-wiki, bookmarking, outliners, et cetera, and none support Bidi[0] or RTL properly. Markdown editors fail most miserably, of course.

[0] https://en.wikipedia.org/wiki/Bi-directional_text