Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What tech stack would you use to build an open-source Google Keep clone?
190 points by mud_dauber on Feb 3, 2019 | hide | past | favorite | 123 comments
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?




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.


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

(Not linked, just a happy paying user)


Is it completely open source + optional paid hosting (I spent a few minutes reading but wasn't sure.)

FWIW: Open Source client + server with optional paid hosting is my favourite. And it is not just words: I've been paying a few hosting services, both commercial and open source, for a few years.

I like the assurance of open source but I often prefer to pay the people who make it to host it.


A bit OT, but honest question: would it bother you if it was almost-open-source, that is, if license forbid leechers (other cloud providers selling competitive offering)?

I am thinking of releasing a product under Apache + Common Clause, Zero License, Business Source License or similar, maybe with GPL timebomb. Basically, feel free to use, improve and share, but don't sell or offer it as a service to 3rd parties. I would love it if normal users could safely use the product and share improvements, but would still like to have a chance at building a business model which didn’t involve donations or selling just support (I want to be incentivized to build a great UX). Which means I am selling convenience, and probably can't compete with others if they can offer the same without the cost of development.

Since you sound like exactly the target audience, would such a license appeal to you, or would you reject it up-front?


That's still completely opensource to me. It's just not Libre software as Richard Stallman would put it. I still think it's an attractive option for a lot of software and wouldn't deteur many users, as most people wouldn't even think of reselling it.


No the OP, but as someone who is happy to pay for hosting, with free software, I would not be happy at all with your suggestion. In fact the original topic is really the reason I would not be happy. The original poster is asking how to build a new service since their service provider has become unresponsive. This is really the last straw. Ideally, as a consumer, you want to be able to potentially move to a new provider of the service using the same software. If you have to change software to change providers, then you are always having problems trying to get matching features, matching workflows, matching data stores, etc, etc. Interestingly, this is also why I don't generally use "open core" unless I only use the "open core" part and pay for hosting. Having the source code is useless because if the user wanted to host their own, they could use free software to begin with. They want hosting.

I think as a service provider, you have to think pretty hard about the service you are providing. Having a cloud based server and keeping it up is pretty basic work. This is exactly why SaaS is so popular -- the actual day to day service is extremely small and cheap. The problem, as you very correctly perceive, is that larger providers can undercut you, very, very easily (because you are buying the actual service from them). They can cut out the middle man.

So for a full free software service, you need to provide something other than hosting as the service. To be honest, one of the really attractive things about SaaS is that you go back to a model where you have an upfront, single time development cost for the software and then you sell it over and over and over again. In other words, you have a constant price with near infinite scaling.

I think this is impossible with free software. I might be wrong, but I've thought through it for a number of decades and I can't see a way to do it :-). With free software (that has no intrinsic hardware or extensive person-oriented service involved) I think you have to charge for actual development time. I think there are inventive ways to do this (many of which have not been tried), but there is no way around it.

I think what you are intending to offer has very little benefit for the user. Certainly, as someone who wants source code, I would not touch something with that license with a ten foot pole. If I were you, I would just go with SaaS or Open Core and be done with it. If you are really intent on providing useful source code for the user, then I think you have to come up with something that they want to buy. That thing has to be something that other people will have trouble competing against. For most programmers, that means development services.


Thank you (and siblings) for an answer! I especially appreciate the reasons given.

You are of course correct - requesting a commercial license for any potential competitor will limit users' options with respect to the provider they choose. It does however grant them the option to self-host. While not that convenient, it still provides some incentive for me to try better, and is a backup plan for users if I become unresponsive. Better for users (and safer for me) than Open Core I think?

That said, the decision is not final yet, and I'm also not satisfied with any license I checked (closest is Common Clause, but what happens with snippets of code, reused in other, maybe foss projects?). Thank you!


Just to be clear (without being annoying I hope), there will be a class of users (myself included) who won't touch it. I would consider it a proprietary license. It isn't a kind of open source compromise. Having said that, there are a lot of considerably worse proprietary licenses. Good luck on your endeavours!


Yes, it is clear, and I appreciate your thoughts a lot! I am just hoping that this class of users is in minority... ;) Good luck to you too, and thank you!


I use StandardNotes and the Open Source aspect attracted me. I can run the parts if the company goes away. Today, I’ll pay SN a reasonable fee for convenience and future additions.

The competition is Evernote if the software isn’t free. I feel like SN seeks convenience now. Licensing games are just another commercial competitor.


