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.
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?
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.
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.
This post is heavily opinionated and is hardly a beginners guide. I've never heard of Padrino to this day and I consider myself quite up-to-date developer.
Beginners should learn languages (preferably with standards in mind) first and then move to pseudo-languages/preprocessors like haml, coffeescript and less.
And it all depends on what you are writing, not all languages/frameworks/tools suit every purpose.
And Bootstrap is not a javascript library. It's a CSS framework (which includes some jQuery plugins).
It's crazy to see the way the "modern web dev stack" has progressed over the years. I'm not so confident of whether this is really one that will last in the way LAMPP ever did, but I'm interested in seeing Padrino in particular. These days, the stack relies so much on personal opinions I can't wait to see where we go in the future.
The only reason I dislike padrino is due to it's code quality - it's riddled with personal preferences of whomever was coding at the time. I also submitted an 'issue' but it was simply closed.
Padrino creates a rails like structure around sinatra. It provides convenience scripts, helper methods and some glue code to create rails style apps. If you like sinatra but want more structure around it you should definitely checkout Padrino.
I was considering Rails for a project but considered it overkill for my needs (small RESTful web service). I discovered Sinatra and fell in love. Then I discovered I could get the benefits of Sinatra, with a bit of Rail-like "magic" (helpers, ORM support, generators, migrations) by using Padrino. For me it's a perfect fit.
I'm just getting into web dev, and the amount of choices is rather overwhelming. I know the basics of html, css, javascript, and ruby. I'm trying to decide where I should start devoting my time though if I'd like to move into freelancing, but it's hard to decide which way to go with rails, sinatra, padrino, node, express, tower, ember, and so on.
I can see the value in less or sass, but I'd like to see more details on why you recommend one over the other. Same goes for most of the choices.
My take on pre-processors like LESS, SASS etc. is this: To truly appreciate and benefit from them, you should first start facing problems in scaling and managing plain CSS. I would argue that the same goes for CoffeScript. For simple apps, preprocessors offer negligible value addition.
If there's a good enough workflow, there's no reason to not use LESS and SASS in each app. You compile the CSS before production anyway, which means you work with beautiful code, and use automatically minified code for production, and all of it is (usually) taken care of in the background.
Plus, if I work in CSS for simple apps and LESS for complex apps, I have to keep two sets of boilerplates. I don't want to be writing CSS from scratch every time I make an app. With using LESS in every instance, not only do I only need one boilerplate, but that boilerplate is modular and I can take the things I need and exclude the things I don't. LESS effectively has namespaces to make this super easy and MORE efficient than plain CSS.
No comment on CoffeeScript, though. I've not had to write enough JS to warrant checking it out in depth.
