I was kind of surprised by this. Has Microsoft done this before (contributed to an Open Source project not of their own making) or is this new for them?
IIRC they've contributed a few bits and pieces to Apache and the Linux kernel (drivers), though I think they've just been for interop with other MSFT stuff.
My fear is that it would be an opportunity for an old trick of theirs: embrace and extend. If so, we'd be in the 'embrace' phase.
I'm hoping not. They've been getting more open-sourcey in the last couple years. One alternative is that they just saw a great model and have no need to reinvent the wheel. It means an easier .net onramp for developers who already know jQuery.
That certainly comes to mind. The question is, how could they take jQuery in an incompatible direction, tying developers into their version, thus gaining control over the project? I can't really see a way it could happen here. Pulling a classic 'embrace and extend' would mean rather than contributing to the original product, they'd make their own subtly incompatible version.
This is interesting. Just the other day I saw a flash ad on Reddit touting all the new features in Visual Studio 2010. I was surprised to see that one of the slides mentioned "Support for including the jQuery Framework".
Glad to see that riding the jQuery train rather than making their own or something along those lines.
Irregardless of MS's support of Moonlight, I question the entire effort. Wouldn't those talented programmer be put to better use on something with a higher chance of actually being used?
I actually really dig mono and in my mind those resources would serve the community better focused on Mono, MonoDevelop, MonoTouch and MonoDroid.
I just don't see wide-scale adoption of Silverlight/Moonlight whether it's available on *nix or not, with or with MS's blessing.
There was a goal (a while back) of getting Moonlight embedded in Firefox (on all platforms). The goal hasn't come true but think about that. A general purpose VM embedded right in the browser!
I have no doubt that Moonlight would be used if it was embedded within the browser. CIL is an open-specification, we already have many compilers that target it. We could run C#, Scala, Java, Python, Ruby, Haskell, etc on the client side.
But all we're stuck with is a JavaScript VM to use.
I think the fact that this thread has only the two of us interested sums of the interest in Silverlight/Moonlight in the hacker community. ;)
I guess I wonder why I would want to write C#, Scala, etc on the clientside? Javascript is an already established cross-browser standard that I'd say any good developer is already familiar with; certainly jQuery strengthens the case for JS and also is bringing more people into the fold.
And with Node.js - which clearly has a lot of interest in the HN community (node.js stories always get upvoted as well they should) - it seems that things are moving in the opposite direction from what moonlight/ms is trying to accomplish with this particular tech.
For all those reasons it just seems like a fools errand to me.
We opted not to use this particular technique for two reasons: 1) It's not nearly as versatile. You can use the if statements on elements, attributes, text - anything you wish - there is no restriction on its contents or location. 2) In order to actually use something like that we'd have to serialize the DOM tree first, traverse it, and then manipulate the nodes into the proper shape. This is slow slow slow and absolutely must be avoided at any cost.
A little off topic but I expect this to go well with jQuery Mobile. Can we expect any updates there? Been a bit disappointed by the relative quiet since the announcement (not that you owe me anything). Also, is there any publicly available code to check out? Thanks!
Only quiet because we're working so hard. We're releasing the alpha on October 16th (at the jQuery conference in Boston) so we're a bit frantic at the moment. Either way we're hoping to get a blog post up this week.
I see reason 1. as a downside — it allows very messy Smarty-like markup that can generate ill-formed HTML.
2. I think there's little difference whether you serialize first or later. Are all those new fancy DOM traversal, XPath and XSLT APIs really not faster than parsing and joining of strings?
"Are all those new fancy DOM traversal, XPath and XSLT APIs really not faster than parsing and joining of strings?"
It cannot be understated how much slower touching the DOM is compared to doing string manipulation. Any DOM touching - but generating DOM nodes and traversing them is radically slow. If you want to support Internet Explorer it's not even an option, as far as performance goes.
Underscore.js (http://documentcloud.github.com/underscore/) provides great Templating support and the ability to customize your templates through the use of _.templateSettings. This would allow you to use <% %>, [% %], or pretty much any symbol combination you prefer.
He also recommends the official jQuery templating plugin. As is the case with most templating plugins there are minor syntax differences - although it does appear as the two plugins tackle the underlying problem in very similar manners (leading to fast execution time). I've pinged Yehuda so that he can comment here, as well.
Data binding! Finally. That is one of my favorite features of the Flex framework. I remember reading about Microsoft working on this with jQuery, but never knew when to expect it. Great news.
The Globalization sounds like a good idea. However the template library scares me. There are so many different template use cases in JS that having one ordained jquery one seems like it might have to be too many things to too many people.
JavaScript templating may sound scary, but if done properly they can be so ridiculously powerful that at this point I think it's inevitable that server-side generation of HTML will eventually be obsolete.
Imagine being able to throw away all the hideous and incompatible JSP, eRuby, PHP (smarty etc), and Django templates with a universal template language.
With respect, I think it's naive to think that the lastest templating language will be the "universal" one. No, this is just one more JS templating language.
Technically there's nothing preventing universal server-side templating language (e.g. XSLT & TAL are available for all languages you've mentioned). It's just a matter of everyone agreeing on syntax — and that's the hard part.
You can't just agree on syntax, IMHO the reason for that is the best template languages have the full language available. You need a full-language for a great template language. Smarty, for instance, sucks. HAML, which is terse, but has access to the full syntax of ruby rocks. You can do things like:
Sure there's some special operator is smarty to do this, but I don't want to have to learn it, and they're always more clunky.
Additionally, I always hit complex, weird situations where I need a full-language, and migrating that logic out of the view makes no sense. For instance, I was working on a site where I had repeating content, with ads at predetermined offsets. I rendered it something like:
ads_positions = Set.new(2,8,10,12)
content.each_with_index do |content,i|
if ad_positions.include?(i)
content
ad
else
content
end
end
I hate expressing that stuff server-side or in half-baked templating languages.
Though we've got nigh-universal bidirectional communication: JSON. That makes JS templating systems server-agnostic, where server-side templates need the server to run more software to render your templates.
Javascript templating isn't really scary. I've used two different engines in the last few months. That's not my concern. More it's that the syntax needed for a small template is going to be very different from a full js application. And both of those are going to be different from a server side node.js template.
Having options is a good thing, and I worry that jQuery with it's dominate position could become the defacto standard even if it is not the best choice for all projects.
I didn't single Django out, I think all server-side template languages are hideos and largely unnecessary. JavaScript templates, with some work, can be better in a lot of ways.
Well I can understand why you think some templating languages are hideous, because they definitely are. Many are overly verbose.
I've definitely enjoyed a few though, Django's being one of them.
I think Javascript templating is great, and it's certainly helpful in many ways, but it could never flat-out replace server-side template engines for me. In Django for example, you almost always pass whole ORM objects to the template. On someone's page of a list of friends, I'd loop through a collection of User objects and generate an html list of usernames and permalinks to their profile pages. If I passed the whole collection of User objects to the client they'd get access to a lot of sensitive information. Which would require me to white-list at the ORM level exactly what fields I might need ahead of time. That might work, but I'd always be worried that I didn't clean the objects sent to the client's JS template enough for every page I'm writing.
Unless of course you were going for the idea that we'll be using one universal templating language both for the front-end JS as well as on the back-end in something like node. In which case disregard everything I just wrote.
It won't degrade gracefully for those who turn off javascript or don't have it. Putting more and more things into javascript may be in vogue but it doesn't seem any better than the solutions we already have.
Yes, if you load in all your content through AJAX/AJAH or some other form of client side process, google won't get that content when crawling your page. The best way to see what search engines will see is to load the page in a browser and then use "View Source".
There are ways to help search engines find your dynamic content, however, which typically involve creating static versions of the content in addition to your more user-friendly AJAX versions. Google outlines some methods for doing this using specially formatted hash tags here: http://code.google.com/web/ajaxcrawling/index.html
If this gets popular enough, maybe we should standardize a new <link> element to point to the JSON data file that search engines should index. Maybe even a standard schema for it!
Interesting technique... I wonder how long until someone sets up a Haml clone in a similar vein, however. Less[1] is already moving in that direction, the next step is to do HTML in a similarly-friendly way. I'd use that; this is a pretty hideous, clearly-MS-influenced Enterprisey implementation.
I... I have nothing bad to say about that.
Hmmm.