Paralysed by choice:
1) Which client-side scripting language should I choose? Let's see... Only one supported - JS it is.
2) Which client-side GUI layout language shoud I choose? Hmm... I will go with the only one supported - HTML.
1) Which client-side scripting language should I choose? Let's see... Only one supported - JS it is.
2) Which client-side GUI layout language shoud I choose? Hmm... I will go with the only one supported - HTML.
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).
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.
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)
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.
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.
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?
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.
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.
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)
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.
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.