To each his own. You are developing this by yourself (AFAICT) and are the only one working on it. Don't let people tell you the right/wrong way to do it, do what works FOR YOU.
Me? I like frameworks, I use them daily at work, I'm familiar with them, and I'm comfortable with the tradeoffs. I think in a multiple-developer environment you need to standardize things and a framework is ONE approach to that. I think it's the best approach in a shared environment but I'm not going to be so cocky as to tell you what the best approach is for you.
I mean reading about your experience with modals made me cringe a little (at how long it took) but hey, you didn't have to lean Angular/React/etc so you probably came out ahead so who am I to judge? Focus on what makes your business successful, for you that is clearly NOT the web UI (not meant as a dig) so don't waste your time using the New Hotness (tm). Instead work on making your API servers rock solid and adding features.
A User is NEVER going to come to you and say "I'd use your product but you used vanilla JS so I went somewhere else" they will say "your site doesn't work in X browser", "Your site is ugly/inconsistent" (I don't think this about your site), "Your API is slow", "I need to be able to filter my time series on X but you only allow for Y". NONE of these problems are fixed with a framework alone and fixing them with a framework brings it's own set of issues.
You do what works for you and clearly this seems to work. Keep it up!
PS: I'll have to keep Pushdata in mind for future side projects, looks pretty cool, this is the first I've heard of it.
Trying hard to find something to disagree with in your comment, but no luck :) Seriously, I think I did at least mention in the blog post that the vanilla approach is something I'd mainly advocate for small projects, with few members. The kind of situation where I am myself, at the moment.
The thing is, I see so many reach for the big guns and over-engineer their new, tiny app that they're developing themselves, with a friend or perhaps a small team. And I see overuse of components in general - the tendency to just pull in a new dependency via npm for something completely ridiculuous. This post was not about big, in-house enterprise systems development.
And in fact, thinking about my experience from that financial company mentioned earlier, I would greatly have preferred a standardized, external framework before the in-house developed macro/library mess that worked but was pretty much undocumented and whose inner workings were known to a very small number of people.
> The thing is, I see so many reach for the big guns and over-engineer their new, tiny app that they're developing themselves, with a friend or perhaps a small team. And I see overuse of components in general - the tendency to just pull in a new dependency via npm for something completely ridiculuous. This post was not about big, in-house enterprise systems development.
Because it is much more reassuring having a community back you up in case you get into the edge cases.
DIY? Good luck, you are on your own. Not to mention you have to scaffold all the things that are already taken of by the framework.
It's also a matter of maintainability. If you can successfully predict that the project will always be small, then fast, bespoke code might be great. But it's usually not the case. Prototypes almost always turn permanent.
> Because it is much more reassuring having a community back you up in case you get into the edge cases. DIY? Good luck, you are on your own. Not to mention you have to scaffold all the things that are already taken of by the framework.
And once you're reasonably familiar with a framework it would make sense to use it even for a prototype. Unless you're actually interested in trying out "VanillaJS" or an alternative framework you would just use the tools you already know and get on with the problem you're trying to solve :-)
One reason people reach for the "big guns" is also career progression. Hell, I started learning React recently precisely because of that: I prefer to touch the Web as little as possible, but everything is now eaten by SPAs, so one may as well just bite the bullet and get ready for the next job... The same reasoning currently motivates all but one of my backend co-workers, they're all learning React now. At my previous job (backend/desktop), people too started to learn Angular and React, just to jump on the (perceivably) safer, and much better paid, career path.
Me? I like frameworks, I use them daily at work, I'm familiar with them, and I'm comfortable with the tradeoffs. I think in a multiple-developer environment you need to standardize things and a framework is ONE approach to that. I think it's the best approach in a shared environment but I'm not going to be so cocky as to tell you what the best approach is for you.
I mean reading about your experience with modals made me cringe a little (at how long it took) but hey, you didn't have to lean Angular/React/etc so you probably came out ahead so who am I to judge? Focus on what makes your business successful, for you that is clearly NOT the web UI (not meant as a dig) so don't waste your time using the New Hotness (tm). Instead work on making your API servers rock solid and adding features.
A User is NEVER going to come to you and say "I'd use your product but you used vanilla JS so I went somewhere else" they will say "your site doesn't work in X browser", "Your site is ugly/inconsistent" (I don't think this about your site), "Your API is slow", "I need to be able to filter my time series on X but you only allow for Y". NONE of these problems are fixed with a framework alone and fixing them with a framework brings it's own set of issues.
You do what works for you and clearly this seems to work. Keep it up!
PS: I'll have to keep Pushdata in mind for future side projects, looks pretty cool, this is the first I've heard of it.