It's a fair point. I think loss-aversion over React (Native) is to blame.
Their current client stack is:
Web: React
Desktop: React + Electron
Mobile: React Native + Native
Their commitment to React on so many platforms makes it easy to accumulate bloat. Their need to support lower-level features means they can't avoid native code altogether.
I wonder why they stick with it.
My guess is they don't want to add more hires just for this problem
That's a good question. It was more an example. I am definitely interested in what model people have chosen. A concrete example is I have a cross platform personal finance app. (win, lin, mac). Its not cloud based or anything. So, I am at the point where I want to think about how to license I guess which is what inspired my question.
I started working on this project because I needed a better way to stay on top of my schedule and tasks. As a minimalist, I wanted it to be simple and smooth. I spent the next two years building the foundational features, like OAuth, sessions, Gcal sync, drag-and-drop, and recurring events.
I gave it a helluva shot, but I didn't finish making my dream calendar. But now that my code is public, maybe you can make yours. Thanks to the MIT license, you could even fork it, add your spin to it, charge for it, and grow it into a great business.All I ask is that you let me know once it's ready so I can finally stop using my Google Calendar
neat! thanks for sharing, sorry you couldn't make it shine the way you wanted.
"simple and smooth." ... "2 years" ... long feature list... Gives a kinda contradictory vibe :)
Calendar stuff gets grotty quick, we're holding a huge set of conventions and expectations so deep that we have trouble articulating them. We know what we expect from a calendar: we can see when they fail; but its difficult to visualize or explain what they should be doing instead.
Been playing with generating calendars to help me see the darkest night hours, there's lovely libraries to do all the difficult bits for me, all my data is to hand; and I'm kinda stumped at how to show it in a form that fits into those almost subconscious conventions.
Contradictory indeed -- definitely let my eyes take on more than my stomach could process.
Curious to learn more about your calendars. I don't quite understand what you mean by 'see the darkest night hours' or 'all my data is to hand.'
It sounds like you're interested in new ways to visualize calendars, compared to the traditional grids. You might enjoy checking out Lightpad or Circular calendars. They represent time in a more real form, but I've struggled to use them day-to-day.
I've got astronomical data for sun and moon rise and set, and inclination etc.
im making sofware that generates pretty html calendars displaying this in normal almanac type forms. I'm trying to make it easier to see "at glance" which nights are darkest, or when the darkness lasts longest, for things like astro-photography... or which nights are best lit for hunting.
The data is the easy part. Deciding how to show it in a way that makes sense and doesnt require effort to decode, that's hard. The sublime ease with which we read conventional calendars is amazing.
Gotcha, cool! Share a link to the project, would love to check it out. Definitely an interesting UX design challenge, combining astrological and almanac calendars
Their current client stack is: Web: React Desktop: React + Electron Mobile: React Native + Native
Their commitment to React on so many platforms makes it easy to accumulate bloat. Their need to support lower-level features means they can't avoid native code altogether.
I wonder why they stick with it.
My guess is they don't want to add more hires just for this problem
Their 2018 commitment to RN: https://discord.com/blog/why-discord-is-sticking-with-react-...
Their 2025 complications with it: https://discord.com/blog/supercharging-discord-mobile-our-jo...
reply