How I Side Project
dotink.co
dotink.co
"Having built a variety of apps, I now have some template or framework that I can copy from a previous project when I start almost anything new. I use Torus, my frontend framework, for all my web projects, and I have a template I copy for my backend projects and static sites. I have a lightweight slap-on CSS library for making things look good with low effort with blocks.css, and these templates and copy-paste snippets make getting started super quick, even with fairly involved projects. I was only able to release RecruitBot in 6 hours because I could lean on both my frontend framework and a backend I copy-pasted from Studybuddy, and because I could easily deploy it on a server I had available for my projects. This might not be the most glamorous approach to starting new projects, but it gets me up and running quickly with a new idea, and that matters more than anything at the start. Having these battle-tested tools that I’ve used over and over again within easy reach has been the single most helpful thing in being able to push out MVPs and prototypes quickly."
As far as I know I'm the only person who currently uses it, but it's saved me so much time that even if I'm the only person who ever uses it, it'll have been well worth the effort I spent writing it.
I'm working on a similar project for documentation generation (https://gitlab.com/dormouse/dormouse/), and I expect that to be the same deal -- I'll probably be the only person who uses it, but I don't care because it'll pay for itself just from the time it saves me.
Part of the advantage of having your own frameworks that you tightly control and understand is that they can be more specific to what you need. It's a tough balance -- I don't advise people to constantly reinvent the wheel, but occasionally existing wheels are really badly designed (looking at you esdoc), and in those cases it's often less work to reinvent the wheel than it is to use a misshapen wheel forever.
The advantage of building your own is that you are forced to go over every piece of it. However, if there was a way to do that for a pre-written tool -- say, rewrite things more efficiently, or just use it in weird ways -- it might be faster to learn than build.
The reason it would be faster/better to learn a tool deeply is now you have more than one mind working on the problem. Your own and all the other geniuses out there working on the tool. And the tool can be simple. (Just use Torus, for instance).
But the reason I lean towards build-your-own is that, especially for libraries and dependencies, popular tools that are "production-ready" also tend to aggregate over time features that everybody wants, but might not be useful to me personally -- it's hard to stay focused while growing to be the dominant tool in the industry. And that also makes it difficult to understand it completely. I think I understand React _well_, but wouldn't dare say I understand it completely; I can confidently say I understand every single line of Torus, because I maintain all ~1000 lines of it. And that makes it easier to stay in "the flow" when working.
Once I'm done, I'm probably going to have a proper crack and either building my own tool or collating smaller libraries (and by small I mean they do one thing only and do it very well) into a toolkit I can build stuff very quickly with.
I think the knowledge gained by building your own tool (CSS library, UI framework, state management library etc) seeps into any work you do with other tools or programming in general. It also depends on your aim. You will be more productive using whatever approach you spend time learning deeply.
https://www.udacity.com/course/front-end-frameworks--ud894
I am not associated with Udacity, but I love them so much I promote them every chance I get.
The things that stand out for me in staying sane working on them, and occassionally getting them done are
1. the most important thing: prototype end-to-end user workflows to prove out that the idea is a good one AND that it's technically possible -- you'll discover lots of technical issues you'll need to go solve when do this (put them in the to-do list mentioned later). Don't over-design anything at this point. Just make it work. Be okay with rough code or experiences. Get the idea working and it'll be a great motivator. Likewise, if you get a rough experience working and realize it's not a great idea, you can move on and do something else!
2. make the project easy to leave and come back to (see next two items).
3. create TODOs.md markdown file in the project and just add items as you go along. This is your source of truth of what to work on next. Don't use any fancy task-tracking service or app, just a simple markdown is good enough. And it should live with the project so you can read it and see what's next.
4. always have a "next task" that you are working on. Don't focus on too many tasks at once b/c you will get overwhelmed and give up. When you are looking for a fun design to think about when you're going for a walk, you can think about this next task.
5. be okay with leaving the project for a while (months, or years). You can always come back to it if you want.
6. don't stress about how quickly you're making progress. Do it for fun.
I'm the only user for almost all my projects though.
They talk about not having unit tests, or CI/CD, etc.
If functional utility is found you'll continue to garner an audience. Otherwise you're polishing something people don't want/need.
Heard of Calendly?
> “Gestural”, a JavaScript library for making multi-touch gesture recognition easy on the web.
Heard of Hammer.js?