[mklim]

>The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building.

Strongly disagree.

Your hand-rolled framework is undocumented besides whatever comments you've put in your code, full of bugs besides whatever you've personally stumbled into, and lacks anything except the features you've needed thus far. It's a means-to-an-end to get the actual features you need done done, instead of built for its own sake and tested and polished for its own sake.

The second your application grows in an unexpected way, you need to augment the entire framework to suit. If there's a bug, you can't search stackoverflow or the github page and just read the answer that 500 other people have found before you, and neither can anyone who has to take over the code after you and try to maintain it--you are the sole author, your internal comments and notes and email chains are all the documentation for the framework that exists in the entire world, there's no hope for the maintainers besides slogging through the source and discovering the solution from scratch. There is no cheerful dev community contributing PRs for the buggy edge cases that break your code on obscure browsers. There's no helpful blog posts out there on how to tweak it for performance optimization. It's all just you trying to maintain what really should be its own full time project while you're trying to build a real product on top of it at the same time.

IME, hand-rolling your own framework as you're building a product gets you the bare minimum (read: extremely poor) mess of code that could possibly address your core use case, not something good for your specific problem. Using multiple libraries instead of monolithic frameworks I think is generally a good idea, depending on context--but completely hand-rolling your own framework from scratch while you're actively developing a product, no, I've never once seen this work well.

[treehau5]

> The second your application grows in an unexpected way, you need to augment the entire framework to suit

The second you need to do something your framework doesn't, the same rule applies. Frameworks are really good for covering most things, but almost everyone runs into that last 5-10% or so that it doesn't do. That ends up being the most difficult, in my experience.

[jakub_g]

To be a devil's advocate: That's true, but still it's the last 10% that is hard when using a well-known framework, compared to 100% when you handcraft everything in a basement.

If you use a well-known fwk, you can tell junior devs and new devs to google stuff when in need (as a first line of help), otherwise, you need to write a ton of documentation and/or devote hours per week on support, at the times when you have the least will to do that.

There's no one-fits-all solution, depends on the project, team, constraints etc.

[treehau5]

> To be a devil's advocate: That's true, but still it's the last 10% that is hard when using a well-known framework, compared to 100% when you handcraft everything in a basement.

I am saying they are about the same. The last 10% is about as much work as bootstrapping a specific solution.

The new junior dev point is irrelevant if you stick to plain vanilla javascript, and hire junior devs that actually know javascript. Your devs should know how to read code and tests.

> otherwise, you need to write a ton of documentation and/or devote hours per week on support, at the times when you have the least will to do that.

No I don't.

Junior dev: "hey how does this work?" Me: "Did you run the tests?"

[dismantlethesun]

Whilst this may be true in general, I find that when it comes to Javascript, things are already so sandboxed and reliant on the DOM api, that there's little you can do to shoot yourself in the foot.

At worst, your site won't be cross-browser compatible, but it's not like it's serverside where the framework is legitimately doing heavy lifting in a high performance environment.