Personally I still believe that JavaScript and HTML should be separate, like HTML and CSS. I know that might make sound old, but I really dislike having a template language embedded in my JavaScript library, and as a result I end up disliking most of the newer frameworks.
I know jQuery, the documentation is good, it's easy to get help, and it makes sense to me in a way React, Angular and others frameworks do not.
Yeah, I could use plain JavaScript, I could also just use Python and not have a Django or Flask dependency. It's just easier and more productive to take the dependency.
I can relate to this idea, but I gave a try to react and I changed my position:
Here's why IMO react is not actually mixing the two: HTML is just the serialized form of the DOM, your browser reads it, transforms it the a DOM tree before rendering it.
With react, you interact with the DOM (indirectly via a virtual DOM API), so you manipulate javascript objects, you only do javascript. JSX is just syntaxic sugar over that API, because deep nesting is easier to read with XMLish syntax. JSX is not a templating language (that outputs a string).
So far every new project in the last few years ended up using jQuery because there is always this one ui widget that does what we need and the other libraries just aren't there yet and its not worth the hassle of reimplementing or extending a different library just to not use jQuery.
True. Although whenever I see a jQuery plugin like that I try to replace it with some combination of "components" [1]. There is a lot of progress in that area.
There are stuff like : File picker [2], dropdown [3], tip [4] for tooltips and many more.
CBP (component based programming) has been around (at least the idea has) since the 60s. It is the holy grail of some developers; being able to compose apps from a collection of components that work everywhere. I don't believe anyone has ever truly reached that goal. But surely it'll work this time because of JavaScript.
Just last week I started a new project, injecting some firebase-backed functionality into a squarespace site, and I used jQuery.
I use it for the same reason I use lodash when I could do everything it does in vanilla js: because it's a slightly more dev-friendly API.
Much like the PHP community, jQuery's community has earned it a reputation as a hacky tool for people who don't understand where jQuery ends and Javascript begins. However, it didn't become popular by accident, and in competent hands, it still has its benefits.
I started using "vanilla" js, then created a method as a name for the huge `[].prototype.slice.call(document.querySelectorAll(selector))`
Then as I continued adding useful methods such as ajax() (no, in vanilla js it's not "solved") and turning events off (also non-trivial) I ended up with a jquery alternative:
It's not exactly the same, but most methods are the same or highly compatible. For example, the append() method is extended so this does what you'd expect it to do, generate a list with first, second and third items:
> useful methods such as ajax() (no, in vanilla js it's not "solved")
Right - I use jQuery because I've greater confidence that `.ajax()` will behave correctly across a wide range of browser versions, though I don't have any good evidence about using that vs vanilla `XMLHttpRequest` these days. I'd be interested to know which bits of "not solved" - which aspects in particular are not yet well supported?
Fetch has its own issues - not being able to abort a fetch, or recieve progress notifications are frustrating if you require them.
But the deficiencies of fetch() are another topic entirely, and I tend to use it (polyfilled tbh) for the majority of my async requests because I like the rest of its implementation.
I can't answer that, but I can answer "Why not use $Framework?"
My current project (a large admin system) is crying out for the more complex parts of the admin UI to be built in React, Angular etc. The problem is it's an all-or-nothing situation.
When picking up a new technology I want to add a little bit to the current project, a bit more to the next, and so on. Progressive Enhancement for the developer. jQuery lets me do that; the frameworks don't.
I have used KnockoutJS in 2 locations in this project; both for a single component on a page which needed to be very dynamic. I have been impressed that it doesn't try and take over, and lets me think of enhancing the experience (and my skills) one component at a time.
Vue.js is a really great way to add progressive enhancement. Can add it to a single page or even a single element on a page and not effect the rest of the page.
We've been replacing certain parts of our vanilla js application with small React apps and it's worked brilliantly. There is a really good talk by Ryan Florence where he replaces backbone components (i think) with React components.
Yes, it's not too hard to replace one at a time. We run an extremely feature rich browser client application and have slowly been dropping in independent react components to replace legacy code as necessary.
Erm, because that's the impression I've got from the tutorials and demos. I guess a "Add $Framework to a bit of your app" isnt' sexy: the ones I've seen add their own routing and focus on SPAs. Rather than "Here's some incredibly complicated information to display, and we need to be fairly interactive over it (and how other data on the page affects it)".
Would it work if you didn't have a vanilla JS application but a traditional web app?
You're right that most tutorials dive in with both feet, but this is literally the very first text on https://facebook.github.io/react/
>Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project.
I've seen a traditional server side rendered rails web app try to do this. The traditional pages are nice a usable and fast, and then you hit a page with a react component and you need to wait a second or more for react to boot up, or whatever it does. How do you handle that?
I don't know what you're referring to, if it's an actual case you've seen, or if people talking about React huge size gave you the idea that it behaved like that.
In any case this is an implementation problem. React base is around 30kb after min + gzip, and executing the code should take hundredth of seconds on page load unless you're on a really bad phone.
Maybe you've seen this behavior because of components designed to perform one or several high latency requests before they display data? If that's the case, then it's easily fixable by providing the initial data along with the page, or improve latency by many means.
It is an actual case I've seen, more than once. I didn't debug it, I just removed it. But the initial load and render of react components is not fast. Can you point me to a live site where it is (and serving an initial server side rendered page is cheating).
They always seem to have an example of being used on a small part of the page, but nobody actually tends to do this and there isn't much in the way of blog posts about it.
Yes of course, for new projects now and for the foreseeable. Its terse expressive fluent syntax alone is reason enough to use it for me. Nothing else comes close for ad-hoc dom work, and your user almost certainly has it cached already anyway.
Unfortunately when you score a page for speed things like jq and bs are counted against you when they are likely to be cached. Why don't any scoring systems (that I know of) able to take can asset popularity into account for things like this?
Just as interesting - I'd like to see stats on which CDNs offer the best chance of a warm cache for my visitors - and which versions of various libraries have the best chance of being cached.
If only the browsers would support caching based on the sha384 of the file then the script/css's integrity property would be even more useful and it wouldn't matter where you were serving it from.
Yup, every project I've ever done has used jQuery:
- Nothing I've done is "big enough" to warrant a front-end framework
- It's guaranteed cross-browser
- There's a large ecosystems of plugins
- The documentation is excellent
- The API is clean, abstracts away some of the fiddliness of "vanilla" js
That sounds much like "why would you push that nail with a hammer is there's a perfectly usable shoe just right there?"
Why does anybody use a library? Because it has some good pre-writen code you can reuse. Vanilla js is verbose, full of extra control sequences and easy to get wrong.
Had this very conversation today - I still like jQuery as previously it was extremely useful for projects (circa 2011).
I haven't really used it in the last 4 years as most of my projects have had frameworks in place.
I definitely think it still has it's place - it is more concise and reads a lot nicer in many cases than vanilla JS for DOM manipulation and AJAX requests.
XML. For HTML jQuery is rarely worth the dependency any more for me, but trying to consistently parse and manipulate XML with vanilla JS across browsers feels like working with HTML did five years ago.
I know XML is not cool any more, but sometimes you don't have a choice.
Most websites based on full flegded js frameworks break entirely without js. I started to miss the "progressive enhancement" of the jQuery days. I had that thought a few monthes back.
Most definitely, yes. I have plenty of projects where there's enough JS interacting with the DOM to use jQuery, but too little to justify adding the entire React package. Furthermore, a number of my projects 1) might have to be taken over someday by developers who don't know React, 2) might eventually have jQuery added anyways for a quick plugin (slideshow, etc.), or 3) have jQuery included already because the client insists on the use of a particular CMS.
If it works and you know it, why not? They're still working on it, it's not going away any time soon, and just about everyone who knows JS knows jQuery. This is particularly true is JS is not the core of your application.
Should you write a SaaS SPA in nothing but HTML and jQuery? Probably not.
Should you write the entire application in React just because you want to have a nice fade out effect on alerts and notifications? Definitely not.
Last big UX project I did (a GA admin console) used "Valilla JS". It was my first such project (not sure if it would be appropriate to call stuff done in early 2000s Vanilla JS). But in another recent refactoring I had to replace an ancient (IE5) datepicker and was dismayed to find there was not broad support for input type=date so I used one of the quality JQuery UI datepickers.
I use it. Selectors are great reason. Also the worst traits of Enterprise Java circa 2009-2010 have infested Javascript - so I tend to avoid modern JS frameworks like the plague.
Isn't that like asking why jQuery exists?
Personally I still believe that JavaScript and HTML should be separate, like HTML and CSS. I know that might make sound old, but I really dislike having a template language embedded in my JavaScript library, and as a result I end up disliking most of the newer frameworks.
I know jQuery, the documentation is good, it's easy to get help, and it makes sense to me in a way React, Angular and others frameworks do not.
Yeah, I could use plain JavaScript, I could also just use Python and not have a Django or Flask dependency. It's just easier and more productive to take the dependency.