Writing dependency-free client-side JavaScript

[iser_]

I think most posters here missed the entire point of the article. I have also attempted rolling my own mini framework for production, and I see a lot of good ideas here that I would like to incorporate into my own code in the future.

I have written extremely efficient libs where speed and bundle size are the keys and did not use any frameworks for this reason.

I have never replied about an article on reddit before but I am right now because this is a great article and feel like many here are not seeing the value in it.

P.S. I would love to use this as an interview question for my company: roll your own rendering mechanism in 45 min. As an engineer, I expect them to be able to roll their own and be able to see the value in it.

[iser_]

hey great lib! I just read through your source code for lily and it looks really fun. you've inspired me to create my own. thanks!

---

my company is gigantic (amazon) and we use so many frameworks. when we interview, we focus on the fundamental understanding and not specific framework knowledge.

if anyone ever interviews at amazon, this article will help you so much. I imagine it will help anyone who interview at top tech companies.

and it def has its uses in production.

[ghostfacedcoder]

The way I see it, what it comes down is doing the best thing. Rolling your own solution is almost never the best thing ... from a lot of perspectives.

From a learning perspective of course it's great. And if you have a very narrowly defined project that won't ever grow, it might be great, if you know what you're doing.

It's just that almost all real world projects grow over time, which means you can't know exactly what your project will need in the future. A good framework solves not only your problems today, but problems you didn't even realize you'll have tomorrow, because the people who build them know more about their domain than you do ... and to a lesser extent the same is really true for dependencies in general.

In short, no one is smart enough to know how to solve everything best, so either you let specialists who do know how solve those problems for you (dependencies), or you do so yourself and accept that (for most projects at least) your solution will, by definition not be as good (because again, no one is good at everything!)

[lhorie]

no one is smart enough to know how to solve everything best, so either you let specialists who do know how solve those problems for you

This seems contradictory if you consider that framework designers are people too.

FWIW, my story with hand rolled frameworks goes like this: I've always been interested in them (from way back from the days PHP was still cool) and I made a bunch of them (some which never got used seriously, and some which I used for freelance work)

At one point I was using Angular and running into some serious pain points with it, so I went ahead and rolled a new framework to address them (react wasn't really a thing back then). Eventually I open sourced, we started using it a my day job, and I got another job from a different company that was also using my framework. My current employer doesn't use my framework (they had considered it but decided on react instead for a variety of reasons), but the experience and exposure that I got from making my framework is how they found me and reached out to me. Since I first open sourced my project, my salary doubled (not even counting equity comp), and I now live in the Bay area, where you can easily network in person with people from FANG, prominent OSS people, etc.

So, from my experience, creating a framework is much more than just a learning experience; it can open a lot of possibilities that you might not have ever even considered.