Stepping Backwards from AngularJS to JQuery – An Experiment
hundredminutehack.blogspot.com
Stepping Backwards from AngularJS to JQuery – An Experiment
1–10 of 68 posts
Re: Stepping Backwards from AngularJS to JQuery – An Experiment
#2Giving up Angular did force me to think more about the DOM. Vanilla jQuery doesn't insert itself as readily into HTML code as an Angular directive can.
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.
Re: Stepping Backwards from AngularJS to JQuery – An Experiment
#3I think there's a better approach to handling the delete buttons that's pretty common when using jQuery. Instead of each button having it's own handler function I would specify an event handler on a single DOM element (e.g. a list container) with something like $('#itemlist').on('click', '.delete', deleteItem). When 'deleteItem' is called 'this' will be the clicked button element that could have an attribute like 'data-itemid=123' which you use to fill in the 'id' part of the service call. And from there, after a successful service call, you can usually get at the parent element you want to remove from the list and take just that out instead of refreshing the entire list.
EDIT: Had the 'on' parameters mixed up. Here's the api doc: https://api.jquery.com/on/
Re: Stepping Backwards from AngularJS to JQuery – An Experiment
#4I found this interesting because it seems to have been written by a person who learned Angular before jQuery. I haven't run into that before.
Maybe I'm getting old.
Re: Stepping Backwards from AngularJS to JQuery – An Experiment
#5Giving up Angular did force me to think more about the DOM. Vanilla jQuery doesn't insert itself as readily into HTML code as an Angular directive can. 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…
I am personally fully behind your shilling and try to shill on your behalf whenever possible. It's sad how little interest intercooler has managed to garner when it's a fantastic antidote to so many things that are wrong with client-side development.
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.
Re: Stepping Backwards from AngularJS to JQuery – An Experiment
#6Caveat: novice programmer here.
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?
Re: Stepping Backwards from AngularJS to JQuery – An Experiment
#7Next time, try dropping jQuery, too, and just using vanilla JavaScript. Just for fun. Simple DOM manipulation is now as simple in vanilla JavaScript as jQuery, with the only big advantage jQuery has now is if you're animating. You may find you're not missing much. You'd have to get used to slightly more involved Ajax syntax, unless you can target only new browsers, in which case the `fetch` API is just as convenient as jQuery's Ajax.
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.
Re: Stepping Backwards from AngularJS to JQuery – An Experiment
#8I found this interesting because it seems to have been written by a person who learned Angular before jQuery. I haven't run into that before. Maybe I'm getting old.
This is a very good point; I also found the submission enlightening for that reason -- because of the 'rediscovery' of jQuery, and how for simple use-cases, it's actually fairly palatable.
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.
Re: Stepping Backwards from AngularJS to JQuery – An Experiment
#9Giving up Angular did force me to think more about the DOM. Vanilla jQuery doesn't insert itself as readily into HTML code as an Angular directive can. 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…
I am personally fully behind your shilling and try to shill on your behalf whenever possible. It's sad how little interest intercooler has managed to garner when it's a fantastic antidote to so many things that are wrong with client-side development. 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 a…
Thanks Andy!
Re: Stepping Backwards from AngularJS to JQuery – An Experiment
#10I found this interesting because it seems to have been written by a person who learned Angular before jQuery. I haven't run into that before. Maybe I'm getting old.
I found that odd. I do worry that many people use technologies because other people working at a completely different scale or in a completely different domain have hit a ceiling which wouldn't really apply to most people. They are convinced to start with a more complex and more difficult technology that's solving problems they are unlikely to be facing any time soon.
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 ;-)