
Stepping Backwards from AngularJS to JQuery – An Experiment - pcote
http://hundredminutehack.blogspot.com/2016/08/stepping-backwards-from-angularjs-to.html
======
carsongross
_Giving 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](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.

~~~
andybak
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.

~~~
quantumhobbit
Keep shilling. I had never hard about it until now. I love the simplicity.

We need more libraries that just do one thing well instead of kitchen sink
frameworks like angular.

------
jasonkostempski
I 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/](https://api.jquery.com/on/)

~~~
nicolasMLV
yes, that is event delegation : [https://learn.jquery.com/events/event-
delegation/](https://learn.jquery.com/events/event-delegation/)

~~~
pcote
I almost went down the event delegation route. The only thing that stopped me
was having stumbled upon a tactic that happened to work where I just attached
individualized event handlers one at a time. I appreciate the input and will
make sure to give event delegation a second look.

------
impostervt
I 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.

~~~
andybak
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 ;-)

~~~
greenshackle
My friend was brought in by a client after the previous contractor had spent
300+ hours coding a simple organizational website - here is who we are, here
is our phone number - using node.js. I doubt the website will ever see more
than 20 concurrent visitors.

~~~
dcherman
Even still, that's just the completely wrong technology to use for something
like this regardless of scale. It sounds like it's literally static content.
Just write an HTML file directly if it's a single page, or use something like
`Assemble` to get easily re-usable partial support if you have multiple pages
that want to share a header and footer or something.

~~~
greenshackle
It was 5-10 pages. Static content. Yeah, even if they had 10k concurrent users
node.js would have been the wrong technology.

------
jnbiche
Next 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.

~~~
beebs93
> ...with the only big advantage jQuery has now is if you're animating.

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://wilsonpage.co.uk/preventing-layout-thrashing/) \-
[http://velocityjs.org/](http://velocityjs.org/)

~~~
jnbiche
Yeah, but then you just add velocityjs (as you reference). But I'm really
referring to simple animations here, for anything complex I'd use Canvas or
possibly SVG (although SVG can also have performance issues).

------
pbreit
Caveat: 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?

~~~
asciihacker
Angular is difficult to grok because it makes computer programming second
class and limited to what you can cram into HTML tags.

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.

~~~
throwanem
> Angular is difficult to grok because it makes computer programming second
> class and limited to what you can cram into HTML tags.

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

~~~
asciihacker
I'm just saying that everything that Angular makes convenient via the hints it
throws in HTML is handled behind the scenes by calling Javascript libraries.

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.

~~~
throwanem
> I'm just saying that everything that Angular makes convenient via the hints
> it throws in HTML is handled behind the scenes by calling Javascript
> libraries.

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?

------
nicolasMLV
You can use event delegation for button handling : `$(document).on('click',
'.button-list', my_function);`

[https://learn.jquery.com/events/event-
delegation/](https://learn.jquery.com/events/event-delegation/)

~~~
tdubbs
Thanks for posting this. It's sad how few people seem to know about event
delegation...

------
c-smile
Just in case. I've written these while ago:

Routing, view, controllers in 60 lines of code + jQuery:
[https://github.com/c-smile/spapp](https://github.com/c-smile/spapp)

Template-less repeatable sections / lists in 100 lines of code + jQuery:
[https://github.com/c-smile/repeatable](https://github.com/c-smile/repeatable).

------
matchagaucho
Amazed at how Angular has created a generation of programmers that accept
2-way data binding and MVC as "the only way" to develop web apps.

JQuery encourages more fluent, purely functional reasoning, and one-way data
binding of immutable data objects.

~~~
pcote
Functional, yes. I can't think of too many cases where JQuery has every
prevented me from mutating anything.

------
asciihacker
Step forward to ScalaJS and dont look back?

[https://www.scala-js.org/](https://www.scala-js.org/)

