10 ms·

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

• joshmn 8y ago
  The one that you're most productive in.
  • mud_dauber 8y ago
    That's Rails. Which I love - but I have my doubts.
    • jamil7 8y ago
      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.
      • mud_dauber 8y ago
        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.
        • fouc 8y ago
          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 https://www.youtube.com/watch?v=SWEts0rlezA http://masilotti.com/beermenus-and-turbolinks/ http://masilotti.com/beermenus-and-turbolinks/
        • coffeefirst 8y ago
          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.
        • jamil7 8y ago
          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.
• fouc 8y ago
  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.
• joduplessis 8y ago
  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.
• polote 8y ago
  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
• 0x420 8y ago
  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.
• kenforthewin 8y ago
  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.
• tga 8y ago
  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.
• saulrh 8y ago
  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 8y ago
    You sound like you're describing https://standardnotes.org/ https://standardnotes.org/ ! (Not linked, just a happy paying user)
    • throwawaymath 8y ago
      Off topic, but it's humorous to me that the "Web" logo is simply the Chromium logo.
      • lol768 8y ago
        Arguably more depressing than humorous! I do like that there is a "download" page for the web version though, which "downloads" a 301 redirect.
      • dgzl 8y ago
        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.
• tmpfrosreponse 8y ago
  Maybe contrib to : https://github.com/paperwork/paperwork https://github.com/paperwork/paperwork (JS + Docker) https://github.com/Laverna/laverna https://github.com/Laverna/laverna (JS) https://github.com/keybits/permanote https://github.com/keybits/permanote (Python) https://github.com/Azeirah/brainstorm https://github.com/Azeirah/brainstorm (JS)
• raviatluri 8y ago
  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
• donpdonp 8y ago
  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.
• based2 8y ago
  https://turtlapp.com/ https://turtlapp.com/ https://framagit.org/framasoft/framanotes-api https://framagit.org/framasoft/framanotes-api https://framagit.org/framasoft/framanotes-js https://framagit.org/framasoft/framanotes-js https://framanotes.org/ https://framanotes.org/
• lbacaj 8y ago
  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 https://Articulu.com got it out for iOS and Android incredibly fast.
  • hwc 8y ago
    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.
    • lbacaj 8y ago
      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.
      • deleted 8y ago
        [deleted]
      • necovek 8y ago
        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)
• fisian 8y ago
  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.
  • mud_dauber 8y ago
    What are NextCloud Notes' downsides, in your opinion?
    • fisian 8y ago
      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).
• aogaili 8y ago
  NodeJS + ReactJS +or Vue with Apollo or Rest and Express and MongoJS All JS no context switching and many open source components already done.
• platz 8y ago
  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 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 8y ago
    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 8y ago
    Your app reminds me me of Pinboard.
• ClassyJacket 8y ago
  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.
  • mud_dauber 8y ago
    Exactly. I end up pinning & unpinning notes to do this. Painful indeed.
• pizza 8y ago
  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
• LeanderK 8y ago
  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.
• lighttower 8y ago
  What features and improvements currently lacking in keep are key deliverables for you?
  • mud_dauber 8y ago
    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
• miguelrochefort 8y ago
  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.
  • Jimskapt 8y ago
    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 https://jimskapt.github.io/lambda-badger, and source is here : https://github.com/Jimskapt/lambda-badger https://github.com/Jimskapt/lambda-badger
• maxxxxx 8y ago
  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.
  • mud_dauber 8y ago
    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.
• EGreg 8y ago
  This is what we chose to use after surveying what is by far most deployed in the wild: https://qbix.com/platform/welcome/stack https://qbix.com/platform/welcome/stack
• ummonk 8y ago
  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...
  • chooseaname 8y ago
    > Standard tech stack: React+Apollo+Redux+GraphQL (with Typescript). The standard or A standard?
    • ummonk 8y ago
      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.
  • iaml 8y ago
    Why not apollo-link-state instead of redux?
    • ummonk 8y ago
      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.
• burtonator 8y ago
  You could take a look at what I'm building with Polar: https://getpolarized.io/ 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.
  • snazz 8y ago
    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.
    • burtonator 8y ago
      oh yes.. they're different. I agree.
  • kowdermeister 8y ago
    Ok, enough. I'll try your app now :)
  • ibnishak 8y ago
    Just letting you know, if you ever build a android app, I will download the paid version happily.
