Comment by plugnburn

10 years ago

> But even still, if you were familiar with the plugin and it would take you 5 minutes to do it that way, why not?

Because I believe these kind of things must be solved with no JS at all, let alone a bloatware lib.

> If page size or load times are excessive at some point, trim the fat then.

jQuery is THE fat.

> So many things already require jQuery

... that I try to avoid them as virus spreaders.

> a form wizard plugin

Wut?

> a calendar picker

<input type=date>

> AJAX form posting with backward compatibility

XMLHttpRequest (probably with some wrapper functions).

> and can't use FormData because you have to support those older browsers

If a thing happens we must enable front-side file uploads for unterbrowsers without FormData, then we use our custom iframe-based solution and charge the customer additionally. Unterbrowser users must suffer, as well as those who want to support them.

> because I doubt rolling your own calendar picker is the goal of the project.

All the things we need were already rolled long before the project start.

> Again, why would you build your own grid and responsive layout/break points when you can just pull in Bootstrap?

Because my grid weighs 999 bytes. How many kilos does Bootstrap weigh?

> the you're wasting your client's time and your employer's money.

Nope, because the grid is already built.

> If you're picking Bootstrap or jQuery you're not trying to enhance them. Your using them to jumpstart your project to build the parts that you need to build.

Since they don't meet my needs 100% of the time, I would end up with some modules that do the same as the ones written from scratch, but slower and with buggy underlying code. Why would anyone prefer that?

> making an AJAX request required 20 lines of code and a bunch of cascading if/else blocks to make sure which request object you were going to get

How hard is it write it once, the way YOU see fit, and then use it all your projects? Or you believe only jQuery authors are allowed to do that?

> It's a bit narcissistic to think you will always be better than what a team of people has been working on for years, but it doesn't mean you're not wrong either.

I'm not trying to be better than them. But yes, I'm trying to do _things I need_ better than they can offer.

> At the end, you bring in the overhead of code maintained by somebody else because you think it will let you finish faster, higher quality, or with features you otherwise wouldn't be able to build.

In the real world though, "finish faster" and "higher quality" are almost always mutually exclusive.