[monoideism]

> As a senior tech manager php and Jquery allow me to show functional prototypes quickly and easily get buy in from other department stake holders

I totally get it if you prefer to leverage your knowledge of jQuery, but modern JavaScript is just as quick to use. Eg, `fetch`, `querySelector`, and many more. Combined with modern css with flexbox and grid, and prototyping becomes very quick.

[kyriakos]

I think the comparison is not between jquery and native Dom functions but between making something quickly with jquery compared to using angular or react for example

[monoideism]

> I think the comparison is not between jquery and native Dom functions but between making something quickly with jquery compared to using angular or react for example

Probably. I was just making the point that jQuery is no longer needed for most use cases. Lots of folks have no idea what the latest browsers are now capable of.

[mharroun]

I'll admit as I moved into managmemt js has also improved. These prototypes are tossaways so it's just faster for me.to grab jquert.

(Btw I love react and use it in any serious project... but each to definitely has its place)

[skinkestek]

It might be just as quick.

But using modern Javascript frameworks makes you completely dependent on Javascript, unless you want to put in some effort to get server side rendering working). And as every good web developer back in 2009 could tell you this is a bad idea as it makes sure the app can never approach the gold standard: to work in every browser (and work better in modern browsers). In fact it is so bad now that we are repeating the IE6 problems even though all major prowser have all the APIs we could only dream of back in 2009.

Here's a secret: I'd say it is still a bad idea to use Javascript application frameworks on most web sites, and possibly many web apps but it is really nice for consultants, training providers and developers who need job security ;-)

As a full stack developer and a consultant who care about the web and about my clients there are times when I can recommend frontend applications but mostly I just hold my nose, accept what sales have agreed with the customer and try to make the problems as small as possible ;-)

[monoideism]

First of all, I wasn't referring to using any JS framework. I was talking about vanilla JS. Did you know that you can use JS modules now in every major modern browser (Chrome, Edge, Firebox), with no build tool required? Now of course, for production deployment, you'll want to do a build so you can hit older browsers and less common browsers, and/or for performance reasons.

And yes, for "brochure sites", nobody should be using anything except for a static site with bits of progressive enhancement Javascript. Agreed.

On the other hand, you use the word "app". For a true app, you're going to need a JS framework. Trying to build an actual app, like Gmail or Slack, is a fool's errand using only server-side rendering. It's possible, but why would you want to do that to yourself? And even then, the user experience would be awful.

I really think web devs need to do a better job both among themselves and for the clients in differentiating between informational sites and brochureware, and true web applications (usually desktop app replacements, or related). The former should be built using static site generators and just bits of JS, whereas no-one is going to try to build a Slack competitor using a static site generator. There are a few projects I've seen that fall in the middle of the two, but those are relatively rare. Most of the time it's very clear if you're building a site or an app.

[rawfan]

I think you misunderstood. The previous poster meant modern Javascript WITHOUT a framework. These days I would just go with AlpineJS, tbh. It’s a mini-framework that solves the most common problems. Best thing for people who don’t want to write js at all.

[simion314]

>but modern JavaScript is just as quick to use

this is not true. There are many APIs in JQuerry that are shorter, nicer to use and totally missing in pure JS. there are JQuerry methods that workaround HTML5 and old HTML(quirks mode) differences, there are functions like wrap,unwrap, sibling, parents,find,is,css that replace many lines of vanilla JS.

I am not saying that JQuerry is the tool for building a complex SPA , it has it's uses and vanilla JS is inferior for those uses, for a simple form where you want to check the input JS is fine.

[monoideism]

1) It's jQuery, not "JQuerry". I've been using it since 2008, and Prototype.js and script.aculo.us before that.

2) For quick prototypes, I can't imagine why you'd need to accommodate pre-HTML5 HTML. We're discussing quick prototypes, not production sites targeting browsers going back a decade.

3) VanillaJS equivalents are slightly longer than jQuery snippets, mostly because the API names are a bit longer:

