Stepping Backwards from AngularJS to JQuery – An Experiment | Hacker News Reader

Stepping Backwards from AngularJS to JQuery – An Experiment

hundredminutehack.blogspot.com

36 pointspcote67 comments

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

Thanks Andy!

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.

Intercooler.js is quite cool.

Wait a minute. So you've got a down on Angular for turning HTML elements and attributes into JS-driven behaviors, but you're fine with Intercooler, which does literally nothing but that thing? You confuse me, sir.

Personally I welcome useful mentions of relevant alternatives in HN discussions, even if it's someone's own project.

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.

Carson is in a bit of a bind in terms of marketing Intercooler. There is a huge mass of community support for frameworks that he feels are taking fundamentally the wrong approach. If he doesn't make a strong case for pushing the pendulum in the other direction then he'll just get drowned out by the echo chamber. Sometimes the plucky underdog has to shout a bit more loudly than is considered polite.

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.

Well, everyone's entitled to their opinion on the best way to do things, and in the right context it makes for interesting discussions. As I said before, I find the mention of a potentially useful alternative a valuable contribution to such discussion.

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 hadn't heard of intercooler.js but that looks pretty awesome. Definitely going to check it out.

FYI, none of the code on your site works for me, possibly because I have cookies and localStorage disabled in my browser. Not sure if this is specific to your framework or a quirk of the website itself (hopefully not the whole framework, as I don't understand why this requirement would be imposed if not actually needed by the app that's using it... since the fundamental premise of the framework seems to be "it's lightweight").

Can you give me your browser/OS combo?

Mac OSX El Capitan, Chrome 52

Heh, that's exactly what I'm using. It must be some settings. Do you see anything in the console?

Yes: "intercooler-0.9.7.js:1507 Uncaught SecurityError: Failed to read the 'localStorage' property from 'Window': Access is denied for this document."

(As mentioned above, I have cookies and localStorage disabled via my browser settings.)

Perfect. I'll try to get that fixed for the next release. History support won't work, but there is no reason that the rest of the examples shouldn't.

Thanks, much appreciated (by me and others who like this simple/easy method to avoid cross-domain tracking on sites we're just browsing and not logging into).

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

We snapshot DOM state so that when the user clicks the back button we can dump the old content back in. We stick it into localstorage.

It should be an opt-in feature, but if it is breaking the other examples that's an ugly bug.

Fixed in dev, will be part of 1.0 release:

https://github.com/LeadDyno/intercooler-js/commit/1cd5809126...

I was actually just about to use jQuery + PJAX on a new project, but this looks much better! Perfect timing.

Appreciate the shill. Hadn't heard of intercooler, but looks very interesting. At our company we've recently been pondering whether to fully embrace the client heavy approach of frameworks like Angular - which we've found frustrating in many ways (mixing server and client templating, localization, duplicated validation logic etc). We've used PJAX in the past and this looks like a suitably modern replacement.

If you enjoy REST, intercooler dovetails really nicely with it: http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

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.

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/

yes, that is event delegation : https://learn.jquery.com/events/event-delegation/

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.

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.

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.

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

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.

It's probably featured in the Previous Contractor's portfolio though.

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.

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

That's not exactly the way I think of it. I try to be pragmatic about my tech choices, even if I might be wrong at times.

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

Well, I actually learned Angular 2 before I learned Angular 1.

This is an extremely confusing statement, considering that Angular2 is only at RC5 and has had many major breaking changes to the API and core components ranging from 3 completely different router builds, introduction of NgModules, greater integration with Observables, a compiler still being developed, etc all since it left "Beta" in May.

I'd have to guess you left Angular2 to go back to Angular1 considering the current state of development

Not really. I'm more of a backend developer, but around the time it went beta (early 2016) I felt it was a good time to be ahead of the curve. So I started learning it with no Angular 1 experience. I've followed it through the betas and RCs.

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 have a suspicion that this kind of thing happens with programmers who have not worked much on client side development moving to it from Enterprise Java development or similar disciplines. This suspicion also seems to be borne out/hinted at by the post.

Nope. jQuery came first. For me, it was a matter of spending a few years in Java shops. Most of the work was so server-side focused that I ended up forgetting a lot of my Javascript.

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.

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.

What's the big advantage of jQuery with animating? Are you referring to the animation built into jQuery?

Actually, looking over the new Web Animation API, it looks like jQuery doesn't even offer much of an advantage for animations as long as you're targeting new browsers that have the Web Animation API (yes, I was referring to the animation support built into jQuery).

Ah, ok. Yes, there are much better options out there than using the animation jQuery offers. At minimum you can use CSS3 transitions and animations before even getting to the Web Animation API. They would likely serve most needs nicely for regular day-to-day sites.

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.

> Yes, there are much better options out there than using the animation jQuery offers.

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.

I understand. Just look at it as controlling the state of the element, not the animation directly, and the browser animates between them for you.

> ...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://velocityjs.org/

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

http://vanilla-js.com/

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

That's classic, how had I missed that. And it's pretty old, doesn't even feature cool new DOM APIs like the Selectors API (ie, `document.querySelector`). Which allows the exact same syntax as jQuery (although it obviously returns a DOM element instead of a jQuery object).

Check out https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati... for animation without jQuery

Thanks, you're absolutely right. Web Animation API is one of the few new JS APIs that I haven't explored much, and I see I've been missing a lot. I tend to use CSS animation in production for most animations whenever I can, but I'm definitely going to keep my eye on support for the Web Animation API (although I'm guessing it won't be hardware accelerated like CSS for a while, if ever).

Using vanilla js is still a massive pita even with ES6.

Nowt's going to beat $(".thing") vs:

    document.getElementByClassNameWhichWordsDidIForgetToCapitalizeThisTimeManVanillaJavascriptSucks

    document.querySelectorWhoopsNoIMeantQuerySelectorAllGodVanillaJavascriptSucks

Design by committee, you get crap. Ease of use is incredibly important. And don't even get me started on on the fly dom manipulation, vanilla js really sucks for that.

    let div = document.createElement("div");
    div.iMAlreadyBoredTyping = "Yes";
    node.appendChild(div);

    $(node).append($("<div>").data("quick", 1"));

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?

If angular were produced by superior engineers, it would be easier, not harder, for lesser engineers to grok it.

The problem is not with you, but with a those that made angular more complicated than it could have been.

For Angular 1, I'd recommend sitting through Dan Wahlin's hour intro to Angular. Don't code, just watch. It really helped me get that initial chunk of knowledge in my head.

https://www.youtube.com/watch?v=i9MHigUZKEM

I've run into a lot of people who found angular hard to pick up; it's not just you.

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

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

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.

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

I think Angular takes a considerable amount of time to wrap your head around. I think the largest issues that you will most likely run into is an ng-repeat with large collection of objects (which, due to dirty checking, may impact your site), memory leaking, and using multiple controllers or controller as syntax.

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.

I think the reason Angular2 might be difficult for a novice programmer is because of the nature of problems it tries to solve. It is an MVC framework with an emphasis on dependency injection and test-driven development. A novice programmer probably has at most a limited understanding of MVC, dependency inversion, and TDD, so you would need to learn more about those concepts to even work through the tutorial. Taking that into account, in may or may not be the right tool for the job depending on the problem.

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

https://learn.jquery.com/events/event-delegation/

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

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

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.

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.

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

Step forward to ScalaJS and dont look back?

https://www.scala-js.org/

Reply on news.ycombinator.com