These are becoming less true. For #1, you might also choose CoffeeScript, ClojureScript or Dart. For #2, you've always needed more than just HTML: CSS at least. Now there's Canvas and WebGL, and some frameworks like React are starting to abstract the DOM away somewhat. Programming in ClojureScript with Om/React does not feel much like programming with HTML/JavaScript at all.

Beyond that, there's an explosion of tooling. Build tools, minifiers, preprocessors and compilers; systems for managing dependencies and run-time library loading; shims and polyfills to emulate new functionality on out-dated platforms; and, of course, frameworks which seek to abstract all of this stuff away behind a neat facade, providing a stable platform that you can build on without needing to worry about the details. Nobody has figured out how to do this properly yet, and I'm not hugely optimistic about the future of such projects.

I'm not quite old enough to remember the history of GUI programming from the mid-80s to mid-90s, but I wouldn't be surprised if the proliferation of tools and libraries was similar then. Even starting out doing Windows development in the mid-90s, there were multiple options - at least Visual Basic, Delphi or C++, and there were multiple C++ frameworks (MFC, ATL, varieties of COM-based stuff, and those were just Microsoft's official options, and this completely ignores non-Windows platforms).

It would be interesting to do a retrospective on such technologies, to work out why some survived and others didn't. It would not have been at all obvious in 1995 that Objective-C would be a mainstream language for user interfaces nearly 20 years later, and C++ would have fallen away, and that people would still be using NextStep in the form of Cocoa but nobody would be using MFC. My feeling is that there are some properties of good design which have enabled ObjC/Cocoa to survive for the long-term, and it would be interesting to figure out if any of the current crop of web front-end tools exhibit these properties (fwiw I get a good feeling about a lot of the ClojureScript stuff, especially Om).

The tool and libraries proliferation was a bit similar, but on a much smaller scale, since they were largely proprietary, and customer acquisition channels were things like the Programmer's Paradise ads in Byte magazine.

There is nothing magical about ObjectiveC that led to its current success, except the attachment-at-the-hip to a large and growing lucrative market the growth of which has been aggressively promoted by a deep-pocketed player. The Java ecosystem was in a similar situation before the dotcom crash, with .Net playing catchup.

Windows: QT, MFC, Windows Forms, XAML/WPF, Awesomium.

I am about to dive head first into web/web app programming. Would you suggest I do it all through plain vanilla HTML/CSS/JS?

I mean I wanted to start with these (I first wrote web pages in the late 90s with just HTML) as I believe you do need a fundamental understanding of the foundations to be able to make a good choice regarding frameworks. But would you say just stay with those, and don't worry about SASS/LESS, Angular/JQuery/etc..?

Or can the right framework really make you more productive? (I really do wonder about this because all I see with a lot of frameworks is that they impose a way of thinking onto your coding)

You can do it in vanilla HTML/CSS/JS but you will eventually reach the same conclusions more seasoned front-end developers have reached. Saying that front-end developers should just use vanilla is as silly as telling server-side developers they shouldn't be using any web frameworks.

> * But would you say just stay with those, and don't worry about SASS/LESS, Angular/JQuery/etc..?*

What you use should ultimately be up to you, but I would approach it in the following way :

1. start with what you need to complete the project

2. add new components / frameworks / libraries on a must-have basis

I'd be tempted to recommend ditching jQuery while learning JavaScript, but don't feel that strongly about it. A lot of Stack Overflow answers will be provided with jQuery syntax - so that's something to keep in mind.

Don't worry about SASS/LESS and client side "MVC" frameworks. Until you need them, those are just new fiddly things to learn that distract from the actual point of the exercise.

I've looked into what it would take just to dump jQuery for DOM traversal and manipulation. It can be done in plain JS, but you end up rewriting a lot of methods to fill in the gaps already filled by jQuery. My conclusion was, it's still easier and more productive to use jQuery.

> It can be done in plain JS, but you end up rewriting a lot of methods to fill in the gaps already filled by jQuery. My conclusion was, it's still easier and more productive to use jQuery.

Of course. That's the entire point of jQuery :/

If your goal is to put up an application - jQuery is basically industry standard. If your goal is to develop a better intuition about how the DOM works - then stick to JavaScript.

Lets just say I need HTML/CSS/JS, how do I know which components/frameworks/libraries are a must have? They all use the underlying tech (unless, and this could be true as I'm very rusty, they enable something fundamentally different)

The only comparison I can make is the difference between ASM and a high level language. I could literally (physically?) see the improved productivity in my workload as I switched from x86 to C. Is there the same level of shift between JS and coffeescript?

> Is there the same level of shift between JS and coffeescript?

Opinion :

I've never used coffeescript, nor have I really been tempted to. JS isn't a conceptually difficult language, and the wrapper libraries (e.g. jQuery) make day-to-day work a snap.

Given that, I can't really see the rationale behind a syntactic sugar layer on top of a mature and straightforward ecosystem. Even back when I wrote Ruby full time, coffeescript felt more annoying than intriguing.

> The only comparison I can make is the difference between ASM and a high level language. I could literally (physically?) see the improved productivity in my workload as I switched from x86 to C.

Oh wow, it's nothing like that at all. JS is already a high level language after all. Syntactic sugar won't be that much of a boon unless you're already proficient with the languages that inspired CS.

Personally, I'm orders of magnitude more productive with C than x86. If I thought I'd see even a fraction of that productivity gain by switching to [insert anything here] I would switch to [insert anything here]. I mean that sincerely.

If you are just starting out, do the very basics. Write your HTML and CSS and JavaScript by hand, because you will want to know what your tools are doing, and when its time to switch to a new tool you will know what it's doing, too.

But be aware that most employers will demand, sensibly or not, that you know whatever the latest fashionable toolkit is. Even if you could learn it in 3 days, they'll want you to have already learned it.

I am not quite 'just starting out' more like 're-starting out' I liked to think of myself as a lapsed programmer. I am also not looking for an employer (I just got lucky in that I don't need to work for someone ever again)

But what I do like is your idea of knowing what a new tool is doing. My big reason from learning everything again from scratch is that I've found that 30 years ago, I knew how to make things happen in assembly language. 20 years ago I switched to high level languages. And somehow, about 15 years ago I became a cargo-cult programmer.

So in a way I'm trying to regain my roots, but I also am doing it with an eye on being super productive in the future.

The right framework absolutely makes you a lot more productive. Particularly when it comes to maintainability. Plain HTML/CSS/JS may be fine on the first write but they don't encourage good DRY habits. I think any toolset imposes a way of thinking, and the way you get from a good framework isn't any worse (in fact it's often better) than what you get from HTML/CSS/JS.

But what happens if you approach your plain vanilla H/C/J writing with these DRY concepts in mind?

One of the reason I would like to use frameworks/libraries is not because of the concepts they introduce, but to basically stop me from going down a rabbit hole and applying the concepts to the extreme. For example, when I am coding something from scratch, and I start to abstract up levels, I just. Keep. Going. I eventually found a soul mate in Knuth with his literate programming, and that has (finally) put an end to the levels of meta abstraction I head into, but I do see (hope) that frameworks will allow me to actually get shit done, instead of traversing the wormhole that is architecture design.

> But what happens if you approach your plain vanilla H/C/J writing with these DRY concepts in mind?

Once you know a technique you can apply it in almost any language and it really doesn't matter which you choose. But that's why it's very important to use good tools when you're starting out. (I'm reminded of an analogous situation where a friend pointed out the irony of personalized golf clubs: a scratch player can pretty much pick up any clubs and play with them, whereas it's the beginners who are still picking up their technique that would really benefit from having personalized clubs).

Frankly, and this is probably not what you want to hear, if you're wanting to learn it right I'd stay away from the web until you've done at least some UI in a well-regarded native toolkit (I'd recommend Qt, whether from C++ or from Python; I've heard good things about the Apple one but haven't used it myself). The web has a lot of legacy cruft and multiple ways of doing something that tend to obscure the principles and make it a poor learning environment, whereas if you've already learnt the basics using something more consistent then it becomes a lot clearer. But by the same logic I'd say that if it has to be the web, you should start with a big, opinionated framework (e.g. Angular) and try to understand its idioms before diving under the covers.

(But then I could never get on with Knuth at all, so your style may be different from mine)

If those were the only choices that need to be made, then perhaps it would be easy.