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.

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?

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.

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.

I absolutely had a lot of the same concerns, and I was just as confused as you as to why Vue wouldn't support remote url templates.

That said, once I decided to roll with it, it took about a week* to get it configured how I have it now and have a decent understanding of how/why it was configured. *not a straight week of banging my head into webpack, but some bits of time here and there as I did development

The one other thing that kind of pushed me over the fence into going down the build step route was that I get a minifier, a LINTer and get to use ES2015 (or typescript, or whatever) syntax.

>"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.

Totally valid concern and I see where you're coming from. Once I got into it, though, I realized the only webpack specific syntax is the configuration; how you link your JS files together is just through import/export statements (ES2015 and beyond module system).

That's good feedback. Yeah, I was really close. As with other frameworks, I do think Vue surfaces too much "old Web", but I also think it was the cleanest and simplest of the contenders. I could see it making dev at least somewhat more enjoyable, organized, and productive.

>it took about a week to get it configured

Funny, that's about what I thought it might take--a week of somewhat committed effort. Felt like we didn't have that to spare though, and wasn't 100% sure about the ROI on that time. Felt like a roll of the dice.

Now, whether we'd have already recouped that week is an open question, and setting up a structured JS project was also no small task. But, likewise, we now have a good pattern/mini-framework with a component inheritance model. So, we're recouping that investment as I write this., and we're not tied to deep dependencies or magic.

Next time out, I may have another look at Vue. But, I am really hoping for a more componentized-event driven model that completely abstracts the old Web. Even moreso than React, but with more simplicity and only JS or Typescript in the mix. Kind of a Swing for JS is the best analogy I can make.

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

- [2] https://github.com/facebookincubator/create-react-app

- [3] https://github.com/KingPixil/moon

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.

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.

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.

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.

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?

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.

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.

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.

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)

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.