11 ms·

Sorry if this sounds naive, but... do people still use jQuery for new projects? I was genuinely surprised to see it was getting releases anymore, given how much

by CM30 4y ago

Sorry if this sounds naive, but... do people still use jQuery for new projects? I was genuinely surprised to see it was getting releases anymore, given how much of its functionality can be done with native JavaScript now.

amflare 4y ago
Yes. Technically you could always use native JS in place of jQuery and have the same functionality. But jQuery's power came from abstracting away some of the messier and more complicated elements and giving developers a more intuitive set of tools. Some part of this are less necessary today than when jQuery v1 came out (like `querySelectorAll()` vs `$()`), but other parts are still enormously helpful (like `$.ajax()`). So like always, it's a trade off. But it's still one that comes up as worth it as often as not.
- udp 4y ago
  I’m not sure $.ajax() is a good example now that fetch is widely supported.
- gabereiser 4y ago
  `$.ajax()` has been replaced entirely by `fetch()` [0]. The only remaining use-case I can see for jquery is the animation capabilities but even that can be replaced with animejs [1]. [0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U... [1] https://animejs.com/ https://animejs.com/
  - amflare 4y ago
    That's only mostly true. If you are working with anything that needs to support older browsers (which, for example, is unfortunately still a requirement in many medical, government, and financial sectors), then you can't use `fetch()`.
    - duskwuff 4y ago
      You can polyfill fetch() if that's a concern: https://github.com/github/fetch https://github.com/github/fetch
    - no_way 4y ago
      You can use fetch polyfill which woyld be better choice since its easier to remove polyfill than refactor your whole site once you don't need to support those old browsers anymore.
      - amflare 4y ago
        Sure. I could also pull in axios or just bite the bullet and use the XMLHttpRequest API. The point isn't that jQuery is the only way to solve the problem, but rather that it still has a value proposition.
        LudwigNagasena 4y ago
        Being a “polyfill” with idiosyncratic API doesn’t sound like a good value proposition.
    - LudwigNagasena 4y ago
      Babel?
  - Beltalowda 4y ago
    I tried using fetch(). I naïvely passed an object as the POST form parameter and it sent the string "[object Object]" to the server as POST data. Apparently you need to use some special object type. Why doesn't the universal key/value type work for passing a key/values? Who knows – maybe there's a good reason, maybe not. I do know that sending [object Object] is literally never what anyone could possibly want and that almost any other design choice would be less idiotic. So I just use xmlHttpRequest or jQuery.ajax(). xmlHttpRequest is kind of awkward, but it's straight-forward and you don't get nonsense like this. I also don't care much for promises, and fetch is pretty promise-heavy.
    - gabereiser 4y ago
      You tried using fetch() without looking at the documentation on how it's supposed to be used? It's pretty clear [0]. You are supposed to JSON stringify your JSON payload so it can be attached to the body (as a string). The reason being that the browser isn't responsible for determining what goes into the request, only that you can make one. JSON isn't the only option. It could be YAML. It could be base64. It could be null. [0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
      - Beltalowda 4y ago
        It's not clear that it will do something completely idiotic if you mess up a parameter. The documentation didn't mention it, so I figured I'd try and see what happens. This is the worst of dynamic languages: if you mess something up and you get an error: okay, fair. If you mess something up and you ignore it or do something insane: that's just stupid. "Read the documentation from cover to cover to something as simple as sending a HTTP request" isn't really much of solution. > The reason being that the browser isn't responsible for determining what goes into the request, only that you can make one. JSON isn't the only option. It could be YAML. It could be base64. It could be null. The standard data type for POST is form data, so it could just default to that for objects. Or it could throw an error. Sending [object Object] is not reasonable behaviour in any shape or form. I guess it just calls the JS "to string" logic ("logic"), but spreading that to new APIs is just not a good design, especially when it's "hidden".
  - runarberg 4y ago
    CSS animations and the Web Animation API are also quite nice to use and quite powerful. https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati...
- ssl232 4y ago
  Is jQuery able to use native browser functions internally if they're available? If so then there's probably not much of a penalty over using pure JavaScript, but a large benefit from the mature component ecosystem.
ericb 4y ago
One thing that gets forgotten about jQuery is that there's a tremendous library of very evolved components in its ecosystem. Sure, "you don't need jQuery" is true, but when you go hunting for components you'd rather not write yourself, man is there still some gravity there. You ask yourself, "do I feel like writing a calendar selector widget today?" Trade some vanity and JavaScript puritanism and the question becomes "what color should I style it?"
kypro 4y ago
I've not used it in a new project for a long time, but I often still work on projects with legacy jQuery code. The main reason to still use it imo it is simply that a lot of devs are familiar with the API and they have really good docs. While I prefer vanilla JS for JS-light projects, I'm also aware of some cross-browser weirdness and combability issues you might run into with a vanilla JS project. The nice thing JQuery is that you know it will work as expected on the all browsers it supports so you don't need to worry about cross-browser testing your code. It also makes certain things easier to do like basic JS animations. The main reason care about the latest releases is that they patch security issues from time to time.
- collyw 4y ago
  > I'm also aware of some cross-browser weirdness and combability issues you might run into with a vanilla JS project. That was the main reason that jQuery got popular if I remember correctly (though I have always been an 85% backend developer). I was under the impression that that isn't really an issue these days, but everyone is building overly complex monstrosities with React or whatever else is flavor of the month.
  - lelandfe 4y ago
    https://webkit.org/blog/12288/working-together-on-interop-2022/ https://webkit.org/blog/12288/working-together-on-interop-20... The various browsers have gotten together and work awfully hard to fix outstanding quirks. You'll still encounter cross-browser oddities here and there, but it's generally more in the order of, "X browser hasn't added this method yet"
  - The_Colonel 4y ago
    Yes, the cross browser weirdness is nothing like it used to be. The other raison d'être is the API, which is simply much better than even the latest DOM API. It's actually pretty remarkable that jQuery API feels spot on even after 16 years.
  - eyelidlessness 4y ago
    I was jQuery’s target audience at its heyday and at least for me, the big thing it brought to the table was $ and what’s now called a “fluent API” ($ methods return $ instances unless they’re getters for primitives; it’s pretty much still my preferred way to explain the general concept of monads to people familiar with the pattern). Browser compatibility was just delicious icing on the cake.
PrivateButts 4y ago
jQuery is like, comfort food for me? Used to use jQuery for everything and now the world's moved on. I wouldn't want to do a large project today in jQuery, but I kinda miss the simpler projects that I used to do all the time with a smaller toolbox.
jrochkind1 4y ago
i don't intentionally write code using JQuery anymore, and find it not very inconvenient to avoid for the most part, even when writing "jquery style" JS -- which I do. Browser API's in recent browsers are good enough. But I'm still using some dependencies that need jquery. I honestly expect I'll never be able to get rid of it.
smallmouth 4y ago
Apology accepted, and absolutely! Myself and two other developers just kicked off a very non-tivial, data-heavy application for a Dow 30 that will be used by a maximum of 12,000 users. Using jquery will help us avoid a lot of thinking and testing time with the whole "gee, how would I do that in vanilla, let me look that up" process.
deleted 4y ago
[deleted]
pier25 4y ago
jQuery is more popular than React by pretty much any metric you can find
- collyw 4y ago
  for starting new projects?
  - kbrannigan 4y ago
    Beginers and aspiring sofware developers tends to use the most popular technology, evangelized by the biggest companies. Since they don't know any better, they equate MOST POPULAR with BEST. Sometimes all you need is a wheelbarrow, you don't need a tractor.
    - collyw 4y ago
      BEST is highly subjective. Most popular has a number of advantages- more developers, likely cheaper developers, bigger community but for most cases I am in agreement with you
  - pier25 4y ago
    Yeah. There are probably more new projects started with Wordpress themes that use jQuery than React projects. And it's not only WP. Plenty of big companies use it too. Amazon (the store) used it until a couple of months ago IIRC. If you don't need a super sophisticated frontend, jQuery is still one of the best tools around. People argue vanilla JS can do everything jQuery does, which is true for jQuery and any JS framework really, but they're really missing the point. With jQuery you can do express complex logic in a single line that would take many more lines in vanilla JS.
thejammahimself 4y ago
Yeah a good few years ago, before I had learnt about frameworks like React, I used JQuery for one of my projects. Once I learned about React, I decided to rewrite this project using that instead, and afterwards I felt that the React version was very obviously the superior version. I just feel like we now have better options, and I still really like React's way of handling state in a moreso functional way.
tsian2 4y ago
I find it much quicker to write and neater to read than vanilla JS. I optimise afterwards and might consider swapping it out but it's usually low down the list of performance issues. Although it can be a bigger issue if you don't know how select things and store those selections efficiently with it.
jabart 4y ago
Bootstrap 4 uses jquery, bootstrap 5 was released (not beta) May 5, 2021. So, anything started with Bootstrap 4 would use it.
yokoprime 4y ago
I only encounter it when maintaining old codebases. Never for anything new
ww520 4y ago
Yes. I do still use it.
Alupis 4y ago
The API jQuery gives you is still so much nicer than regular javascript, even with modern ECMAScript 7+... While we're at it - Bootstrap (and similar css frameworks) are still much nicer to use than native CSS, even with modern CSS3 and flexbox... It's almost like the designers for these native-API's look at what the community uses, and then decide to do something similar, but different just because.
- eyelidlessness 4y ago
  > It's almost like the designers for these native-API's look at what the community uses, and then decide to do something similar, but different just because. This is an understandable interpretation, but I think the real explanation is more nuanced (and more favorable). Web APIs do tend to be inspired by existing use cases like you say, and that’s a good thing. But from there they tend to be low level—in the sense that they’re designed for library authors, at least as much as they’re designed for end users—either as an explicit goal or as an implied general principle. Taking inspiration from real usage is unambiguously great. Lower level APIs might feel more painful for end users (and can lead to dependency-itis which is a constant target of scorn here and all over). But the benefit is that these less friendly APIs are also well designed to be used in a wider variety of ways, without much influence on their own higher level interfaces. More concretely, the DOM as designed allows jQuery and React to coexist and thrive for their own target audiences, in a way that would probably be much less likely if the DOM had been designed more like either one of them. This is similarly true for APIs like Intl (which I’ve used directly, and it’s fine… but it’s definitely better as a library target than for every day usage).
  - Alupis 4y ago
    Of course there are technical reasons things are the way they are - but why does javascript have like 6 different ways to select an element? Why does everything have to start with verbose "document."? Why are the new functions so long in name and cumbersome to use? In jQuery, you can select almost anything with just the constructor. It's simple... and clearly better. > in the sense that they’re designed for library authors Libraries shouldn't be necessary to write basic DOM manipulation code. Modern ECMAScript has been promised to do away with all the "hack" libraries like jQuery... and articles like "You might not need jQuery" sprang up in popularity based on new ECMAScript features. But, modern ECMAScript is objectively harder to use, more clunky and verbose. Even the naming of functions is absurd... "querySelector()" instead of just "select()" or "get()"... The problem with the javascript community is nobody actually knows javascript. No, people know whatever framework/lib they work with, which is not the same thing. It's that way because javascript... sucks to use.
progmetaldev 4y ago
I am still using jQuery because I have so many plugins such as calendars, photo galleries, video galleries, and file explorer type trees that are all progressively enhanced, it would be a ton of work to rebuild everything. I think jQuery is still does a great job for progressive enhancement of CMS/informational type websites.
bigger_cheese 4y ago
I used jQuery earlier this year. I am not a web developer I learnt HTML in the 90's (When Frames and Tables were the way to write web pages). I have not kept up to date with current State of the art in web development. I know enough about JavaScript to read source code and kind of understand what it is doing but don't know anything about best practices or the 'proper' way to write it. I needed to throw together a simple webform to submit a date as one of the inputs. I was having problems getting it to work consistently across different browsers. One of the issues I was having was I needed the date to be in the Australian date format (DD/MM/YYYY) but one browser (I can't remember which Edge maybe??) kept insisting on using US style dates MM/DD/YYYY it caused me a lot of frustration maybe I just didn't know the correct phrase to search google for but I could not work out how to make the browsers built in calendar picker force the date to be in a specific format. So I just used the JQuery calendar picker took me two seconds and problem solved.
tambourine_man 4y ago
It always could be done in JavaScript, jQuery is written on it after all. It’s just that it’s a lot better and easier. The fact that we haven’t standardized on jQuery’s API is one of the greatest missed opportunities in the field.
deterministic 4y ago
Yep. It is the first package I install on a new project. Followed by React.
PointyFluff 4y ago

by CM30 4y ago

amflare 4y ago

Yes. Technically you could always use native JS in place of jQuery and have the same functionality. But jQuery's power came from abstracting away some of the messier and more complicated elements and giving developers a more intuitive set of tools. Some part of this are less necessary today than when jQuery v1 came out (like `querySelectorAll()` vs `$()`), but other parts are still enormously helpful (like `$.ajax()`). So like always, it's a trade off. But it's still one that comes up as worth it as often as not.

udp 4y ago
I’m not sure $.ajax() is a good example now that fetch is widely supported.
gabereiser 4y ago
`$.ajax()` has been replaced entirely by `fetch()` [0]. The only remaining use-case I can see for jquery is the animation capabilities but even that can be replaced with animejs [1]. [0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U... [1] https://animejs.com/ https://animejs.com/
- amflare 4y ago
  That's only mostly true. If you are working with anything that needs to support older browsers (which, for example, is unfortunately still a requirement in many medical, government, and financial sectors), then you can't use `fetch()`.
  - duskwuff 4y ago
    You can polyfill fetch() if that's a concern: https://github.com/github/fetch https://github.com/github/fetch
  - no_way 4y ago
    You can use fetch polyfill which woyld be better choice since its easier to remove polyfill than refactor your whole site once you don't need to support those old browsers anymore.
    - amflare 4y ago
      Sure. I could also pull in axios or just bite the bullet and use the XMLHttpRequest API. The point isn't that jQuery is the only way to solve the problem, but rather that it still has a value proposition.
      - LudwigNagasena 4y ago
        Being a “polyfill” with idiosyncratic API doesn’t sound like a good value proposition.
  - LudwigNagasena 4y ago
    Babel?
- Beltalowda 4y ago
  I tried using fetch(). I naïvely passed an object as the POST form parameter and it sent the string "[object Object]" to the server as POST data. Apparently you need to use some special object type. Why doesn't the universal key/value type work for passing a key/values? Who knows – maybe there's a good reason, maybe not. I do know that sending [object Object] is literally never what anyone could possibly want and that almost any other design choice would be less idiotic. So I just use xmlHttpRequest or jQuery.ajax(). xmlHttpRequest is kind of awkward, but it's straight-forward and you don't get nonsense like this. I also don't care much for promises, and fetch is pretty promise-heavy.
  - gabereiser 4y ago
    You tried using fetch() without looking at the documentation on how it's supposed to be used? It's pretty clear [0]. You are supposed to JSON stringify your JSON payload so it can be attached to the body (as a string). The reason being that the browser isn't responsible for determining what goes into the request, only that you can make one. JSON isn't the only option. It could be YAML. It could be base64. It could be null. [0] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
    - Beltalowda 4y ago
      It's not clear that it will do something completely idiotic if you mess up a parameter. The documentation didn't mention it, so I figured I'd try and see what happens. This is the worst of dynamic languages: if you mess something up and you get an error: okay, fair. If you mess something up and you ignore it or do something insane: that's just stupid. "Read the documentation from cover to cover to something as simple as sending a HTTP request" isn't really much of solution. > The reason being that the browser isn't responsible for determining what goes into the request, only that you can make one. JSON isn't the only option. It could be YAML. It could be base64. It could be null. The standard data type for POST is form data, so it could just default to that for objects. Or it could throw an error. Sending [object Object] is not reasonable behaviour in any shape or form. I guess it just calls the JS "to string" logic ("logic"), but spreading that to new APIs is just not a good design, especially when it's "hidden".
- runarberg 4y ago
  CSS animations and the Web Animation API are also quite nice to use and quite powerful. https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati...
ssl232 4y ago
Is jQuery able to use native browser functions internally if they're available? If so then there's probably not much of a penalty over using pure JavaScript, but a large benefit from the mature component ecosystem.

ericb 4y ago

One thing that gets forgotten about jQuery is that there's a tremendous library of very evolved components in its ecosystem. Sure, "you don't need jQuery" is true, but when you go hunting for components you'd rather not write yourself, man is there still some gravity there. You ask yourself, "do I feel like writing a calendar selector widget today?" Trade some vanity and JavaScript puritanism and the question becomes "what color should I style it?"

kypro 4y ago

I've not used it in a new project for a long time, but I often still work on projects with legacy jQuery code. The main reason to still use it imo it is simply that a lot of devs are familiar with the API and they have really good docs. While I prefer vanilla JS for JS-light projects, I'm also aware of some cross-browser weirdness and combability issues you might run into with a vanilla JS project. The nice thing JQuery is that you know it will work as expected on the all browsers it supports so you don't need to worry about cross-browser testing your code. It also makes certain things easier to do like basic JS animations. The main reason care about the latest releases is that they patch security issues from time to time.

collyw 4y ago
> I'm also aware of some cross-browser weirdness and combability issues you might run into with a vanilla JS project. That was the main reason that jQuery got popular if I remember correctly (though I have always been an 85% backend developer). I was under the impression that that isn't really an issue these days, but everyone is building overly complex monstrosities with React or whatever else is flavor of the month.
- lelandfe 4y ago
  https://webkit.org/blog/12288/working-together-on-interop-2022/ https://webkit.org/blog/12288/working-together-on-interop-20... The various browsers have gotten together and work awfully hard to fix outstanding quirks. You'll still encounter cross-browser oddities here and there, but it's generally more in the order of, "X browser hasn't added this method yet"
- The_Colonel 4y ago
  Yes, the cross browser weirdness is nothing like it used to be. The other raison d'être is the API, which is simply much better than even the latest DOM API. It's actually pretty remarkable that jQuery API feels spot on even after 16 years.
- eyelidlessness 4y ago
  I was jQuery’s target audience at its heyday and at least for me, the big thing it brought to the table was $ and what’s now called a “fluent API” ($ methods return $ instances unless they’re getters for primitives; it’s pretty much still my preferred way to explain the general concept of monads to people familiar with the pattern). Browser compatibility was just delicious icing on the cake.

PrivateButts 4y ago

jQuery is like, comfort food for me? Used to use jQuery for everything and now the world's moved on. I wouldn't want to do a large project today in jQuery, but I kinda miss the simpler projects that I used to do all the time with a smaller toolbox.

jrochkind1 4y ago

i don't intentionally write code using JQuery anymore, and find it not very inconvenient to avoid for the most part, even when writing "jquery style" JS -- which I do. Browser API's in recent browsers are good enough. But I'm still using some dependencies that need jquery. I honestly expect I'll never be able to get rid of it.

smallmouth 4y ago

Apology accepted, and absolutely! Myself and two other developers just kicked off a very non-tivial, data-heavy application for a Dow 30 that will be used by a maximum of 12,000 users. Using jquery will help us avoid a lot of thinking and testing time with the whole "gee, how would I do that in vanilla, let me look that up" process.

deleted 4y ago

[deleted]

pier25 4y ago

jQuery is more popular than React by pretty much any metric you can find

collyw 4y ago
for starting new projects?
- kbrannigan 4y ago
  Beginers and aspiring sofware developers tends to use the most popular technology, evangelized by the biggest companies. Since they don't know any better, they equate MOST POPULAR with BEST. Sometimes all you need is a wheelbarrow, you don't need a tractor.
  - collyw 4y ago
    BEST is highly subjective. Most popular has a number of advantages- more developers, likely cheaper developers, bigger community but for most cases I am in agreement with you
- pier25 4y ago
  Yeah. There are probably more new projects started with Wordpress themes that use jQuery than React projects. And it's not only WP. Plenty of big companies use it too. Amazon (the store) used it until a couple of months ago IIRC. If you don't need a super sophisticated frontend, jQuery is still one of the best tools around. People argue vanilla JS can do everything jQuery does, which is true for jQuery and any JS framework really, but they're really missing the point. With jQuery you can do express complex logic in a single line that would take many more lines in vanilla JS.

thejammahimself 4y ago

Yeah a good few years ago, before I had learnt about frameworks like React, I used JQuery for one of my projects. Once I learned about React, I decided to rewrite this project using that instead, and afterwards I felt that the React version was very obviously the superior version. I just feel like we now have better options, and I still really like React's way of handling state in a moreso functional way.

tsian2 4y ago

I find it much quicker to write and neater to read than vanilla JS. I optimise afterwards and might consider swapping it out but it's usually low down the list of performance issues. Although it can be a bigger issue if you don't know how select things and store those selections efficiently with it.

jabart 4y ago

Bootstrap 4 uses jquery, bootstrap 5 was released (not beta) May 5, 2021. So, anything started with Bootstrap 4 would use it.

yokoprime 4y ago

I only encounter it when maintaining old codebases. Never for anything new

ww520 4y ago

Yes. I do still use it.

Alupis 4y ago

The API jQuery gives you is still so much nicer than regular javascript, even with modern ECMAScript 7+... While we're at it - Bootstrap (and similar css frameworks) are still much nicer to use than native CSS, even with modern CSS3 and flexbox... It's almost like the designers for these native-API's look at what the community uses, and then decide to do something similar, but different just because.

eyelidlessness 4y ago
> It's almost like the designers for these native-API's look at what the community uses, and then decide to do something similar, but different just because. This is an understandable interpretation, but I think the real explanation is more nuanced (and more favorable). Web APIs do tend to be inspired by existing use cases like you say, and that’s a good thing. But from there they tend to be low level—in the sense that they’re designed for library authors, at least as much as they’re designed for end users—either as an explicit goal or as an implied general principle. Taking inspiration from real usage is unambiguously great. Lower level APIs might feel more painful for end users (and can lead to dependency-itis which is a constant target of scorn here and all over). But the benefit is that these less friendly APIs are also well designed to be used in a wider variety of ways, without much influence on their own higher level interfaces. More concretely, the DOM as designed allows jQuery and React to coexist and thrive for their own target audiences, in a way that would probably be much less likely if the DOM had been designed more like either one of them. This is similarly true for APIs like Intl (which I’ve used directly, and it’s fine… but it’s definitely better as a library target than for every day usage).
- Alupis 4y ago
  Of course there are technical reasons things are the way they are - but why does javascript have like 6 different ways to select an element? Why does everything have to start with verbose "document."? Why are the new functions so long in name and cumbersome to use? In jQuery, you can select almost anything with just the constructor. It's simple... and clearly better. > in the sense that they’re designed for library authors Libraries shouldn't be necessary to write basic DOM manipulation code. Modern ECMAScript has been promised to do away with all the "hack" libraries like jQuery... and articles like "You might not need jQuery" sprang up in popularity based on new ECMAScript features. But, modern ECMAScript is objectively harder to use, more clunky and verbose. Even the naming of functions is absurd... "querySelector()" instead of just "select()" or "get()"... The problem with the javascript community is nobody actually knows javascript. No, people know whatever framework/lib they work with, which is not the same thing. It's that way because javascript... sucks to use.

progmetaldev 4y ago

I am still using jQuery because I have so many plugins such as calendars, photo galleries, video galleries, and file explorer type trees that are all progressively enhanced, it would be a ton of work to rebuild everything. I think jQuery is still does a great job for progressive enhancement of CMS/informational type websites.

bigger_cheese 4y ago

I used jQuery earlier this year. I am not a web developer I learnt HTML in the 90's (When Frames and Tables were the way to write web pages). I have not kept up to date with current State of the art in web development. I know enough about JavaScript to read source code and kind of understand what it is doing but don't know anything about best practices or the 'proper' way to write it. I needed to throw together a simple webform to submit a date as one of the inputs. I was having problems getting it to work consistently across different browsers. One of the issues I was having was I needed the date to be in the Australian date format (DD/MM/YYYY) but one browser (I can't remember which Edge maybe??) kept insisting on using US style dates MM/DD/YYYY it caused me a lot of frustration maybe I just didn't know the correct phrase to search google for but I could not work out how to make the browsers built in calendar picker force the date to be in a specific format. So I just used the JQuery calendar picker took me two seconds and problem solved.

tambourine_man 4y ago

It always could be done in JavaScript, jQuery is written on it after all. It’s just that it’s a lot better and easier. The fact that we haven’t standardized on jQuery’s API is one of the greatest missed opportunities in the field.

deterministic 4y ago

Yep. It is the first package I install on a new project. Followed by React.

PointyFluff 4y ago