The apps and server are both open source. There is also free hosting. The bit that is not open source is the "Extended" paid subscription which includes all this: https://standardnotes.org/extensions

Open source is split across multiple repos:

https://github.com/standardfile/ruby-server

https://github.com/standardnotes/web

https://github.com/standardnotes/desktop

https://github.com/standardnotes/mobile


Off topic, but it's humorous to me that the "Web" logo is simply the Chromium logo.


Arguably more depressing than humorous!

I do like that there is a "download" page for the web version though, which "downloads" a 301 redirect.


I see that on Reddit also. When viewing their site from a phone, a pop-up says "view on our app? [Reddit Logo] View on web? [Chromium logo]"

Silly goose, I'm never leaving Firefox.


For me it shows the [Reddit logo] and [Safari logo], since I'm on IOs. So it seems like it pulls the standard browser...


> standard browser

Why would Chromium be the standard browser for Android? I have never had that installed on my phone.

Edit: Yes I know Google develops the Chrome products. Down-voting my post without discussion is pretty useless, no?


Maybe the reddit popup just pick a ‚standardish‘ browser depending on the OS. I only have Safari on my phone...


Because it is the standard browser that comes with OEM Android. Google phone, Google browser.


Is that true? I've always seem Chrome but never Chromium.


It's the new "e" icon.


I’ve been using standard notes and the client isn’t great. It makes me choose between editor addons when what I want is just one really good editor.

Example: I want features found in the advanced editor but also in the markdown editor


Yeah, that's fair. I would mention that to them - they are responsive to feedback when it doesn't conflict with the longevity and stability requirements.



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.


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


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)!


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.


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.


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


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

I haven't really used Elixir so can't talk from experience. I did look at it but just prefer Erlang syntax. I hear good things about the language, ecosystem and community though. Phoenix seems really well-regarded as a web framework (and indeed, there is/was some integration with Elm).

It uses Erlang's underlying VM (BEAM) so benefits from the stability and concurrency BEAM brings. So I don't see any obvious downsides.


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


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.


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?


I think it's very promising, but it definitely has some rough spots.

Things I like:

  * It's a general purpose language, it's not only usable on the front-end (like Elm for example).
  * It's a really powerful language (or rather, OCaml is).
  * Interop with JS is good. It takes a bit to get used to the syntax for writing bindings, but once you get the hang of it it's pretty straightforward. Again, ReasonML IMO scores a lot better in this front than Elm.
  * ReasonReact is a very thin wrapper around React, so if it's really easy to work with if you already know React.
  * There are other options than ReasonReact, for example bucklescript-tea [1] which is very Elm like.
  * There seems to be a lot of focus on targeting native. See for example Esy [2]. There's some real potential in bs-react-native [3] and Revery [4].
  * Overall the experience of working with Reason is really great. The compiler has your back, is great at type inference and the syntax is pretty elegant (though IMO a little less so than Elm).
  * The compiler is blazingfly fast. Blows Typescript and Babel out of the water.
Things that are a bit rough:

  * Docs are spread across Reason docs, Bucklescript docs and OCaml docs. A lot features are not documented in Reason, because they're inherited from OCaml. If you would read just the Reason docs you might get the impression that's a pretty small and simple language, but it's actually very powerful. If you're thinking about picking up Reason I definitely recommend you read the RealWorldOCaml book [5].
  * The Reason syntax is a bit weird in some spots. If you make a syntax error the compiler will in most cases just yell `Error: Syntax error` at you which is not really helpful.
  * The ReasonReact API feels a bit alien, probably because it's build on top of the React Class API. I think there a bit some big changes coming to ReasonReact though, so hopefully this will change.
Things that concern me:

  * There's little formal communication about the direction and future of the project. It seems to be mostly Facebook who's behind it, it doesn't feel like a community project at all. Bucklescript seems to be largely a one man show.
  * There have been a handful of Bucklescript and Reason releases that plain broke stuff. Of course this can happen, but it does make me a feel a little uneasy.
All in all I'm definitely positive. There's a lot of potential and hopefully when Reason picks up some more steam it can become more a community project. Be sure to check out the Reason Discord [6], very helpful people there!

[1] https://github.com/OvermindDL1/bucklescript-tea

[2] https://esy.sh/

[3] https://github.com/reasonml-community/bs-react-native

[4] https://github.com/revery-ui/revery

[5] https://dev.realworldocaml.org/

[6] https://discord.gg/reasonml


> 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 :)


