search

dnagir / ruby-haml-js

HAML-JS Tile and Rails 3.1 Template
MIT License
86 stars 13 forks source link

Windows JS runtime compatibility #4

Closed inossidabile closed 12 years ago

inossidabile commented 12 years ago

Current version of ruby-haml-js was not available to run at Windows/JScript environment due to lack of some core functionality.

We've attached the patched version of HAML.js lib by @wintondeshong which uses underscore lib to fulfill the gap. Therefore underscore was added to Gem (and correspondingly to template.rb).

The history of HAML.js fixes can be traced from this commit: https://github.com/wintondeshong/haml-js/commit/d507750986e10cec8387afab40a193c72467fbe2.

dnagir commented 12 years ago

I would definitely avoid using a patched and forked version of the hamljs as maintaining and merging it with the main (creationix) will be a pain.

I will accept this patch if it will be accepted by @creationix as well in the main repo.

As an alternative, I can see the following solutions for now:

  1. Use nodejs instead of JScript.
  2. Include Sugarjs that adds native methods, so that there is no need to modify the hamljs itself.
  3. Apply fixes for native objects as recommended by Mozilla. For example, forEach.

I would definitely prefer option 1 though, especially since Node.Js officially supports Windows.

Do you have any problems with the nodejs solution?

inossidabile commented 12 years ago

I agree, problems with forked version are quite possible.

But I can't agree with Node.JS solution. It adds dependence which gem can not handle internally. I trust that while we have way to avoid such dependence, we should do it. A lot of potential users of such library may not even know what's behind your gem. Like tilt, execjs or even JS runtime. I can't agree we should make their lives worse.

On the other side manually applying fixes to native objects (3rd variant) sounds like an overkill. I'll find out if Sugarjs mixing is enough to make basic implementation work with JS.

dnagir commented 12 years ago

I really don't think that nodejs is such a big issue. You just need to have it installed, no other config should be necessary as execjs will handle that.

I am a bit reluctant to try to support what hamljs itself doesn't and would rather see if more people have this problem.

It all boils down to what hamljs itself supports. Instead of adding something on top of hamljs, I think it is better to contribute to it and then update this gem accordingly.

inossidabile commented 12 years ago

That's why I did not change anything myself but rather used what's already on pull request. @creationix seems dead though. Your choice makes support easier but it clearly breaks encapsulation (in my opinion). But if you would like to go with node.js – np, we'll just use my version internally since gem itself is quite small and I will be able to support this hack.

Thank's a lot for a useful gem :)

dnagir commented 12 years ago

Yeah, I would prefer to keep it as close to the original implementation as possible. Will diverge when more people will need some customisations.

I still think it's much simpler to just install nodejs instead of maintaining a separate fork. You will need it anyway to compile CoffeeScript in your Rails apps.

inossidabile commented 12 years ago

-- You will need it anyway to compile CoffeeScript in your Rails apps.

For sure I won't. JScript (as default Windows bundle) is completely enough for coffee. In fact everything you expect to work in Rails just works. That's why you can not add node.js as dependency to Rails only because it's so easy for you to install it. It's nonsense.

dnagir commented 12 years ago

Well, it wasn't nonsense for the author of hamljs for some reason. In any case, I don't want to modify the content of the hamljs itself. Don't forget that you can also use it on the client side.

But as I said there are two other options to go with. If you'll try those and they will work, then we could merge it in, but only for Windows platform. I would also tripple check that additional JS files would not be be served as the rails assets. On Nov 28, 2011 6:40 PM, "Boris Staal" < reply@reply.github.com> wrote:

-- You will need it anyway to compile CoffeeScript in your Rails apps.

For sure I won't. JScript (as default Windows bundle) is completely enough for coffee. In fact everything you expect to work in Rails just works. That's why you can not add node.js as dependency to Rails only because it's so easy for you to install it. It's nonsense.

Reply to this email directly or view it on GitHub: https://github.com/dnagir/ruby-haml-js/pull/4#issuecomment-2893907

creationix commented 12 years ago

"@creationix seems dead though", not quite, just very busy. ;)

You should be aware that I'm not the maintainer of haml-js anymore, @aaronblohowiak is. As far as my opinion, I don't think adding underscore as a dependency is the right thing to do for haml-js. It needs to stay lightweight and framework agnostic. It can probably be made to work with jscript without adding a new framework. (I personally haven't looked at the code in some years, so I probably won't be much help on specifics)