• spinningslate 8y ago
  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 8y ago
    Interesting. I just spent a couple of weeks learning Elixir & really liked it. Any disadvantage to doing the backend work in Elixir instead?
    • spinningslate 8y ago
      > 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.
• sidcool 8y ago
  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
• kowdermeister 8y ago
  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/ https://ant.design/
• tln 8y ago
  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
• oyebenny 8y ago
  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.
• PascalW 8y ago
  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 8y ago
    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?
    • PascalW 8y ago
      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 https://github.com/OvermindDL1/bucklescript-tea [2] https://esy.sh/ https://esy.sh/ [3] https://github.com/reasonml-community/bs-react-native https://github.com/reasonml-community/bs-react-native [4] https://github.com/revery-ui/revery https://github.com/revery-ui/revery [5] https://dev.realworldocaml.org/ https://dev.realworldocaml.org/ [6] https://discord.gg/reasonml https://discord.gg/reasonml
• wtmt 8y ago
  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 8y ago
    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.
• CalmStorm 8y ago
  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.
  • handzbagz 8y ago
    I've used this before which fits your bill: https://clipperz.is https://clipperz.is. Quite an interesting app and you can download and offline copy of your notes too.
• tokyodude 8y ago
  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.
  • Andrex 8y ago
    Meteor was amazing for this but unfortunately seems to be on its way out.
    • MegaLeon 8y ago
      What makes you say this?
      • Andrex 8y ago
        That Meteor seems to be dying? Some good answers on HN here: https://news.ycombinator.com/item?id=16782266 https://news.ycombinator.com/item?id=16782266
• Geee 8y ago
  Firebase for authentication + realtime multi-user database. Frontend can be anything that works with Firebase.
• goloroden 8y ago
  For the backend I'd use wolkenkit, a backend framework for JavaScript that lets you build backends very quickly: https://github.com/thenativeweb/wolkenkit https://github.com/thenativeweb/wolkenkit To get started, you find everything you need in the documentation, see https://docs.wolkenkit.io/3.1.0/ 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 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.
• avip 8y ago
  Start by browsing numerous existing os tools on GitHub.
• rakoo 8y ago
  I'd take inspiration from tiddlywiki (https://tiddlywiki.com/ https://tiddlywiki.com/). It already has much of what you need and is open-source. No need to start from scratch
  • paulirish 8y ago
    +1. tiddlywiki is exactly what I was about to recommend.
  • mud_dauber 8y ago
    Downloaded. This is promising, TY!
• woolvalley 8y ago
  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.
• vbo 8y ago
  Don't worry too much about the tech stack. Use whatever you're comfortable with.
• glenrivard 8y ago
  Flutter
• pier25 8y ago
  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.
• partingshots 8y ago
  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...
• thwave 8y ago
  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 https://en.wikipedia.org/wiki/Bi-directional_text
• kokokokoko 8y ago
  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.
• brobdingnagians 8y ago
  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
• james_s_tayler 8y ago
  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 https://youtu.be/Yx6k6WR8GRs
• emilfihlman 8y ago
  Backend: nginx, sqlite or postgresql and Your Favourite Language for logic Frontend: vanilla html5, css and js
• aboutruby 8y ago
  What would I use? Rails + React
• aqw137 8y ago
  FE: vuejs (PWA), BE: PHP Laravel, I would be interested in working on a backend if it would be this stack :)
• AHTERIX5000 8y ago
  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).
• zmix 8y ago
  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.
• slifin 8y ago
  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
• rco8786 8y ago
  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.
• developit 8y ago
  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.
• leksak 8y ago
  What features are you missing?
• sAbakumoff 8y ago
  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.
• tmaly 8y ago
  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.
• BerislavLopac 8y ago
  I'm a happy user of https://simplenote.com/ https://simplenote.com/, if it helps.
• bobbydreamer 8y ago
  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 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.
• screye 8y ago
  > 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-google-keep/bmfmbanhkhjhfeckobkcecohknhlnamb?hl=en https://chrome.google.com/webstore/detail/input-tab-in-googl... https://chrome.google.com/webstore/detail/category-tabs-for-google/dlahcjmefibiedeecoegjilekaebchhl?hl=en https://chrome.google.com/webstore/detail/category-tabs-for-...
  • mud_dauber 8y ago
    Thanks. I'm a (fairly) heavy user of category tabs.