Sure! It's https://github.com/pascalw/pragma/ and there's a demo running at https://pragma-demo.pascalw.me/.

I've actually just taken a short break from the project. It turns out building a good offline + sync note taking app is more complicated than I imagined it would be :-) Given that I'm just working on it in my spare time every now and then it frustrates me a little sometimes that I'm not making as much progress as I would like. But probably I'll pick it up again soon because I do believe this could turn out to be quite useful.


For those interested, password is: demo


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.


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.


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.


Nice, thanks for contributing it’s the most promising cross platform app development I’ve seen so far.

I think it’s fine for us to disagree on Mobile vs Web. But I think depends on what his goals are, in my opinion these days Desktop isn’t the main use for apps like this. He could always add that kind of support later.


A notes app where you are forced to type notes on a touch "keyboard" always discourages me from making any notes.

Having it on the phone is nice, but it has to let me type in my notes at ~100wpm as well ;-)

(Of course, to each their own)


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?


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


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.


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


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


Downloaded. This is promising, TY!


The one that you're most productive in.


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


If you're goal is to get the app done and published rather than learning a new tech then go with your default stack. I've never worked with Rails but it seems like a totally valid choice for the product. You can always bolt on a more modern frontend later if you need it.


Thanks. It's Rails' frontend performance stigma that made me hesitate. I suppose bolting a better FE is an option, but I won't know it until I benchmark it.


I'm a rails dev too, last year I was making a mobile web app where I was concerned about frontend, so I started making a SPA in mithril.js and using Rails as the API.

Later I abandoned the SPA and went back to rails views, using turbolinks to make it fast. In reality rails + turbolinks is fast enough for most cases, and then I can sprinkle in extra javascript or use SPA on one or two pages as needed.

The reason I think it's almost better to avoid SPA + API approach is to keep the codebase simple and easier for one person to maintain.

https://www.youtube.com/watch?v=SWEts0rlezA http://masilotti.com/beermenus-and-turbolinks/


I’ve been going through the same thought process on a similar project in Django. Every way I look at it, the SPA route is slower and far more complicated.

I don’t know much about Rails’ perf, but by and large “SPAs are faster” only seems to hold up if you’re only measuring actions after the first page load AND your pages are very dense with heavy assets.


As others have pointed out the SPA route can introduce a huge amount of complexity. If you're a Rails dev one option worth exploring might be Phoenix + the upcoming LiveView feature.


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.


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.


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.


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.


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.


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.


Your app reminds me me of Pinboard.


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.


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


Don't worry too much about the tech stack. Use whatever you're comfortable with.


I use Keep Notes on Android for shopping lists and while the UI is sleek and animated, the lag is intolerable. Thanks for reminding me that I can simply switch to another app.


Offline-first PWA using React/Vue + PouchDB

What features do you want Google to add to Keep?

I'm not satisfied with existing note-taking apps myself, and I'm currently researching/prototyping alternatives. My current prototype focuses on eliminating input friction, and I use it as my Android launcher.


Hi, I agree with you, PouchDB is an exiting technology. I had built an webapp (PWA) as a open-source side-project, using Vue+Vuetify+PouchDB, and it looks like to works well for single-user. It is not finished, I have some ideas to gradualy improve it, like WYSIWYG, encrypting data, full-text search, notifications, ...

The demo/presentation is here : https://jimskapt.github.io/lambda-badger, and source is here : https://github.com/Jimskapt/lambda-badger


Take a look at Riot.js or Mithril.js if you want something much simpler and easier to pickup quickly. Another great option might be Svelte & Sapper (Sapper is for Svelte like Next.js is for React)

Try focusing on finding ES6 approaches and that'll help keep your code simple also.


I like Keep the way it is. Add anything more, and it quickly turns into a mess.

It’s already at the edge in my opinion, and I would like to continue using it for a long time into the future, so please stop pushing the engineers to change things. You might actually convince them...


I don't know which frameworks do real time multi-user updates but that's a feature of many of Google's apps I would miss if it wasn't there.

I have Keep open on my laptop, my work desktop, my phone, and sometimes my tablet. If I edit on one the edits show up everywhere else without refreshing which is important because I might be sitting at my desk, type a few things into a list, walk down the hall, get out my phone, add a few more things.

Maybe people can suggest which frameworks handle that for you vs which ones you'd have to role your own solution.


Meteor was amazing for this but unfortunately seems to be on its way out.


What makes you say this?


That Meteor seems to be dying? Some good answers on HN here: https://news.ycombinator.com/item?id=16782266



