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.
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.
<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.
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.
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).
>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.
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
If you project calls for "standard, ECMAScript, and (gasp) jQuery," then use them! Just be aware of the benefits and trade-offs.
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.
Large projects or team projects, you will want to use something with more structure.
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 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.
Not an invalid point. Mention jQuery here, or anywhere, and witness the response.