6 ms·

Can anyone tell me why I shouldn't still just use standard, ECMAScript, and (gasp) jQuery? There's so much churn in the JS world, sometimes it makes sense to ju

Can anyone tell me why I shouldn't still just use standard, ECMAScript, and (gasp) jQuery? There's so much churn in the JS world, sometimes it makes sense to just build something, and then optimize it later.

kcdev 9y ago
For small projects, this is definitely still OK. Green browsers don't really need jQuery any more, but if it's what you're comfortable using and it gets the job done, then use it. Large projects or team projects, you will want to use something with more structure.
- aaron-lebo 9y ago
  Some of the newer frontend frameworks are so small that it really doesn't benefit you to use jQuery even for small projects. It lacks structure and it's way too easy to start manipulating state though the dom when you could have reusable components and a decent structure with a few extra lines of code.
lxrbst 9y ago
No one is seriously saying you can't. If your problems are simple enough to be solved with plain js/jquery, feel free. I don't get all this tooling and framework hate - no one is forcing you to choose anything, it's an open buffet, and you can choose as much as you want from wherever you want, for free.
- unclebucknasty 9y ago
  I think he/she is saying the opposite: that people who don't use frameworks get the hate, and there is a lot of pressure to pick a framework. Not an invalid point. Mention jQuery here, or anywhere, and witness the response.
chasing 9y ago
Remember that part of being an experienced developer is having the wisdom and knowledge to select the right tool for the right job. Sometimes that's the hot new cool shit. Oftentimes it's something much more mundane. If you project calls for "standard, ECMAScript, and (gasp) jQuery," then use them! Just be aware of the benefits and trade-offs.
- RonanTheGrey 9y ago
  I think alot of people forget this. How many frameworks have I passed over, because I knew they were a trend, before I selected something like React to develop with? It's a fine balance, choosing between a technology you know and "always be learning". Experience guides how much of the bandwagon you jump onto. The funny part is, that in no other industry is there this expectation that things be plain, simple and easy. We, as developers, are blinded by our desire for instant gratification that is uncommon in other industries. My mom, as a paralegal, never complained that the path to completing a case took 47 different filings with each page printed in triplicate, whose versions changed depending on the dates in the case. It just.. IS. Sure it can be better. But the expectation that it be, in an almost petulant way, is what I'm talking about here.
thinkxl 9y ago
I've been a web developers for 5 years like the author, and, I as well, went through the jQuery, Knockout, Backbone, React, Vue road. On my daily job I use Node & React/Redux, on personal projects, I prototype in Python using bottle and vanilla JavaScript with axios[1]. Before, I wanted to use the latest stack, maybe looking for approval from the "community", something like: "Hey, I'm building a X app with Express, React, React Router, Redux, Immutable..." But by the time I had the basic setup, my motivation was gone (at that time there was no react-starter-app[2]). So I'd say you should start with whatever you are most comfortable, doesn't matter if it's React or jQuery. The goal, IMO, is to start building stuff. Now, I just don't care what's the latest JS framework, I don't dislike them, all the opposite, I get excited about them[3], but I focus on what's my best weapon for the job. - [1] https://github.com/mzabriskie/axios https://github.com/mzabriskie/axios - [2] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app - [3] https://github.com/KingPixil/moon https://github.com/KingPixil/moon
ElatedOwl 9y ago
The problem I always have with jQuery is it turns into a maintenance nightmare (read: spaghetti everywhere) and there's a lot of repetition. I'm sure there are some people with organized jQuery front ends, but it's way too easy to have a mismangled giant ball of mud. Going with a framework you can of course still have a giant ball of mud, but it's a lot harder to get there. Anything component based is a big step up in organization. My other big issue is 90% of what I'm doing on the front end is ajax calls and keeping the UI state up to date. A framework like Vue makes it so trivial. I sincerely encourage you to give something like Vue a try. You don't have to adopt it all in, you can use it for just a single on page component and see how you like it. The getting started guide is great - if you have a solid understanding of JS you will be up and running in an afternoon. I was hesitant like you and as soon as I tried Vue I haven't looked back.
- unclebucknasty 9y ago
  What's the best way to manage templates in Vue if you don't want ES6-style string literals everywhere and you don't want a build step?
  - ElatedOwl 9y ago
    You can do script style templates, e.g. <script type="text/x-template" id="component-name-template"> <div> {{ msg }} </div> </script> Then when setting up your component you specify the template property with the id, e.g. Vue.component('component-name', { template: '#component-name-template' }); Honestly though this sucks if you plan on reusing components. Can I ask why you don't want a build step? The single file components are great.
    - unclebucknasty 9y ago
      Thanks. Yeah, I looked at that option too and agree that it does suck. :) Just didn't want a build step due to complexity. I know it's not that difficult, but wanting to keep it as simple as possible. I don't really get why Vue opted not to support URLs for their templates. It could be easily managed via co-location of templates with components and/or naming conventions. You actually wouldn't even need to specify the URL. It just grabs it from the component's directory by name. Anyway, for me, this is a weakness. I get that they want to maintain the single file component model, but I'm not sure it's worth it when your choices are literals, script templates, or an extra build step. OTOH, co-locating a dependent file is no biggie, even if you don't get to claim single file components. EDIT: I was close to going with Vue for a project a month or so ago. But, wading into it, I realized the build step would be necessary to do it "right". Suddenly, you're downloading plugins, xcode, and all kinds of other stuff, then setting up a build. It just seems a lot for, essentially, single file templates. Granted, several steps are automated, and you're just issuing npm commands, etc. But, I started thinking, "do we really want all of this magic? What if the build just doesn't work one day or we need to reconfigure? Now we're troubleshooting and figuring out the linkages that were created and the other magic. The whole process was a stark reminder that you're in someone else's world. Maybe I'm too big on control. But, I don't want to be sucked into too many dependencies.
