It uses jQuery extensively. The frontend developer in me wants to make a fork written in typescript using react and redux toolkit to manage keystrokes. Then I realize it is just a fun toy.
This industry’s best kept secret is that jQuery is as awesome today as it was 10 years ago.
The DOM API is so much nicer than the native one it’s not even funny.
And when you are not dealing with thousands of buttons you realize you don’t need a virtual DOM. You may even come to the conclusion that if you have so much state in a single view, maybe your UI sucks.
And that beneath all the React hype, there were people doing “components“ and “server side rendering” in PHP, Python, Ruby, Java for decades.
But I’m not gonna get grumpy this early in the morning.
While i use React at work for bigger things, I've come to use Vue for almost all my "smaller" hacks since it becomes a win to use almost as soon as you start using inputs. After this it scales pretty well up for anything that is on "one page".
Apart from work things the main example would be a that I built a small audio sequencer hacked together with Vue. That project would've been suicidal to do in JQuery but also went far quicker to make than if i would've been messing around with doing everything "properly" in React. (Iirc the entire thing is <1000 loc)
My main "issue" right now is if i should just leave it and let it be useful at the current level (perfect for creating small retro-style chip tunes with fixed audio channel tone generator controls). Or to remake it in React to enable more easily supporting stuff like view plugins (to control parameters custom instrument/filter plugins), I.e. in principle making it more "application" like rather than just a small one-page hack.
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”.
(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.
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:
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.
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.
> 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!
> 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.
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)
Then you realise this is what a lot of people spend their working lives doing, rewriting frontend code in a different framework for no good reason other than they want to.
Yeah, no native tools ever get written in different languages and frameworks. Or is it only not acceptable when Front End developers do it?
Personally I've never known anyone do this for any other reason but educational reasons. When I wanted to learn React, I copied other websites in React. I do similar things when I'm learning Golang, or C, or any other language I'm interested in.
I’m not sure what the go/C equivalent of “Ugh, you’re using jQuery? Time for a rewrite” is. It happens a lot more in frontend land than in the rest of the developer ecosystem.
You're describing switching to a different language. There's plenty of that going around no matter what language you're using. But I don't recall once seeing anyone decide to rewrite something in the equivalent of a different C "framework". There's certainly a lot less of that outside of frontend development.
That's because if you want to write for the Web Platform, you haven't been able to switch languages; you were largely stuck with JavaScript for decades.
Contrast that to writing for the Windows Platform--you could easily choose one of many languages.
You have a fully working application where the only major issues can be easily fixed by adding `event.preventDefault()` to the keystroke handlers. Instead, you want to throw all that away and rewrite it with some new tool/framework, inevitably introducing new bugs and issues. Unless this is a joke, the question is why?
Complain about JQuery yet this loads in less than 300ms.
Struggle to imagine any React/Redux engineer I know getting this on the screen in even 3 seconds let alone sub 1. Depresses me how even 10 second webpage load times are considered acceptable in that toolchain, I know it's capable of better but it clearly needs more work to get there than people are willing to put in.
Why single out JS? Everything developers do nowadays is overcomplicated. See all the posts from large companies saying they switched to this and that for tenuous at best reasons. Then we get a post later saying they're switching back.
The problem is, the industry favors overcomplicating developers, because there's more of them, over those who actually have a clue what their code is doing.
Yet, it's fast. Browsers will always be optimised for the most common JS functions, which even today are nothing else, but showing very basic jQuery based interactive pages.
