11

The time needed to download a website would be significantly reduced, and parsing would be also easier I think.

Why are not these languages imposed as a standard? Obviously they are better than raw html and CSS...

Browsers are the only thing that keeps us away from eliminating the intermediate HTML/CSS code.

|improve this question
  • 2
    There's a lot of reasons, but backward compatibility is a big one. – sevenseacat Jun 10 '12 at 10:02
  • they could detect html based on the doctype and haml based on another keyword.. – Alexa Jun 10 '12 at 10:23
  • 1
    joelonsoftware.com/items/2008/03/17.html – Job Jun 10 '12 at 16:06
  • I am not familiar with Haml, but with other template engines in general, you would still need to parse the template on the server in order to insert data into the rendered HTML. Granted, it is becoming easier for browsers to do this, but I imagine that's not something that will go away any time soon. – Jeremy Heiler Jun 10 '12 at 17:45
  • I thinks SCSS should be baked into browsers. Perhaps they are waiting for a clear winner to emerge between Less and SCSS... – MSC Aug 25 '18 at 9:34
15

Another thing to consider is that standards organizations have limited bandwith--they can only work on so much at a time.

Given these constraints, I would rather they work on solving problems the web developers cannot solve themselves (like adding new tags or CSS animations). SASS and haml are trivial to compile down to CSS/HTML, so the advantage of native browser support would be limited, since it's so easy to do yourself.

|improve this answer
9

The strongest point going for the preprocessor languages such as Sass or CoffeeScript is the fact they compile to their "standard" counterparts. That's what is compelling about them - you get all the benefits of their "obviously better" design without adding to the myriad of compatibility issues web developers already have to deal with when working with standard CSS or JS. Backwards compatibility is a big thing when it comes to web development, anyone who still has to mind IE6 at his job will aggree.

Html/CSS/JavaScript package has rough edges and things that may feel inadequate today, but it does provide a bare minimum - but a bare minimum that's widely accepted, understood and implemented - that we can build upon. Haml/Sass/CoffeeScript do precisely that and that's what makes them useful. I'd rather keep my Sass server-side than deal with browser developers engaging in a Sass-Less-Stylus standards war that would serve no one ;)

|improve this answer
5

"Technically better" and "easier to use" are just two out of many criteria for making something a standard. There are lots of others, such as:

  • Compatibility with existing standards
  • Existing implementations (informal de-facto standards)
  • Effort required to implement
  • Existing user base (and hence, community support, available skilled manpower)
  • Existing toolchains
  • Platform support
  • Integration with related standards

You will have to agree that HTML and CSS have an overwhelming advantage against any newcomer on these criteria.

|improve this answer
4

sass and haml are not standards. HTML and CSS are.

If and once both become standards (and are widely accepted and used), then there will be a compelling reason for browser makers to add support for them.

|improve this answer
  • 1
    What does make something a standard? The number of people that use that thing. If browsers add support for haml and sass the # of users will increase, and eventually the standard will be made official on w3c.. – Alexa Jun 10 '12 at 11:18
  • 1
    @Alexa - Or an official standards body (or industry consortium) make a standard. – Oded Jun 10 '12 at 11:25
  • 2
    @Alexa: No, if it worked that way then the <blink> tag would have been made official. – user16764 Jun 10 '12 at 12:55
  • 1
    @user16764, but I think Alexa is right. HTML5 is just a compilation of stuff browsers were already doing. They just put it in nice words. – Arturo Torres Sánchez Apr 3 '15 at 3:48
3

No production project can use Haml until it is supported by Firefox, Chrome, Safari and Internet Explorer. It used to be that "enterprise" applications could be IE only, but I think the days of that are over. Standards aren't imposed from on-high, they are agreed to by browser vendors.

So really to have Haml made a standard, you'd need to get Apple, Google, the Mozilla Foundation and Microsoft to agree. This isn't trivial. These companies are going to generally concentrate on expanding capabilities rather than cleaning up existing features.

Haml looks nice to work with, but it won't actually improve download sides as all modern browsers and servers support compression. Compressed Haml and Html are likely to be about the same size. (Plus, most of the download time for the average website is in downloading images and script code.)

Now keep in mind that few people write in Html anymore. People use frameworks that spit out Html as an end product. Not only would this hurt the adoption of Haml directly, as none of these frameworks will support it, but it obviates the need for it, because the underlying markup language is only seen by the computer.

From the browser vendor point of view, they can improve an existing feature slightly (by supporting something like Haml, which gives cleaner pages) or they can add something entirely new, like WebGL. The latter just has more bang for the buck.

|improve this answer
2

Yes, they do look cooler and easier to use than html and CSS. But html and CSS are existed and built for a long time, many many applications both on web or desktop use them.

Therefore, it's not easy to make something standard. HAML and SASS are really fun and cleaner to use but being standard, it will take a long time or never. Since, w3c does care about developers, so they indeed make html and css better in html5 and css3.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.