3 ms·

If you are using $ signs all over your code, they'd better refer to jquery and nothing else. jQuery has, for better or worse, become such an integral part of w

If you are using $ signs all over your code, they'd better refer to jquery and nothing else. jQuery has, for better or worse, become such an integral part of web development, the $ namespace is pretty much owned by it at this point. If you do want to use it for not-jquery, it should be something that is drastically different so someone new trying to patch a bug on prod doesn't run around in circles wondering why their code that should be working is not. The bling.js project by repurposing $ into something that looks like it might be jquery but isn't, is just a bad idea.

allendoerfer 11y ago
I think so, too. The "on" alias is great, so it might as well create an alias like "qsa", "query", or "find" on Node, that searches within its children, and on window, that searches within the whole document. I wonder, why that is not done more, after all it is one of the benefits of prototype based inheritance, that you do not have to subclass to change the interface.
untog 11y ago
It's not even a project, it's a GitHub Gist. Talk about a lot of fuss being made over nothing.
- wwweston 11y ago
  Sure, this is just an illustration. I hear Eric Meyer's normalization css was too -- more intended as a to-do list of elements you might want to consider reseting than something to include and then override. But then a lot of people ran with the idea of leveling all margins and padding with a global override to start with and then overriding that override (usually inadequately). Of course, the horse is out of the barn on the personal $ library front, so maybe Irish doesn't have to worry about inadvertently influencing people badly. There already was a no-library/micro-library trend 4-5 years ago where lots of people would write their own tiny jQuery-like DOM utilities, and I've worked on a few projects where someone used jQuery-like idioms for their partial reimplementation (I call them "nayQuery"). Even the better ones are a pain where they subvert expectations. And of course, when someone later decides to add jQuery to the project (makes sense, jQuery does more and has an ecosystem around it), now you're using $ for the custom library and jQuery for jQuery, which is disorienting. I've written my own version of what Irish presents here -- it's a useful exercise, I appreciate his contribution (helps me think about some different ways to approach it), and sometimes it's even concretely useful when you're getting started on a small project with a limited browser target where the rest of the codebase is going to be smaller than jQuery itself. But when I write something like this, I always name it differently than $.
arkanciscan 11y ago
If you're still relying on the global namespace you should stop. When I require('jquery') I'll name it what ever I damn well please, and you better get used to that because ES6 modules are here.

allendoerfer 11y ago

I think so, too. The "on" alias is great, so it might as well create an alias like "qsa", "query", or "find" on Node, that searches within its children, and on window, that searches within the whole document. I wonder, why that is not done more, after all it is one of the benefits of prototype based inheritance, that you do not have to subclass to change the interface.

untog 11y ago

It's not even a project, it's a GitHub Gist. Talk about a lot of fuss being made over nothing.

wwweston 11y ago
Sure, this is just an illustration. I hear Eric Meyer's normalization css was too -- more intended as a to-do list of elements you might want to consider reseting than something to include and then override. But then a lot of people ran with the idea of leveling all margins and padding with a global override to start with and then overriding that override (usually inadequately). Of course, the horse is out of the barn on the personal $ library front, so maybe Irish doesn't have to worry about inadvertently influencing people badly. There already was a no-library/micro-library trend 4-5 years ago where lots of people would write their own tiny jQuery-like DOM utilities, and I've worked on a few projects where someone used jQuery-like idioms for their partial reimplementation (I call them "nayQuery"). Even the better ones are a pain where they subvert expectations. And of course, when someone later decides to add jQuery to the project (makes sense, jQuery does more and has an ecosystem around it), now you're using $ for the custom library and jQuery for jQuery, which is disorienting. I've written my own version of what Irish presents here -- it's a useful exercise, I appreciate his contribution (helps me think about some different ways to approach it), and sometimes it's even concretely useful when you're getting started on a small project with a limited browser target where the rest of the codebase is going to be smaller than jQuery itself. But when I write something like this, I always name it differently than $.

arkanciscan 11y ago

If you're still relying on the global namespace you should stop. When I require('jquery') I'll name it what ever I damn well please, and you better get used to that because ES6 modules are here.