Hacker News Reader

Comment by joshontheweb | Hacker News Reader

In my opinion it's a bad idea to begin learning any web dev stack by using preprocessors like haml, coffeescript or less. You need to have a solid understanding of HTML, JS, and CSS first so you can make sense of the maddening quirks the preprocessors can cause.

View on HN

This is an approach reminiscent of some of the most brilliant professors that I've encountered. And of senior software and hardware folks that already understand the whole stack. And of the Unix man pages.

Technical education (much like a user interface, for that matter) is all about progressive disclosure. Hit a freshman with details that are natural and fundamental to a Master's or PhD, or hit a web n00b with Javascript or CSS up front, or the contents of a classic man page, and you're going to overload and overwhelm most of the folks.

Moving along to the quirks and the details is certainly necessary as a n00b advances, of course. But it's not where you want to start. A n00b needs to get some things understood and working, and to learn how the pieces fit together, and then work toward an understanding of Javascript, CSS, HTTP, HTTPS and other components of the foundation.

But you don't want to start a n00b with a man page.

Do you think that that concern is as outmoded as forcing people to have a good sense of x86 opcodes, and assembler, to have a sense of what the CPU is actually doing?

No, because C compilers are no longer as buggy as they used to be.

The thing is when you are still going to be debugging in a different language, haml -> html, coffee -> js.

As a CoffeeScript guy I think one of its main strengths is its harder to shoot yourself in the foot with is great for beginners but you have to be careful a beginner doesn't just bind all the way down using =>

Actually it IS valuable to have some understanding of assembler, even when you are using JavaScript on a daily basis. Maybe it's not that important for a beginner programmer now, since source maps are available, but I would encourage everyone to go as low-level as possible. Some JS and CS constructs have an awful representation underneath. Think of eval, dynamic types or hashtable-like objects.

Totally agree. The reason is this: one will at some point have to debug and wade through all the generated JS and CSS code, and unless already familiar with HTML, JS and CSS, this is going to be difficult.

Or you could just use a source map. (In the not-too-distant future, anyway. We are talking about the future, right?)

I agree on the haml front. Whilst long-term web developers will appreciate the haiku-like syntax, ERB is significantly easier to parse since it's HTML plus code. To use HAML effectively you ultimately need to learn to "read" a new language.

I strongly recommend any devs, including the Padrino crew, to keep examples/guides in ERB. It's much more friendly for newcomers to the framework. Having to learn to read HAML at the same time is a PITA.

Reply on news.ycombinator.com