| HN Mirror

I never understood this “suicidal” critique of jQuery. I've never got so tangled up in my own code to feel the urge to switch to a different model.

I've seen Backbone.js, Angular, React, etc, all come and go and none ever answered the “why would I want that” question to me. I remember using Prototype.js and MooTools.js and when I saw jQuery's home page I knew instantly the “why” and the answer was an instant and rejoicing “yes”.

stevenhubertron 2065 days ago

I use https://umbrellajs.com/ whenever I can get away with it. Lesser overhead than jQuery but much of the convenience I need for my prototypes.

(TL;DR; It's just a different way of working with less manual code)

I never spent much time on webdev in the era where jQuery came into being but as I've understood (and from the jQuery code I've seen since) it solved basic issues in working with manipulating the DOM and gives powerful animation tools,etc. So as you say the upgrade over the browser API DOM manipulation is obvious, clear and direct.

I'd say that my background is mainly from games, where you usually setup your own data structures and then rendered them as it fit.

From time to time I've worked on custom tools on native platforms (win32/GDI/MFC, Java/Swing,etc) and working with these is conceptually similar to using the DOM (manipulating objects like adding buttons, responding to events, reading data from input boxes on events,etc) and there is always relatively lot of work with shipping data in and out of the UI objects (either keep data synchronized between UI and internal model or reading data from the UI continually).

Compared to your game rendering code that usually just needs to iterate internal data this always felt like a lot of manual work to keep UI and internal data in sync.

Considering for example a 3D program where you can drag around an object with some arrows, while those arrows are dragged an input-box is updated with the new values and if you want to align the position you might edit the value manually in the input box and have the 3D view show the new position as you edit it. On top of these 2 sources of value changes you might have an animation system wanting that might change these values while animating (so that they are visible to the user), this kinda stuff is usually a buggy nightmare to maintain once you have it in a few many places.

