Stepping Backwards from AngularJS to JQuery – An Experiment(hundredminutehack.blogspot.com) |
Stepping Backwards from AngularJS to JQuery – An Experiment(hundredminutehack.blogspot.com) |
And that's why you should use http://intercoolerjs.org for most of your stuff, and a bit of jQuery where necessary for more exotic UX needs. The people who got sick of a mess of jQuery code were right, but they went the wrong direction to fix it. We have to go back.
I know people get tired of my shilling, but intercooler really is a better way for many, and maybe most, web apps to be developed.
I recently used a touch of intercooler on a Django project and it just felt so right. Once I'd included intercooler.js itself, everything else was done via normal http attributes. It felt clean and lightweight.
We need more libraries that just do one thing well instead of kitchen sink frameworks like angular.
I would encourage you to tone down your rhetoric a bit, though. Intercooler looks like a good lightweight tool for projects with lightweight requirements, but based on your own documentation, the claim that it covers most of what is needed for most modern web apps just hurts your credibility.
Maybe one could argue that 'survival of the fittest' is working as intended here but perhaps the tipping point is occasionally in need of a nudge.
Happy to help you evaluate it for more advanced stuff (e.g. triggering client-side events from the server) just hit me up on the newsgroup.
EDIT: Had the 'on' parameters mixed up. Here's the api doc: https://api.jquery.com/on/
Maybe I'm getting old.
Heck, if you can can transpile to ES6 or if you're only targeting new browsers, you could probably even drop the Handlebars in factor of template literals without losing too much convenience.
Even Angular is still difficult for me to grok and sometimes I wonder if stuff that comes out of Google "suffers" (for me) from Google having unlimited resources and employing superior engineers? Would Google have a difficult time empathizing with "average" programmers with limited resources?
Routing, view, controllers in 60 lines of code + jQuery: https://github.com/c-smile/spapp
Template-less repeatable sections / lists in 100 lines of code + jQuery: https://github.com/c-smile/repeatable.
JQuery encourages more fluent, purely functional reasoning, and one-way data binding of immutable data objects.
1. NoSQL <> traditional RDMS because of scaling/sharding
2. Angular <> jQuery (or anything similarly lightweight) because of the issues around huge complex webapps
3. 'Fast' languages <> 'nice' languages ( ;-) ) because of performance concerns
4. Static typing <> Dynamic typing because of maintainability across large teams.
5. Docker/Microservices etc <> traditional architectures because of... I really have no idea...
So I guess the degenerate case is some poor chap learning web development who decides to write their Pet Store as an angular app with a Scala API backed by Mongo and Solr deployed to a Kubernates cluster ;-)
To pick on your NoSQL example. There was one project where I had a large set of records which were all JSON in a text file. There was no one set structure for it. Attempts to set up proper MySQL tables for these records didn't work out so well. It was only after the pain of trying that I decided that MongoDB made more sense for this "collection of documents".
All solutions go through a maturity cycle where we invent an ostensibly "better" way of doing it because we're frustrated with the old way -- jQuery came about because early DOM selectors were lacking, Angular came about because people built complicated client-side spaghetti code state machines with jQuery -- but eventually a new wave of people comes along and the 'new way' becomes the 'mainstream way', and the like.
Like this author has done, it's interesting to go back and rediscover how things were done in the past, and in many cases you learn more about the problem domain or your stack of choice by doing so. My age is also showing that Angular no longer counts as cutting-edge, early-adopter tech, but firmly in the camp of mainstream ways of doing client-side code.
After leaving my last job, I decided I needed to update my skills and Angular seemed like a good road to go down. It was only recently that I decided to return to the old jQuery well to see what I could do with it vs. Angular. I'm glad I did.
I'd have to guess you left Angular2 to go back to Angular1 considering the current state of development
While you can probably get away with using $.animate for very simple animations, you'll run into jQuery's animation performance problems before too long.
See: - http://wilsonpage.co.uk/preventing-layout-thrashing/ - http://velocityjs.org/
"Vanilla JS is a fast, lightweight, cross-platform framework for building incredible, powerful JavaScript applications."
"In fact, Vanilla JS is already used on more websites than jQuery, Prototype JS, MooTools, YUI, and Google Web Toolkit - combined."
Nowt's going to beat $(".thing") vs:
document.getElementByClassNameWhichWordsDidIForgetToCapitalizeThisTimeManVanillaJavascriptSucks
document.querySelectorWhoopsNoIMeantQuerySelectorAllGodVanillaJavascriptSucks
let div = document.createElement("div");
div.iMAlreadyBoredTyping = "Yes";
node.appendChild(div);
$(node).append($("<div>").data("quick", 1"));I used Mithril for a while and it opened up my eyes as far as thinking "functionally"; it makes your code easier to understand and extend.
If you use filters functionally with Angular, you can get great performance on large collections in a ng-repeat. Likewise, if you understand prototypical inheritance, it will make working with multiple controllers/states a lot easier.
I really enjoy developing Angular, but it took a lot of time to really process. jQuery just works out of the box, but for me, it feels like it is more for little snippets of codes across various pages. It just depends on what you are trying to do.
The problem is not with you, but with a those that made angular more complicated than it could have been.
One of them now works on the React team, and I found it pretty easy to pick up from the official docs: https://facebook.github.io/react/ . I recommend not bothering with stuff other than the base react library at first (although jsx/babel is nice); you can use react without it and potentially learn that later.
It's also totally valid to just start with basic js/html/jquery. The Mozilla's MDN docs for most html/js things are decent, and jQuery's api docs are pretty good in my experience.
Angular isnt really a Google product - Misko Hevery and another guy (both Google SW Engineers) developed in their free time.
Dart is a Google product and I would say is much easier to grok than Angular.
...say what? I've done a lot of work with Angular, and a lot of work without it, and it's possible that I might agree with what you're saying here if I understood it, but I don't. Can you elaborate?
However, frequent and obviously excessive claims about the merits someone's personal preferences tend to fall somewhere between noise and trolling, and IMHO they are much less welcome.
I recently picked up Angular 1 just because it seemed like a good idea (I often mentor others), not because Angular 2 wasn't in a good state. (If I had to do a project today, I'd probably go with v1, just because the ecosystem feels richer)
I would much rather the QooxDoo approach of writing apps in pure Javascript and using Javascript libraries instead of the HTML/JS/CSS soup that Angular tries to serve up to me as convenience.
It might be more convenient for someone who cant write computer programs. But for me it insults my ability to read, extend and use well-documented APIs.
Well, of course, but I'm not sure why this would be an issue. Earlier, less well implemented versions of Angular sometimes produced headaches this way. Current versions really don't. Considering the amount of boilerplate I find this saves me having to write and maintain - thus freeing me to spend effort on those parts of my application which are essentially complex, not just accidentally so - I find Angular a pretty clear win there.
Of course, maybe I just can't write computer programs, and my now almost two-decade-long professional career doing so is simply a preposterously unlikely fluke. Who knows?
(As mentioned above, I have cookies and localStorage disabled via my browser settings.)
If one really wants to use the jQuery animation options, there are plugins that will try to shift them to CSS3 options instead, but keeping the same syntax.
No doubt. I haven't used jQuery to speak of in the past 2 years, and the only time I've found myself missing it was when I needed to do some simple animation and wasn't using a library like d3 that could do it just as easily or easier.
And yes, I mentioned CSS animations in this same thread. It's what I've been using in production for animation for the past 2+ years, although it sometimes feels wrong to animate things in JS by adding and removing classes from an element.
Out of curiosity, what is it about intercooler's history support that requires localStorage? Can't it just use history.pushState? (I assume there's more robust functionality involved, but as I'm not yet familiar with how intercooler works figured I ask).
It should be an opt-in feature, but if it is breaking the other examples that's an ugly bug.
https://github.com/LeadDyno/intercooler-js/commit/1cd5809126...