pragmar 9y ago
I'd say it depends on whether you're fundamentally serving documents or an application. The new breed of js frameworks probably isn't the right choice for Wikipedia, and jQuery probably isn't the right choice for Spotify player. A generalization, for sure, but that is how I tend to think about it.
draw_down 9y ago
Man, building UIs that way was so painful in so many little ways. You can still do it if you like... as long as your code is testable and changeable (sorry but comfort/familiarity isn't everything)
jbreckmckye 9y ago
You can, but it requires a lot of discipline, and the code you're left with is not particularly fast or elegant. Still, if you must: create classes to represent components, with methods used to manipulate markup, and plug those methods into a simple pub/sub event bus. This will work for very simple apps, but ask yourself - how simple will your app remain?
danielharrison 9y ago
Jquery was a 'patch' to standardise js and the dom across browsers. It's no longer really needed because both native js and the dom have caught up.

kcdev 9y ago

For small projects, this is definitely still OK. Green browsers don't really need jQuery any more, but if it's what you're comfortable using and it gets the job done, then use it. Large projects or team projects, you will want to use something with more structure.

aaron-lebo 9y ago
Some of the newer frontend frameworks are so small that it really doesn't benefit you to use jQuery even for small projects. It lacks structure and it's way too easy to start manipulating state though the dom when you could have reusable components and a decent structure with a few extra lines of code.

lxrbst 9y ago

No one is seriously saying you can't. If your problems are simple enough to be solved with plain js/jquery, feel free. I don't get all this tooling and framework hate - no one is forcing you to choose anything, it's an open buffet, and you can choose as much as you want from wherever you want, for free.

unclebucknasty 9y ago
I think he/she is saying the opposite: that people who don't use frameworks get the hate, and there is a lot of pressure to pick a framework. Not an invalid point. Mention jQuery here, or anywhere, and witness the response.

chasing 9y ago

Remember that part of being an experienced developer is having the wisdom and knowledge to select the right tool for the right job. Sometimes that's the hot new cool shit. Oftentimes it's something much more mundane. If you project calls for "standard, ECMAScript, and (gasp) jQuery," then use them! Just be aware of the benefits and trade-offs.

RonanTheGrey 9y ago
I think alot of people forget this. How many frameworks have I passed over, because I knew they were a trend, before I selected something like React to develop with? It's a fine balance, choosing between a technology you know and "always be learning". Experience guides how much of the bandwagon you jump onto. The funny part is, that in no other industry is there this expectation that things be plain, simple and easy. We, as developers, are blinded by our desire for instant gratification that is uncommon in other industries. My mom, as a paralegal, never complained that the path to completing a case took 47 different filings with each page printed in triplicate, whose versions changed depending on the dates in the case. It just.. IS. Sure it can be better. But the expectation that it be, in an almost petulant way, is what I'm talking about here.

thinkxl 9y ago

I've been a web developers for 5 years like the author, and, I as well, went through the jQuery, Knockout, Backbone, React, Vue road. On my daily job I use Node & React/Redux, on personal projects, I prototype in Python using bottle and vanilla JavaScript with axios[1]. Before, I wanted to use the latest stack, maybe looking for approval from the "community", something like: "Hey, I'm building a X app with Express, React, React Router, Redux, Immutable..." But by the time I had the basic setup, my motivation was gone (at that time there was no react-starter-app[2]). So I'd say you should start with whatever you are most comfortable, doesn't matter if it's React or jQuery. The goal, IMO, is to start building stuff. Now, I just don't care what's the latest JS framework, I don't dislike them, all the opposite, I get excited about them[3], but I focus on what's my best weapon for the job. - [1] https://github.com/mzabriskie/axios https://github.com/mzabriskie/axios - [2] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app - [3] https://github.com/KingPixil/moon https://github.com/KingPixil/moon

ElatedOwl 9y ago

The problem I always have with jQuery is it turns into a maintenance nightmare (read: spaghetti everywhere) and there's a lot of repetition. I'm sure there are some people with organized jQuery front ends, but it's way too easy to have a mismangled giant ball of mud. Going with a framework you can of course still have a giant ball of mud, but it's a lot harder to get there. Anything component based is a big step up in organization. My other big issue is 90% of what I'm doing on the front end is ajax calls and keeping the UI state up to date. A framework like Vue makes it so trivial. I sincerely encourage you to give something like Vue a try. You don't have to adopt it all in, you can use it for just a single on page component and see how you like it. The getting started guide is great - if you have a solid understanding of JS you will be up and running in an afternoon. I was hesitant like you and as soon as I tried Vue I haven't looked back.

unclebucknasty 9y ago
What's the best way to manage templates in Vue if you don't want ES6-style string literals everywhere and you don't want a build step?
- ElatedOwl 9y ago
  You can do script style templates, e.g. <script type="text/x-template" id="component-name-template"> <div> {{ msg }} </div> </script> Then when setting up your component you specify the template property with the id, e.g. Vue.component('component-name', { template: '#component-name-template' }); Honestly though this sucks if you plan on reusing components. Can I ask why you don't want a build step? The single file components are great.
  - unclebucknasty 9y ago
    Thanks. Yeah, I looked at that option too and agree that it does suck. :) Just didn't want a build step due to complexity. I know it's not that difficult, but wanting to keep it as simple as possible. I don't really get why Vue opted not to support URLs for their templates. It could be easily managed via co-location of templates with components and/or naming conventions. You actually wouldn't even need to specify the URL. It just grabs it from the component's directory by name. Anyway, for me, this is a weakness. I get that they want to maintain the single file component model, but I'm not sure it's worth it when your choices are literals, script templates, or an extra build step. OTOH, co-locating a dependent file is no biggie, even if you don't get to claim single file components. EDIT: I was close to going with Vue for a project a month or so ago. But, wading into it, I realized the build step would be necessary to do it "right". Suddenly, you're downloading plugins, xcode, and all kinds of other stuff, then setting up a build. It just seems a lot for, essentially, single file templates. Granted, several steps are automated, and you're just issuing npm commands, etc. But, I started thinking, "do we really want all of this magic? What if the build just doesn't work one day or we need to reconfigure? Now we're troubleshooting and figuring out the linkages that were created and the other magic. The whole process was a stark reminder that you're in someone else's world. Maybe I'm too big on control. But, I don't want to be sucked into too many dependencies.

pragmar 9y ago

I'd say it depends on whether you're fundamentally serving documents or an application. The new breed of js frameworks probably isn't the right choice for Wikipedia, and jQuery probably isn't the right choice for Spotify player. A generalization, for sure, but that is how I tend to think about it.

draw_down 9y ago

Man, building UIs that way was so painful in so many little ways. You can still do it if you like... as long as your code is testable and changeable (sorry but comfort/familiarity isn't everything)

jbreckmckye 9y ago

You can, but it requires a lot of discipline, and the code you're left with is not particularly fast or elegant. Still, if you must: create classes to represent components, with methods used to manipulate markup, and plug those methods into a simple pub/sub event bus. This will work for very simple apps, but ask yourself - how simple will your app remain?

danielharrison 9y ago

Jquery was a 'patch' to standardise js and the dom across browsers. It's no longer really needed because both native js and the dom have caught up.