This is why I like Vue and React (Angular.JS also had this to a degree even if it's implementation was weaker than Vue), with both of them you only need to concern yourself with how your internal data works/looks and operations are simple to do since they only operate on that internal data.

Then the Vue templates (or your React rendering functions) takes care of visualizing it with the associated automatic functionality to adjust the internal values if changed by the user.

React: https://github.com/tastejs/todomvc/blob/gh-pages/examples/re... https://github.com/tastejs/todomvc/blob/gh-pages/examples/re... https://github.com/tastejs/todomvc/blob/gh-pages/examples/re... https://github.com/tastejs/todomvc/blob/gh-pages/examples/re... https://github.com/tastejs/todomvc/blob/gh-pages/examples/re...

Thanks for sharing. I have very little experience with game engines but React/Vue always resembled them to me a bit. Here's the data, render when changed. I just don't think it's needed in most Web cases.

Sure, if you attach behavior code to every interactive element directly, all of which are controlling the same portion of the screen and depending on each other, it's a recipe for a mess.

If, however, you call somewhat generalized functions on those events, with basic DRY strategies in mind, it's all very clear and manageable well into the thousands of lines, with no need of running a gaming engine in JS, creating a templating language that must be transpiled, etc.

edit: >less manual code

jQuery code if often smaller and clearer, I mean check this classic:

jQuery: https://github.com/tastejs/todomvc/blob/gh-pages/examples/jq...

https://github.com/tastejs/todomvc/tree/gh-pages/examples/vu...

And that was my original point, using React for a small one page thing like this is grossly overkill but Vue is a good smaller alternative at this scale that gives you most benefits.

I looked at the jQuery example above and checked the Vue example in the same repo. That example has about as many lines total but the Vue example is 30% smaller in total due to shorter lines.

ep103 2065 days ago

mooTools was great back in the day (oh man, we're old). And jQuery was a great improvement from that.

Prototype was a great initiative, but I think the community was right when it decided to go the jQuery route, and not append new functions to the prototype. Even though prototype never really caught on, working with websites where it was used partially, or scraping data on websites that used it, has caused me plenty of issues over the years.

You left out 2 frameworks that are important in answering your question, and those are YUI, and jQuery UI. And both of them attempted to answer the same issue. The issue was thus:

In jQuery's hayday, developers wrote code by appending jQuery scripts to events. If you click this button, then the code in $(yourButton).click(function(){}) would run. But at the time, writing OOP, or even well moduled code in javascript was extremely difficult to do, as very few developers invested time into setting up a module system via CommonJS, or AMD modules, with requireJS or Browserify or etc, and almost never did so by default with a normal jQuery page.

The end result is that once your average webpage hit a certain level of complexity, the page itself would have thousands and thousands of lines of JS, each one written as a completely standalone script, triggered off of some jQuery event on the page.

And this is just fundamentally not a good way to program. In what other world would we write code, and say that our architecture is that each user action can trigger a stand-alone script, and that's good enough? Except for JS it was worse, because without a moduling system, there were often conflicts and soft dependencies everywhere between said scripts. Above a certain complexity level, refactoring code from this timeperiod is a complete and utter nightmare. It doesn't help that the inability to program using cleaner architectures resulted in many programmers writing off JS as a "toy" and not a real language, whereupon many of these programmers would then go on to write "toy" level quality of code.

jQuery UI, and YUI both attempted to solve this problem by building a component based approach to organizing your events. Basically enforcing a very simple OOP framework in a world where writing AMD or CommonJS modules was a pain in the neck.

They're both okay. At my company there's still old code from before and after these frameworks came out, and among pages that have thousands of lines of JS, the pages that use these frameworks are miles and miles easier to refactor than the ones that just rely on pure jQuery. We usually take to just completely burning and replacing the pre-Yui/pre-jQuery UI pages, but the Y/jUI pages we can usually refactor or actually debug.

Backbone.js took the lessons learned in YUI and jQuery UI and wrote the first real framework that was any good at building a modern UI architecture that worked in the browser. I could go to a dev who was building a WPF app in MVVM, and explain backbone.js in a few minutes, and they got it. It wasn't perfect, but it was far better than what we had before.

Node.JS standardized how to actually write functional or OOP code in JS.

Angular and React took the lessons learned and failed by backbone, and added in the fact that with the advent of Node, people actually started writing JS as a first-level language.

Angular was an iteration on the problems attempted to be solved by yUI and jQuery widgets. That's to say, Angular's entire approach was to build a heavily boiler-plated framework so that individual developers could write UI scripts in relative isolation from each other, in a very easy to debug manner. It is and was basically what every large development project manager / team lead has been asking for since the early 2000s for JS development. A framework that is so boilerplate heavy, opinionated, and hand-holdy that it becomes easy to debug and review the majority of the code written by your junior JS devs. Its no wonder it was the first framework to heavily enforce static typing and typescript, or that it was pushed by Google. Though Angular has iterated many times over the years, its initial versions were explicitly written with the intent to be used by project managers writing JS who weren't programmers, and to me, it often feels like it is inspired by enterprise JAVA type decision making. You can use Angular for anything, but to me where it really, truly shines is if you have a webpage with a well defined layout, need specific parts of that page to have heavy but isolated user interaction, and your team is not a JS-first shop. This isn't the only place where Angular shines, but my god does it shine in that particular combination.

React took the opposite approach. It also iterated on the successes and failures of backbone. But it attempted to do so with an approach that provided the bare minimum for front end developers to write modern web apps, and give developers an opt-in approach to included what parts of the library they would like to use, and make it easy for developers to write their own packages to be used with the library. Where angular attempted to provide its own core libraries (and correct way to use them) for every possible need a developer could have when building a web page, react trusted the community to develop JS on its own.

Vue, mithril, etc all iterate on react's decisions.

I enjoyed reading that, thanks. It did, however, reinforced my impression that these frameworks are trying to solve a problem I don't have.

>But at the time, writing OOP, or even well moduled code in javascript was extremely difficult to do

JavaScript is still the same, you still can and pollute the global window object, use global variables, etc.

It seems these frameworks are mostly about enforcing a code style, best practices when dealing with large teams with very different experience levels. Since I work mostly alone and clients don't care what tech stack I choose, I guess I'm in luck.

ep103 2065 days ago

> JavaScript is still the same, you still can and pollute the global window object, use global variables, etc.

If you are writing in a modern framework, this is now not possible, without really, intentionally, breaking a lot of things to be able to do so.

> It seems these frameworks are mostly about enforcing a code style, best practices when dealing with large teams with very different experience levels.

Its more like finally having a real programming language, but for backwards compatibility, you can still peer under your framework and libraries and see all the nonsense that used to be available.

> Since I work mostly alone and clients don't care what tech stack I choose, I guess I'm in luck.

Most likely if you're a single person working on such projects, you usually won't hit the complexity needed to justify these tools. That said, since most modern work is being done within them, you are also missing out on the ability to leverage those capabilities when needed. But fair enough!

bboygravity 2065 days ago

Oh, so that's what all the JS slang was about in all those webdev vacancies I've seen over the past 10 years or so?!

I'm an embedded guy (very little idea about webdev stuff). Nice summary :)

webmaven 2065 days ago

> My main "issue" right now is if i should just leave it and let it be useful at the current level [...]. Or [...] making it more "application" like rather than just a small one-page hack.

Both, perhaps (ie. fork it)?

Maybe down the line (too many side projects already). I really should just add that little extra bit of work to make the Vue version usable.

UI wise i need to add an envelope editor instead of entering numbers manually, the player code already has support for envelopes although it needs a bit fixing with how sustain is handled.

Would be fun to "put up" the project for public consumption, took the opportunity to try out a serverless backend (since this isn't something i plan to manage myself or think will pull or cost in any real money) and that was fairly easy for what i have in mind (adding the possibility to share tunes and some 3rd party login for saving stuff maybe)

antoineMoPa 2065 days ago

Have you tried webcomponents?

Does it solve data-binding? From what I've understood of WC it's about making developing customized elements saner?

It doesn’t, and probably why it hasn’t really caught on.