Hacker News Reader

Comment by Touche | Hacker News Reader

Rather than using a library with a bunch of utility functions that you may or may not need, using individual utility functions indeed does seem like a better idea.

For example, I don't support browsers without classList, so I don't need your regexp stuff. Maybe you do, but my code shouldn't be larger because of that.

View on HN

Problem now is that you get to write, test and maintain all this instead of using something that has a whole community backing it.

Most of these utility functions are fairly straightforward and will rarely require any changes or maintenance. Testing should therefore be straightforward as well. Having the whole community back something doesn't mean it's bug-free, and sometimes it makes it harder when their release cycle isn't as frequent as you'd like it to be.

Having said that, it's all about tradeoffs. Whether your project needs something as big as <insert JS framework or lib here> or if you can live with just needing a few utility functions, you make those choices, doesn't mean one is better than the other as it all depends on context and situation.

jQuery has become the defacto must-use library for javascript now which IMO is unfortunate, as a lot of sites and apps include it when they barely use most of what jQuery offers. I'm guessing most use jQuery for only a few things - Ajax, DOM querying, and events. I hope that sometime in the future jQuery would be more modular.

If you search for classList on npm you get a half dozen results. I disagree with your assessment here.

Dead code elimination (i.e. UglifyJS) should do away with most unused code from a library - so with a proper build system this shouldn't be a big concern...

I don't think you'll find UglifyJS's dead code elimination to do the type of tree shaking that'll remove jQuery's unused functions.

What if one wants to keep things simple with a minimal/nonexistent build system?

I haven’t done serious web work in ages but if I did I’m quite sure I’d find all of today’s “required” build tools quite frustrating.

And yet by "keeping it simple" you have to re-write and maintain a bunch of utility functions that are solved problems.

If it's for some gain, then why not. It's a trade off decision.

If they're solved problems, what difference does it make what form and package they arrive in?

You say that as those jQuery is the only place you can get a addClass function without writing it yourself. It isn't.

Not at all, OP said "if one wants to keep things simple with a minimal/nonexistent build system" which would exclude the easiest ways to get one-off utility functions.

Wouldn’t this be an argument for adding those solved problems to JavaScript as like a standard library? I’m not a web developer by day so forgive me if I don’t know all the nuance of JS but I feel like what you would consider it’s “standard” functions is quite small.

That is generally the long term solution, and the reason this website is saying jQuery is no longer needed (because modern browsers offer a much better and more consistent foundation). The problem is the short term. While waiting for browsers to catch up and add new things, we usually have to polyfill, hence this debate.

For what it's worth, it already is.

https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

Builtin functions for adding, removing, toggling and querying classes on elements.

It won't. UglifyJS's dead code elimination is snake oil and mirrors anywhere but in the most trivial of cases.

See:

- https://github.com/webpack/webpack/issues/2867

- https://github.com/webpack/webpack/issues/4784

(Note: webpack doesn't do any dead code elimination, it relies on UglifyJS to do so)

Those are good links to interesting discussions on the topic, I guess UglifyJS is better than nothing although you're right there.

Are you aware of any alternative that can do tree shaking? Reading those issues' comments there is a link to babel-webpack-tree-shaking [1] which seems to do it?

[1] https://github.com/Aladdin-ADD/babel-webpack-tree-shaking

Rollup [1] seems to be pretty good at tree-shaking and apparently babel's babili minifier [2] is better than UglifyJS (but I guess it's too early to tell)

But both come with their own tradeoffs: Rollup is ES6 only and doesn't support certain features from TC39's Stage 3. Babili is very very new :)

[1] https://rollupjs.org

[2] https://github.com/babel/minify

Reply on news.ycombinator.com