It seems to me that the frontend is pretty simple and most stacks will be fine. I would worry more about how the data is stored, backed up and other backend parts. My expectation is that most work will be done on the backend side.

Another consideration that’s independent from your frontend stack is how the user interacts with the UI. I guess that’s called UX these days. Making the right or wrong choices there will have much bigger impact on success than the framework choice.


Agreed & thanks. That's why I started with a text file of UX gotta-haves and like-to-haves before touching any code. Appreciate it.


Historically, many of the most successful open source projects that did not have the support of a large company or organization were forks. Just some food for thought.


Any Js framework will work, also vanilla js will work.

Just pick a framework that you want to learn and do this project on this framework. Also if you want to learn vanilla js, pick vanilla js.

And for the backend side, same story, pick whatever framework and language you prefer. Superior framework at the scale of a side project doesn't exist. And personally I would pick vanilla js with Django because that is the stack I know the best


Holy should I thought I was the only one I'm giving them feedback literally every other week. I keep reminding them that they should just hire one intern. Like literally send a 12 year old to improve the app for 3 months and they'll find a many ways by themselves. This is not even a snail's pace; perceivably it's as if literally no one to sign to it at Google.


NodeJS + ReactJS +or Vue with Apollo or Rest and Express and MongoJS

All JS no context switching and many open source components already done.


Depends, if the idea is to build something reliable that will be maintained for longer periods instead of just for learning the newest whatever.js I'd choose something boring. For example Python/Flask + Postgres for the backend and plain JS for the frontend (possibly with React but that's it).


When I became unhappy with Google Keep I switched to Nextcloud Notes.

It arguably has some downsides compared to Keep, however it suits my needs and as a plus it supports markdown formatting.

Additionally it's open source, so you might get some insights into which thoughts went into it, which might help when designing your own solution.


What are NextCloud Notes' downsides, in your opinion?


One thing is that you can put one note only into 1 category. There is no "tag" system that allows multiple tags per note.

It also only supports text notes, so if you use drawings, etc in Keep a lot that might be a problem.

What I really like about it though is its simplicity and that I can easily run my own instance (of Nextcloud which I use anyways).


I wonder if a server side rendered app with Rails or Java/Spring Boot would do. If you want mobile first then Flutter may help. But in any case exlpore Firebase for persistence. It's cheap and very scalable, provides Sync and push notifications as well


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

These 2 keep extensions have hugely improved my satisfaction with keep. Try them out.

https://chrome.google.com/webstore/detail/input-tab-in-googl...

https://chrome.google.com/webstore/detail/category-tabs-for-...


Thanks. I'm a (fairly) heavy user of category tabs.


What would I use? Standard tech stack: React+Apollo+Redux+GraphQL (with Typescript). React Native for mobile. On the backend, Postgres DB at first, upgrade to CockroachDB or something when needing scale. Choice of language for application server to translate GraphQL queries to and from SQL queries is the only thing I would be unsure about - either Python or Typescript probably.

But this is because I'm very familiar with these frameworks. Productivity using them is really high once you've learned them well. But the learning curve to learn these technologies might be more than the amount of work that goes into making a Google Keep clone with a more approachable framework...


> Standard tech stack: React+Apollo+Redux+GraphQL (with Typescript).

The standard or A standard?


Nearly all the new startups I interviewed with recently were using that stack, except some had vanilla JS or were only partially converted to TypeScript.

It's becoming the de facto standard stack for new projects.


Why not apollo-link-state instead of redux?


No particular reason other than I'm used to redux.

My gut reaction when it came out was "it seems rather unwieldy compared to redux to have to manage client-side application state through graphql", but my gut reaction could be wrong, and I haven't actually tried apollo-link-state so this isn't really an informed opinion. Notably though, it feels think graphql is great for graph data, but pointless overkill for most global application state which isn't really graph data.


I'm interested in this simply because Keep still, somehow, doesn't have sort by most recently edited, even tho Apple managed this as the default a decade ago. Manually dragging a note to the top every time I use the app is so painful.


Exactly. I end up pinning & unpinning notes to do this. Painful indeed.


I would actually start with a closed source backend-as-a-service: Firebase.

Then you can concentrate on getting your front end. Once you have a great UI add multiple backend support, maybe on ipfs or something super open.

Tiddlywiki might be interesting to you as well


This is what we chose to use after surveying what is by far most deployed in the wild:

https://qbix.com/platform/welcome/stack


On frontend:

