3 ms·

I must say it's a valid point. After all it's a hobby project, having fun is the first priority :D However, one could also say "Well, it's a hobby project, so

by nirui 5y ago

I must say it's a valid point. After all it's a hobby project, having fun is the first priority :D However, one could also say "Well, it's a hobby project, so I'll just slap this framework on to save my time..." or "What? I have to manually deploy this hobby thing every time I made a change? I'll just put it on a CI and let Webpack pack the thing for me"... My method is this: I will start the project with all new tech/frameworks/lib/"display: grid", then I publish the project, if it turns out to be a success, I'll maintain it (including upgrade the framework, bug fix etc); if it's not, I'll just put it aside and start another one. This way, I can touch/learn many new stuffs that might later benefit me in my day job without any risk. So, I believe it eventually boils down to personal preference (based on objective information on hand, of course) :D

MereInterest 5y ago
Makes sense. For me, I like to get hobby projects for my own personal use. The "publishing" involves pushing it to github, then doing absolutely nothing additional with it. But because I use it on my own, I may want to add more features to it later. For frameworks, I'm sure they save time once you are familiar with them, but that also requires evaluating which frameworks to use and how to go about using them. That ends up taking a lot more time than throwing something together with plain JS. That definitely makes sense, especially if you're using the hobby projects to learn about frameworks that you'll later use elsewhere. I tend to do the same thing on the compiled side, trying out different libraries and languages. (For example, picking up Rust for last December's Advent of Code challenges, then porting some of my other projects over to make some performance comparisons.) Part of this is also that my dayjob has very little interaction with JS. If/when I use JS in my dayjob, I'm usually picking something minimal so that it can be used/expanded on by others without framework-specific JS knowledge. My goal is to make sure that I leave behind a codebase that can be read/understood by as many people as possible, which may mean picking a software stack that has a bit worse usability, in exchange for ease of finding developers.

by nirui 5y ago

MereInterest 5y ago

Makes sense. For me, I like to get hobby projects for my own personal use. The "publishing" involves pushing it to github, then doing absolutely nothing additional with it. But because I use it on my own, I may want to add more features to it later. For frameworks, I'm sure they save time once you are familiar with them, but that also requires evaluating which frameworks to use and how to go about using them. That ends up taking a lot more time than throwing something together with plain JS. That definitely makes sense, especially if you're using the hobby projects to learn about frameworks that you'll later use elsewhere. I tend to do the same thing on the compiled side, trying out different libraries and languages. (For example, picking up Rust for last December's Advent of Code challenges, then porting some of my other projects over to make some performance comparisons.) Part of this is also that my dayjob has very little interaction with JS. If/when I use JS in my dayjob, I'm usually picking something minimal so that it can be used/expanded on by others without framework-specific JS knowledge. My goal is to make sure that I leave behind a codebase that can be read/understood by as many people as possible, which may mean picking a software stack that has a bit worse usability, in exchange for ease of finding developers.