Vanilla JS version

[zslabs]

What kind of issue is this? (put 'x' between the square brackets)

• [x ] Question. This issue tracker is not the place for questions. If you want to ask how to do something, or to understand why something isn't working the way you expect it to, use http://stackoverflow.com/questions/ask . Provide working code, starting from http://codepen.io/marcandre/pen/jqbzyN?editors=101. We monitor the tag parsley.js.
• [ ] Bug report. If you’ve found a bug, you must provide a minimal example in a CodePen, starting from http://codepen.io/marcandre/pen/jqbzyN?editors=101 .
• [x] Feature Request. Make sure there's no good way to do what you want first; consider asking on http://stackoverflow.com/questions/ask first.

Hi, Are there any specific features tying this to jQuery nowadays? Is there any interest in converting this to a vanilla JS version?

[marcandre]

To be very honest, I don't know for absolutely certain, as I never write JS without jQuery, so my knowledge of vanilla DOM is very limited.

I personally have zero interest in a vanilla parsley. Let me try to me more explicit about why.

I don't personally write without jQuery and I don't plan to. Nor do I write in HTML, ES3/5, or in CSS for that matter. I consider HTML, JS, Dom & CSS like assembly language, a platform to target but requiring an essential layer that provides a decent interface to them (slim/Haml, CoffeeScript/ES6, jQuery & Sass/less respectively). Of course that's a personal opinion, but hey, as the only active maintainer, it counts :smile:

More practically, from my limited knowledge: I don't know at which version of IE one could start adding attributes to native objects (ideally without memory leaks). We use jQuery data so that's a solved issue for us, so we can support IE8+.

Parsley makes extensive uses of promises, although we could use ES6's instead. It uses $.ajax, which has a much nicer interface in jQuery than the vanilla equivalent, but again that could be kind of done "manually".

More importantly, there are two things that can't be done reasonably without jQuery to provide easy options:

Config of ajax

It wouldn't be reasonable to provide compatibility with ajax options and ajax validators for the remote validator. These are jQuery specific and are not easy to duplicate.

Selectors.

These selectors are way more powerful than what querySelectorAll can accept. Firstly, some nice builtin jQuery selectors are not supported, but secondly you can write your own jQuery pseudo-selectors. That's a really nice API that one can use, for free. We could provide the possibility for the user to write a callback instead of a string for more complex cases, but that is not nearly as nice would make parsley heavier.

I think that's sums it up.

[zslabs]

Hey @marcandre appreciate the reply.

I can certainly understand keeping the library within your comfort zone; as that's the most important thing 😏

In terms of some of the nicer utilities jQuery offers, I'm sure you've also noticed a lot of the movement around the BabelJS project; which makes a lot of these a non-issue on compilation. Furthermore, the Polyfill.io project has also made it possible to automatically polyfill older browsers, while allowing you to write in native/future technologies and keep your codebase clean. Think of it like Autoprefixer for JS, but even better. It also makes things like fetch a possibility to work around some of the AJAX items you mentioned.

While I've personally been able to move past jQuery without any issues, I'm not on the "jQuery is evil so everyone that uses it is wrong" boat. I very much respect your thoughts on the subject and have appreciated using the library over the years. For me, it's just one of those items that's causing me to load jQuery when it's the only thing that's required for it on my site. Parsley is just so darn convenient 😄

BTW, this is my absolute favorite way of looping over DOM nodes in a more "jQuery like" way:

function forEach(array, callback, scope) {
  for (var i = 0; i < array.length; i++) {
    callback.call(scope, i, array[i]); // passes back stuff we need
  }
}

[marcandre]

I was not aware of polyfill.io or of fetch :smile:. Pretty nice stuff. Great replacement for $.ajax, so it does mitigate my biggest objection.

So I'm starting to feel like it would be possible to have Parsley be compatible with a choice of either jQuery or polyfill.io's fetch and other.

Not really relevant to the discussion, but I feel your forEach is not needed in ES6...

So I'm reopening this and will see about writing a roadmap. kickstarter?? :smile:

[zslabs]

Sweet! It'd definitely be a switch; maybe worth a major version change, but if you wrote Parsley in a way that took advantage of the today's powerful utilities, then you probably stick within the same browser support range if you mentioned by default what was supported, but "with polyfill.io, supports back to whatever".

[marcandre]

AFAIK, fetch is not currently supported on any browser, so I guess it could be a choice of

• jquery
• polyfill.io
• very recent browser and not using remote validators.

Unsure about releasing this as v3, it could in theory be part of the 2.x line.

