Comment by omarhaneef | Hacker News Reader

Comment by omarhaneef | Hacker News Reader

Lots of interesting ideas in this -- well worth the read -- but in the competition for most productive paragraph, I would guess the following would win:

"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."

I've been using my own super minimal unit testing framework for all of my personal projects for about 2 years (https://gitlab.com/distilled/distilled/tree/develop). It's designed to be very flexible, and very, very fast to get up and running -- for new projects I want to be able to start writing unit tests within 30s to a minute after calling `npm init`.

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.

I've been toying with the idea of creating my own lightweight JS and CSS framework so I can achieve similar levels of productivity. I know it varies between people but I find using third-party frameworks slows me down more often than not when I want to quickly build something.

I wonder if it is faster to learn a tool deeply than to build your own.

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

I would imagine rolling your own also puts you at significant risk of being distracted by yak-shaving.

I am currently in the process of doing something similar: https://github.com/CarlMungazi/aprender-js

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.

Boy have I got a treat for you -- or maybe not if you're very knowledgeable in the space -- but this is an amazing course for walking you through the main functions of a framework and the code for some major frameworks:

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.

Nice - will check it out if I ever get the time.

I think there's truth to both. A great example of the second kind is Chrome Devtools (or firebug, or insert-other-browser-equivalent-here, but I think Chrome leads the pack here). Chrome's developer tools is a gold mine of incredibly useful tools for profiling, measuring, and understanding complex frontend applications, and most developers only use a tiny fraction of the features it offers. Learning devtools deeply has been one of the most worthwhile investments of my time in my short dev career.

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.

Reply on news.ycombinator.com