css:

    // jQuery
    newDiv.addClass('foo');

    // Vanilla
    newDiv.classList.add('foo');

siblings:

    // jQuery
    const nextElement = $('#wrap').next();

    // Vanilla
    const nextElement = document.querySelector('wrap').nextSibling;

etc etc.

If the extra verbosity bothers you, you can always alias `document.querySelector` as `$`, or `sel`, or whatever. Then you get stuff like:

    // jQuery
    const nextElement = $('#wrap').next();

    // Vanilla
    const nextElement = sel('wrap').nextSibling;

And yes, the jQuery method names are a little shorter, but for quick prototyping, I'd rather use something that I know can be run on any modern browser, with no build step or library required. For production apps, I'll 99% of the time use a framework, either React or Vue.js.

I get that not everyone prefers that. That's OK.

[simion314]

You chose the functions that are the simplest , maybe this are the ones you use but there are many more, like do this in JS. i gave other examples like .is("Lvisible") .parenents , wrap, unwrap, and the one I use a lot .css() .after(), .append() etc . and what makes the API neat is you can chain methods where DOM APIs return special collection that you have to use with for(i = 0; ....

JQuerry might not be the tool for your job but this not makes the fact it's API is nicer, powerful then pure JS . check the anti-jQuerry page http://youmightnotneedjquery.com and you will see that in the end you have to reinvent yor own jQuerry

[monoideism]

> JQuerry might not be the tool for your job

Again, jQuery. I'm a little skeptical that you use either very often if you don't even know how to spell it. `jQuery` is literally the global namespace for jQuery (often aliased to `$`).

> and the one I use a lot .css() .after(), .append() etc

after:

    // jQuery
    (target).after(element);
    // Vanilla JS
    target.insertAdjacentElement('afterend', element);

append:

    // jQuery
    $(parent).append(el);
    
    // Vanilla JS
    parent.appendChild(el);

css:

    // jQuery
    $(el).css('color', 'black');

    // Vanilla JS
    el.style.color = 'black';

That jQuery equivalent page is like 5+ years old. Now, there are easier APIs for the few lengthy vanilla JS that remain on that page.

[simion314]

>el.style.color

is not equivalent with .css()

About my typo , I am not a native english speacker and words like query , queue , still, until are hard for me to remember when to double some letter, spell checker will help but jQuery is not in the dictionary and when I code I use $ and never the full name.

In my use case jQuery is the best tool and I am not sure why you need to contradict someone with daily experience , is so hard to admit that the API is nicer, that it fixes browser differences ? Do you lose some points or pride or other ego related stuff? Do you think you win some credit when you find a typo and use that to attack me? Can you explain what is happening in your mind when you type this ?

Go on that page and look at /is() pr /widthy() and not cherry pick stuff or incomplete implementation like you did for .css()

[monoideism]

> >el.style.color is not equivalent with .css()

How is it not equivalent? Please be specific.

> In my use case jQuery is the best tool and I am not sure why you need to contradict someone with daily experience

Dude, you're the the one who challenged me, and suggested I was lying or uninformed. jQuery is fine to use, I totally understand someone who wants to leverage their background in it. By the way, I also have daily experience, used jQuery for 10 years, am a senior frontend dev.

But it's misleading to new developers to claim that modern JS doesn't have the same capacities. Making this claim spreads misinformation.

> is so hard to admit that the API is nicer,

Disagree. It's more or less the same. I get you're used to one, but there's not a huge difference between the two.

> that it fixes browser differences ?

Yes, it fixes old browser differences, and I made that point repeatedly elsewhere in the thread. For production apps (apps, not sites), if someone is stupid enough to avoid using a framework like Vue.js or React, and you're targeting browsers going back a decade in time, then it's wise to use jQuery. jQuery is also good for progressive enhancement on brochureware sites if you have to support very old browsers (for those kinds of static sites, no need for a JS framework).

But none of that applies to the discussion we were having. The discussion was about quick prototyping.

> Do you lose some points or pride or other ego related stuff? Do you think you win some credit when you find a typo and use that to attack me? Can you explain what is happening in your mind when you type this ?

Sure. Mostly, I'm annoyed at being corrected about jQuery by someone who can't even bother to spell "jQuery" correctly. I speak several languages, and make an effort to use them correctly. Also, language mastery is irrelevant: it's frankly surprising to meet a developer who has such trouble with basic syntax issues.

All the criticisms you threw up in that last paragraph, also apply to you. Do you even realize that? You're the one challenging my perspective. I'm defending it.

Also, in terms of cherrypicking, I'm using the example you chose. So if anyone is cherrypicking here, it's you.

[te_chris]

Modern JS is a total shit show of competing build tools, APIs that only work in certain ways in certain places, NIH reinventing the wheel. Thankfully there's some standardisation now, mostly due to the heft of Facebook, but it's still some much more work than it needs to be, espeically on the server compared to other web stacks like Elixir Phoenix, Rails, Flask, even Laravel (despite it's frustrating APIs).

[monoideism]

I'm talking about vanilla JS, no build tools.

Totally different than server-side coding.

[dagw]

but modern JavaScript is just as quick to use. Eg, `fetch`, `querySelector`

That's one, trivial, part of JQuery. The real strength of Jquery is the countless UI widgets and libraries built on top of it. I can knock together a quick and easy UI using Jquery, Bootstrap and a handfull of Jquery UI widgets faster than with just about anything else.

[monoideism]

Yes, I know. I used jQuery for 10 years.

Now, after learning new APIs for 2 years, I can put together a quick and easy UI using vanilla UI and CSS as fast as I could with jQuery. Particularly grid and flexbox have made a big difference (they fill the role of the old grid CSS frameworks, including that part of Bootstrap).

Your mileage may vary.

Also, the majority of third-party jQuery plugins are no longer maintained. Most of the JS world has moved on.

[sethammons]

jQuery: include this lib, modify DOM.

Modern JavaScript: traveling menagerie of package managers, compilers, build tools, etc. Now that is all in place, modify DOM.

At least, this is my impression from the outside. The last time I actually wrote js was around a decade or more ago.

[martin_a]

As someone who is not very familiar with JS in its multitude of variations this is what it feels like to me. Somebody told me to try Vue and while reusability of components is surely nice to have I feel kind of lost when all I need is a popup when a "save action" was successful.

What about jQuery? Is it still the go-to for simpler things?

[monoideism]

> What about jQuery? Is it still the go-to for simpler things?

Unless you need to target older browsers (like any IE, really), I'd just use vanilla JS. Vanilla JS means no packaging or build process needed. Just create write a JS file, reference it in a script tag in a basic `index.html`, start a web server (like `python3 -m http`) and you're good to go.

Spend a little time learning about flexbox and grid CSS APIs, and you don't even really need CSS framework if you're a decent designer (if not, use Bootstrap or some other CSS framework).

If you're targeting older browsers, like IE, then yes, it's probably a good idea to use jQuery and some CSS framework like Bootstrap.

Absolutely no need for Vue.js or React if you're just doing a very basic UI (however, note that basic UIs have a tendency to become more complex with time, so for that reason most JS devs start with something like Vue.js even if it's not needed initially).

(I'm a senior software developer working in frontend development exclusively for the past 5 years, but have been using JS since 1998, and jQuery since like 2008 - I left the software industry for a number of years after the dot.com bust and came back a decade later).

[monoideism]

I'm referring to vanilla JS and CSS. Literally just write a file and go. No packaging. You can even use modules on modern browsers.

A lot has changed in the decade you've been away from JS. Yes, there's a whole build infrastructure now for large-scale project, but bare, plain, vanilla JS and CSS have more or less built-in most of the features of jQuery and the old CSS grid frameworks.

[SparkyMcUnicorn]

The parent comment is referring to vanilla JS. Just write and serve .js files.

The tools you mentioned are common for frontend frameworks and such.