4 ms·

I'm surprised this needs jQuery. What this seems to be is a simple script that fetches a resource and places it into an element. I really feel opposed to adding

by Kequc 10y ago

I'm surprised this needs jQuery. What this seems to be is a simple script that fetches a resource and places it into an element. I really feel opposed to adding more dependencies where they aren't required. That could be written without jQuery or this library fairly easily.

xaduha 10y ago
Well, this exists http://userbag.co.uk/demo/pjax http://userbag.co.uk/demo/pjax https://github.com/thybag/PJAX-Standalone https://github.com/thybag/PJAX-Standalone
dec0dedab0de 10y ago
I am by no means a js expert, but doesn't jquery essentially act as an abstraction layer to smooth over differences in browser behavior?
- quantumhobbit 10y ago
  That was the one of the original use cases for jQuery, but browsers have gotten more compatible recently, so you may not need it anymore.
  - tmat 10y ago
    ES6+ Async/Wait make it extremely unnecessary
- tmat 10y ago
  its extremely unnecessary in ES6 w/ isomorphic-fetch and promises. In fact I much prefer what's happening in that area. Really this seems unnecessary. Async JS isn't that hard and ES6 has come a long way to solving the issues imo.
  - ryanbrunner 10y ago
    I kinda feel that a hard ES6 dependency goes against the philosophy of this tool, which is arguing for simple libraries that can be simply used for small projects without buildchain dependencies, etc. Saying "Front-end javascript is too complex, let's go back to our progressive enhancement roots" in one breath and "Requires webpack and ES6" in another doesn't jive IMO.
carsongross 10y ago
Yeah, it just evolved out of a jQuery-based set of tools. I've looked into breaking the jQuery dependency and it hasn't bubbled up high enough for me to get motivated. Always happy to take pull requests though...
andybak 10y ago
> I really feel opposed to adding more dependencies Isn't it a pragmatic technical decision rather than - what you almost make sound - rather an emotional one? There are times adding a dependency is exactly the right thing to do and times when it isn't. It's surely something that is project and situation dependent.
- Kequc 10y ago
  `XMLHttpRequest` is a bit sloppy to use admittedly, but you can encompass fetching into a simple function that's less than 10 lines long. Then, it's a matter of placing what you fetched into an element on the page. That is one line. If I do it myself I retain full control over the functionality, it's faster because fewer "kitchen sink" properties need to be evaluated. It's easier for future developers to pick up and understand. There isn't any chance that the dependency or any of it's sub-dependencies go out of date and need to be replaced. In software development there is always more than one way to do something, and this way will work today. But in what circumstance is it better? I don't want to attack this library. I'm trying to say there are too many libraries that act as an abstraction of something that would otherwise be simple to do.
  - andybak 10y ago
    > It's easier for future developers to pick up and understand. Only if your 'utility function' stays small. However my hunch is that on any real-world project over time you hit a Greenspun 10th variant* * Any sufficiently complicated 'pure' .js project contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of jQuery
    - NoGravitas 10y ago
      That evolves to be able to read email[0]. [0]: https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles

by Kequc 10y ago

xaduha 10y ago

Well, this exists http://userbag.co.uk/demo/pjax http://userbag.co.uk/demo/pjax https://github.com/thybag/PJAX-Standalone https://github.com/thybag/PJAX-Standalone

dec0dedab0de 10y ago

I am by no means a js expert, but doesn't jquery essentially act as an abstraction layer to smooth over differences in browser behavior?

quantumhobbit 10y ago
That was the one of the original use cases for jQuery, but browsers have gotten more compatible recently, so you may not need it anymore.
- tmat 10y ago
  ES6+ Async/Wait make it extremely unnecessary
tmat 10y ago
its extremely unnecessary in ES6 w/ isomorphic-fetch and promises. In fact I much prefer what's happening in that area. Really this seems unnecessary. Async JS isn't that hard and ES6 has come a long way to solving the issues imo.
- ryanbrunner 10y ago
  I kinda feel that a hard ES6 dependency goes against the philosophy of this tool, which is arguing for simple libraries that can be simply used for small projects without buildchain dependencies, etc. Saying "Front-end javascript is too complex, let's go back to our progressive enhancement roots" in one breath and "Requires webpack and ES6" in another doesn't jive IMO.

carsongross 10y ago

Yeah, it just evolved out of a jQuery-based set of tools. I've looked into breaking the jQuery dependency and it hasn't bubbled up high enough for me to get motivated. Always happy to take pull requests though...

andybak 10y ago

> I really feel opposed to adding more dependencies Isn't it a pragmatic technical decision rather than - what you almost make sound - rather an emotional one? There are times adding a dependency is exactly the right thing to do and times when it isn't. It's surely something that is project and situation dependent.

Kequc 10y ago
`XMLHttpRequest` is a bit sloppy to use admittedly, but you can encompass fetching into a simple function that's less than 10 lines long. Then, it's a matter of placing what you fetched into an element on the page. That is one line. If I do it myself I retain full control over the functionality, it's faster because fewer "kitchen sink" properties need to be evaluated. It's easier for future developers to pick up and understand. There isn't any chance that the dependency or any of it's sub-dependencies go out of date and need to be replaced. In software development there is always more than one way to do something, and this way will work today. But in what circumstance is it better? I don't want to attack this library. I'm trying to say there are too many libraries that act as an abstraction of something that would otherwise be simple to do.
- andybak 10y ago
  > It's easier for future developers to pick up and understand. Only if your 'utility function' stays small. However my hunch is that on any real-world project over time you hit a Greenspun 10th variant* * Any sufficiently complicated 'pure' .js project contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of jQuery
  - NoGravitas 10y ago
    That evolves to be able to read email[0]. [0]: https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles https://en.wikipedia.org/wiki/Jamie_Zawinski#Principles