Google Todo app tutorials and pick the one you like the syntax the most and you can complete in a couple of hours. There are gazillion of tutorials out there how to build one. I would follow a React based for learning purposes.

For backend:

Try a simple Express backend with Node.js and Firebase as a database. With a todo app, you will never run out of the free tier and migrating between server provider will be very simple.

Level it up with a nice UI library:

https://ant.design/


You could take a look at what I'm building with Polar:

https://getpolarized.io/

It's basically note taking but integrated with the reading flow. You basically keep all your books and notes in one place and you can annotate and highlight directly within Polar.

It's basically a "personal knowledge repository" with all your books and web content integrated along with highlighting.


Google Keep serves a different purpose. Although I guess you could use them for the same thing (kind of), the card-based functionality is Google Keep’s main selling point, which your application does not seem to include. Although I like what you’re doing, I think it’s too different and too specific to reading and note-taking to be a Google Keep replacement.


oh yes.. they're different. I agree.


Just letting you know, if you ever build a android app, I will download the paid version happily.


Ok, enough. I'll try your app now :)


As far as your backend design goes it really depends on your scaling needs and how much of a purist you want to be about keeping your dependencies open source. If I was just trying to scratch a personal itch I would write it as a Typescript w/ Apollo GraphQL hooked up to a managed Postgres and running on a serverless platform like AWS Lambda. I’d probably write the frontend in React with some kind of state management library.


React Native gets you the most platforms for the least effort (web, mobile, windows, macos). React PWA if you don't care about being on the app store.


I'm a happy user of https://simplenote.com/, if it helps.


You can roll out your own app using a frontend framework together with a backend one - like Node, PHP, .NET, etc. Using something like Firebase, a backend framework becomes less relevant - but some of those features you listed are deceptively complex. My suggestion would be to pick up Angular or VueJS together with Firebase. React can be tricky if you're starting out.


I would use, Datomic for revisioning, horizontal scaling, and flexible schema (whilst still being relational)

Clojure(Script) for the ability to use same language front and back, for it's very good interoperability CSP and expressions

Datascript for my client side database, I'd probably try and achieve a real time app based on something like hyperfiddle


FE: vuejs (PWA), BE: PHP Laravel,

I would be interested in working on a backend if it would be this stack :)


What's wrong with Google keep exactly? Maybe the problem is within u and not on there end. I don't know if it's "there" or "their", but neither does the POTUS, so it's ok.


Since you want to produce documents (notebooks and notes) I would use a doucment format for storage, that allows for light and shallow relations: XML with XQuery on the backend (eXistDB or BaseX, I can recommend BaseX). REST and websockets are a welcome addition, these XML database/XQuery processors can satisfy. They can convert to many JSON formats, which then you may consume on the client side.

As for the client side: I tend not to think about that too much, since it is often quicker and easier to create your own DOM manipulation than learning any of these, highly opinionated, frameworks. I like to use jQuery, because of the huge community, the large number of plugins and since many other frameworks try to stay compatible.


Futter for Android/iOS and any JS stack for web

And use Firebase or Firestore as the database. It's super easy to build a simple MVP app with just Firebase SDKs


Start by browsing numerous existing os tools on GitHub.


What would I use? Rails + React


Firebase for authentication + realtime multi-user database. Frontend can be anything that works with Firebase.


Backend: nginx, sqlite or postgresql and Your Favourite Language for logic

Frontend: vanilla html5, css and js


What features and improvements currently lacking in keep are key deliverables for you?


Off the top of my head:

* card sort by creation date, last edit, title text, maybe card color? * private/public/sharable options per card * something other than raw text display (markdown?) * a better page load strategy for slower connections

Nice to have: * card width/height options, maybe via CSS like Muuri * archives to selected categories


I got a task to do. I got a app to bootstrap. Check up on hacker news - Angular 2, React or Vue?

https://youtu.be/Yx6k6WR8GRs


At the very least use a language with static types, and maybe concurrency support without a GIL getting in the way when you're coding the non-web frontend portions.


What features are you missing?


As a customer, I would like to use a zero knowledge application for note taking. I don’t want my notes leaked due to security breaches. I also don’t want them to used for other purposes such as data for machine learning without my permission. My notes should always be encrypted and I am the only who has the key.

You may want to take a look at Bitwarden to see how they do it. It is open source. You can use the similar architecture for client side encryption and decryption, and extend it to note taking.


I've used this before which fits your bill: https://clipperz.is.

Quite an interesting app and you can download and offline copy of your notes too.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: