Tero Parviainen

Learning computer programming you mean? If you think creating something musical would motivate you, JavaScript using the WebAudio API isn’t a bad starting place, as it provides high level components such as oscillators and filters that you can plug together without needing to know the internals - for example, check out https://teropa.info/blog/2016/07/28/javascript-systems-music.html, which is aimed more or less at newcomers to programming. Another good starting point if you are using Mac (and iOS, if you like) is AudioKit, which has some great interactive “playgrounds” and similar high level “blocks” of code as WebAudio, which you can wire together to get quick results.

If you want to write your own plugins or audio software you’ll need to learn C++ at some point, which I think is a fairly complex language to start with and likely to be frustrating in terms of getting quick results, but your mileage may vary!

A colleague of mine learned C++ as his first “real” language (which is now his job) because he started out playing around in SuperCollider (a DSL for computer music stuff) and wanted to turn his ideas into real plugins, but it can get pretty complex pretty quickly so I’d say you’d have to be pretty motivated to do this!

If you do want to go down this route I would probably start with the aforementioned SuperCollider or something similar (maybe Max/MSP) to get an idea of how the musical side of things works without having to master C++ at the same time, then when you…

You are On. The. Money.

When I first started dabbling in web programming a few years ago, I quickly learned about jQuery from SO while looking up common patterns to create the behaviors I wanted in the browser. But even accounting for my unfamiliarity with the browser paradigm, jQuery always rubbed me the wrong way because of how loosely structured it allowed you to be and the amount of leaky scope it encouraged.

I finally decided earlier this year it was probably worth my time learning a framework just to get some structure in my code, so I asked a webdev friend if he had any recommendations for a JS framework I should try; he pointed me towards Vue. I had never heard of it and was skeptical, but I started working through the quickstart guide (Vue docs are great, another +1 to Evan!) and I was hooked before I finished the third example. It was night and day from jQuery, but easy to learn. My experience so far is that Vue (in contrast to jQuery) is astoundingly flexible for how terse it is. My code was probably bad, but rewriting a jQuery page in Vue usually halved my linecount.

>no transpilation

This is huge to people who just want enough JS to get their proposed feature working and don't want their whole site to be JS, and to beginners. True, at this point I have started getting comfortable with the npm/webpack/babel/es6 stack and I enjoy the things it makes convenient - but at the beginning it's a pretty nontrivial learning curve and delayed benefit for a dev team…

My suggestion is to go through some full-stack tutorials. Vary them up to learn how workflows with different library combinations/boilerplates feel for you.

For React my quick and dirty intro a few months ago involved: http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webpack/ and then following along with http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html

The first link is very light on dependencies and brief. The second link is basically a mini-ebook going from front-end to back-end but walks you through the choices very well.

What you want to do is build apps, so look for tutorials that make you build an app from start to finish. Do a number of those, semi-rotely, and you'll develop familiarity with the tools and methods they use. That's when you want to deep dive on specific libraries and stacks.

Imagine how complicated it would be to try to learn Rails by learning ActiveRecord and then ActiveSupport etc. The interesting work happens when all the dependencies are combined -- and the challenge/beauty of the framework is how it combines them -- not when they are taken as individual libraries. Boilerplates are shitty, immature frameworks but similar principles apply.

The author is indeed well aware of WebSockets limitations, and OP's "Examples of where it's acceptable/recommended to use WebSockets" seem sound.

The problem is that the appeal of oooh-shiny is so strong that some (many?) developers and influencers do end up "using WebSockets for the wrong thing". Last case I met: a tutorial for a client+server js app using React & Redux [1], building... a CRUD voting application. Quoting the article on why choosing WebSockets for this, "This is an app that benefits from real-time communication, since it's fun for voters to see their own actions and those of others immediately when they occur. For that reason, we're going to use WebSockets to communicate."

Well yes, WebSockets work here (modulo problems and missed benefits/tooling that are the whole point of this article), and socket.io seems like a nice library, but a good old long poll would have done just as well :)

[1] http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html

I was just reading a blog post where a guy had written about Steve Reich and Brian Eno's experiments and his attempts at replicating them. It was posted on HN a few days ago: http://teropa.info/blog/2016/07/28/javascript-systems-music.html

There are embedded YouTube videos, MP3s, and code samples to illustrate what he's writing about. He's implemented their ideas using the Web Audio API and you can run the code from within the page and listen to the music being generated in real-time. It's a real testament to how great the web can be.

I think being able to do things like that is worth all the annoying parts of the modern web, in the end. For the developer and the end user. I wouldn't want to go back to the old way. I think it's easy to focus on the annoying parts and take the good parts for granted.

First off, this article is 4 months old.
Second, <everything else that's mentioned here>

Third: You won't get the actual idea behind Angular without some good tutorials indeed.
This one gave me the best insight and i've been churning out my own angular based chrome extension with behaviors, services and modules within a week.

http://www.ng-newsletter.com/posts/chrome-apps-on-angular.html

Fourth: There's a new book in progress (with some free chapters) that explains how to build Angular.js from scratch and explains everything in-depth (Something that was indeed lackin from angular.

Site: http://teropa.info/build-your-own-angular/

Sample:
http://teropa.info/build-your-own-angular/build_your_own_angularjs_sample.pdf