Ask HN: What tech stack would you use to build an open-source Google Keep clone?
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?
127 comments
[ 3.7 ms ] story [ 234 ms ] threadLater 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 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.
Try focusing on finding ES6 approaches and that'll help keep your code simple also.
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
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.
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.
(Not linked, just a happy paying user)
I do like that there is a "download" page for the web version though, which "downloads" a 301 redirect.
Silly goose, I'm never leaving Firefox.
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?
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.
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?
The competition is Evernote if the software isn’t free. I feel like SN seeks convenience now. Licensing games are just another commercial competitor.
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.
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!
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
Example: I want features found in the advanced editor but also in the markdown editor
And use Firebase or Firestore as the database. It's super easy to build a simple MVP app with just Firebase SDKs
https://framagit.org/framasoft/framanotes-api https://framagit.org/framasoft/framanotes-js
https://framanotes.org/
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 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.
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)
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.
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).
All JS no context switching and many open source components already done.
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.
And I'm always in a browser context too. Thanks.
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
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.
* 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
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.
The demo/presentation is here : https://jimskapt.github.io/lambda-badger, and source is here : https://github.com/Jimskapt/lambda-badger
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.
https://qbix.com/platform/welcome/stack
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...
The standard or A standard?
It's becoming the de facto standard stack for new projects.
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.
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.