[zslabs]

IMHO it's more of a documentation challenge. Browser support is okay, but if you mentioned that you could include polyfill.io if you needed older browser support, that would allow you to negate any supports checks and just write natively.

[marcandre]

Mmm, we use promise.state(). Native promises do not give access to that.

Current processing is quite nice. Handle every validations as promises, combine them, etc..., to implement whenValid and whenValidate. The methods isValid and isValidate simply call those and inspect the state of the resulting promise. I don't see an easy way keep doing this with native promises :cry:

[zslabs]

Not that I'd personally want a whole library integrated for this piece, but does BluebirdJS help us at all here?

[marcandre]

Bluebird has a sync API, so yeah that would help, but I'm not sure much is gained.

This discussion led to a very long discussion with the jQuery people, and they changed some of the processing for v.3.x that should make compatible with Parsley, although I still need to double check that

[zslabs]

Ha well I guess that's good for the jQuery version ;) Is this Promise situation all that you think stands in the way?

[pazams]

just my 2 cent: IMO a validation library should support async validators. Letting the user write a custom async validation rule, using whichever ajax api/library/module he wishes.

[zslabs]

Would ES6 Generators help control the flow of these requests?

[marcandre]

@zslabs not really

[zslabs]

Do you think creating a vanilla-JS branch and making broadcasting a call-to-action for help in converting could help spur some thoughts into any of the roadblocks that we may be facing to see if there's some workarounds?

[marcandre]

Are there still people interested in this? I've put down my ideas on how to do this. I could lay down the ground work for this, and would handle the most delicate part (promise combining) but would very much like help from others. Anyone can commit to serious collaboration effort?

[zslabs]

I can help with a lot of the pure syntax-related swaps, but some of the deeper API changes may be outside of what I can dedicate time to right now.

[Flaburgan]

@marcandre I'm still very interested about it but have no time to contribute at the moment, sorry.

[marcandre]

I've started to convert some jQuery calls to use the native DOM. PRs welcome (post here first on what you intend to do...)

[herberthenrique]

Hey @marcandre, I decide to give you a little help :) (I really want this feature)

I'm opening a PR now to remove jquery from one of parsley's files. :)

[DanielRuf]

Bump. I could also help.

[marcandre]

@DanielRuf PRs welcome. Ideally keep commits small, and don't hesitate to ask for help if you're unsure of something.

[DanielRuf]

Would be better to move this project to an org.

[marcandre]

Would be better to move this project to an org.

Probably, but since I'm the only active maintainer and that Guillaume is quite responsive to the very rare admin changes that need to be made, the current setup has never been an issue. If any further discussion on this topic is required: new issue please!

[Seebiscuit]

Hi. I'm looking at Parsley.js for my project and I'm interested in a jQuery-free version. I don't need it right away and can start using the library right away with the jQuery dep. If there is a firm roadmap to drop jQuery, I'd be happy to contribute. Please, advise on the current status on this ticket.

[marcandre]

I'm involved in other OSS projects that are my priority, so unless I am sponsored for this, I'm afraid I won't be working on it myself in the foreseeable future. OTOH, I'll be glad to review and merge high quality PRs.

[Seebiscuit]

Thanks for the quick reply.

I may still be able to contribute if you could please provide me

1. Reasonable estimate of the time required
2. List of modules that require refactor

I know this is an old thread, but perhaps @zslabs and @DanielRuf may still be interested in helping?

[zslabs]

@Seebiscuit I ended up using http://rickharrison.github.io/validate.js/ and rolling my own UI on top of it for my needs.

[marcandre]

I may still be able to contribute if you could please provide me

1. Reasonable estimate of the time required

I'd have a very hard time answering that if I were to do it, so it's even harder to provide for you! Sorry...

2. List of modules that require refactor

You can grep for uses of $ in src/. While references to $element would remain, most methods called on it need to be changed (e.g. this.$element.is(this.options.inputs) would become DOMInterface.is(this.$element, this.options.inputs) or similar, where DOMInterface.is would be something native for the vanilla version, and jQuery's is function for jQuery version.

As stated previously, one tricky part is promise handling and combining, which I'd be willing to do myself once that's the last remaining thing to be done.

HTH

[marcandre]

BTW, if there's interest, I could start a kickstarter/bountysource (not sure of the differences), although I doubt it would get enough traction.

[Seebiscuit]

ROk. I'll take a look.

Re Kickstarter, I think you need some kind of discounted deliverable as an incentive. Don't know how you do that with OSS...