Hacker News new | past | comments | ask | show | jobs | submit login

"You might not need Ruby on Rails. Use C to rewrite tons of shit you need."

Use jQuery please.

Rewriting jQuery methods with vanilla js usually turns out to be a hack job that is buggy and ugly. Just use jQuery.




That's a really bad analogy.

People don't use Ruby because C's standard library works differently across different platforms.

This isn't about "rewriting jQuery methods with vanilla js". It's about using the built-in, native, vastly more performant methods that come standard on modern browsers.


The analogy is even worse because Ruby changes way faster than C :)

But anyway, writing code in any 'lower' layer is very educational.


This is exactly what we're trying to combat. For modern browsers, in many cases, it's just not true. There are a few utility methods that are tricky to replace, but you really shouldn't be including jQuery only for it's utility methods.


jQuery provides a uniform API that is guaranteed to work on supported browsers. The jQuery team does all the work to back that guarantee. If I rely on raw JS, then I'm one glitchy browser implementation away from being broken.

Even worse: suppose you build a product with the approach you recommend, it's very successful, and then your sales team makes a major sale to a stodgy old bank that still uses IE7. Or maybe you just never make the sale because you don't support the browser they use.

OK, let's say we should all turn away money from IE7 users because it's insecure and old. For OP's strategy to work, we have to assume all browsers we care about will be compatible going forward. I think this is a very unsafe assumption to make. While one small incompatibility would only be a minor annoyance, once you have more than a handful of these, a compatibility layer like jQuery again looks very nice.

And none of this even speaks to the fact that the jQuery implementation in the source article is generally at least as short and readable as the alternative, or that most people are more familiar with the jQuery version.

The only reason I can think of for dumping jQuery is maybe speed optimization, and even in that case, well-implemented jQuery should be no slower than the native speed plus the cost of a function call. If it's slow and you want to optimize something, why not optimize/bug-fix jQuery itself and help everyone, not just your one project?


I think your analogy is flawed because it seems like you're essentially taking an extreme on the opposite end from what you are sarcastically mocking.

I wouldn't call myself "old school," "hard core" or anything like it, but I just don't see what's so difficult about--or wrong with--replacing any library with "ad hoc" code that accomplishes a small subset of the library's functionality if the majority of the library's purpose is to provide that small subset. "Small", of course, is relative and context dependent.


Rewriting jQuery methods? If you can do it natively, and succinctly, why would you load a library abstraction to begin with?




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: