March 07, 2012 Re: D to Javascript converter (a hacked up dmd) | ||||
---|---|---|---|---|
| ||||
Posted in reply to James Miller | On Wednesday, 7 March 2012 at 03:46:45 UTC, James Miller wrote: > However, I would like jQuery's CSS selector engine as a standalone library, sooo much easier than complex DOM lookups CSS selector is built into all the browsers since IE8/FF3.5. The functions are element.querySelector and element.querySelectorAll. http://msdn.microsoft.com/en-us/library/cc304119%28v=VS.85%29.aspx https://developer.mozilla.org/En/DOM/Document.querySelector If you need to support older browsers, I think jquery's engine is called Sizzle stand alone, but I just let it throw the method not found exception, and carry on without the javascript. It's not worth the size. |
March 07, 2012 Re: D to Javascript converter (a hacked up dmd) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On 7 March 2012 16:51, Adam D. Ruppe <destructionator@gmail.com> wrote:
> On Wednesday, 7 March 2012 at 03:46:45 UTC, James Miller wrote:
>>
>> However, I would like jQuery's CSS selector engine as a standalone library, sooo much easier than complex DOM lookups
>
>
> CSS selector is built into all the browsers since IE8/FF3.5. The functions are element.querySelector and element.querySelectorAll.
>
> http://msdn.microsoft.com/en-us/library/cc304119%28v=VS.85%29.aspx https://developer.mozilla.org/En/DOM/Document.querySelector
>
>
> If you need to support older browsers, I think jquery's engine is called Sizzle stand alone, but I just let it throw the method not found exception, and carry on without the javascript. It's not worth the size.
Oh right, I didn't know that, IE8 and FF3.5 are old enough that you can use it without too much worry, older browsers can just have some graceful fallback.
--
James Miller
|
March 08, 2012 Re: D to Javascript converter (a hacked up dmd) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert Clipsham | Am 01.03.2012, 17:29 Uhr, schrieb Robert Clipsham <robert@octarineparrot.com>:
> Interesting idea:
>
> version(JavaScript) asm
> {
> /* Well... it's not really asm, but it's
> as close as you could get with a javascript backend :p */
> document.write("Oh look, inline javascript D-:");
> }
>
> Perhaps it would be better to have a dedicated function for that though.
How about:
pragma(js)
{
document.write("Oh look, inline javascript D-:");
}
|
March 18, 2012 Re: D to Javascript converter (a hacked up dmd) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | This is still alive: https://github.com/adamdruppe/dmd/tree/dtojs Merging in DMD changes as they happen has been fairly easy, so we have things like UFCS in there. I'm pretty happy with the core setup, though it still isn't finished. Enough of the D language works like you expect that you can do a lot of things with it naturally. Thus, I've moved on to libraries. I previously talked about the jslang and browser packages. These provide zero-overhead, direct access to javascript built-ins. You can also use a good chunk of the real Phobos in here if you want. But now, I'm adding minimal overhead nicer libraries, including a port of my dom.d, adopted to try to cover some browser incompatibilities. (The browser package, being zero overhead, makes no attempt at this. It just provides the tools to DIY.) The trick is though, doing it with as lean code as possible. Here's my domtest.d: import arsd.dom; import browser.window; void main() { Element e = document.getElementById("cool"); e.addClass("sweet"); e.style = "font-weight: bold;"; e.style.fontSize = "30px"; e.innerText = e.style; window.alert(e.parentNode.tagName); e.removeFromTree(); } It generates about 2 kb of javascript, libraries included, after you strip unused functions and reduce the variable name length. (NOT gzipped!) Let's talk about one line at a time: Element e = document.getElementById("cool"); In browser.document, there are JSElement and JSDocument classes defined. Here, though, I'm using a custom type: Element. The implementation for this uses zero overhead forwarding to native methods, unless I override them, in which case it is implemented as a free function. Many functions are now mixin templates in browser.document so I don't have to repeat them, even if changing types. Using alias this, these are compatible with the native types as well. e.addClass("sweet"); Is a new function in class Element. It manipulates the native className property and in the resulting .js file is a free function. e.style = "font-weight: bold;"; The style object is defined in browser.document and has a long list of properties. It maps directly to native code, but with one addition: alias cssText this; style.cssText in Javascript is the attribute as a string. In my dom.d, Element.style can be treated as a string or a struct, and I wanted that here too. alias this accomplishes that goal with zero overhead. e.style = ""; translates simply to e.style.cssText = ""; e.style.fontSize = "30px"; The property is a native one, nothing special here. e.innerText = e.style; innerText, while a property on some browsers, isn't present on all of them. Thus, class Element defines it itself. This generates a free function (with a mangled D name, so no conflict) that is called using D property syntax. The generated code looks like this: _D_mangled_innerText(e.style.cssText, e); This is the general pattern I'll do for browser compatibility. Use the real name in D, but let it implement as free functions with mangled names. window.alert(e.parentNode.tagName); The browser.window module defines some things that are global in JS, including alert(). e.parentNode returns an Element, thanks to a mixin that can specialize on types with zero overhead. tagName, while a native property, is actually a function here. The reason is dom.d uses lowercase tag names, but Javascript uses uppercase. Thus, this is implemented: @property string tagName() { return __js_this.tagName.toLowerCase(); } and the above line calls a D function. Some overhead, but very little. e.removeFromTree(); Finally, this is just a regular function. I'm thinking about changing it to UFCS though so it can check for null on e too. (It does: if(parentNode) parentNode.removeChild(this); the idea being to just ensure it isn't in the tree without needing an external null check. If this is null, it is also not in the tree, so its contract is satisified anyway, so it might as well succeed. Currently, though, it will not work since the Element invariant will segfault it.) But, there's a rundown of what I'm doing with libraries. Beautiful D code, compatible implementations, minimal overhead. I'll be posting the library soon, and then this will be sharable. |
April 19, 2018 Re: D to Javascript converter (a hacked up dmd) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | Did this thing ever get to a release/usable point? |
April 19, 2018 Re: D to Javascript converter (a hacked up dmd) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan I Levi | On Thursday, 19 April 2018 at 16:20:22 UTC, Jonathan I Levi wrote:
> Did this thing ever get to a release/usable point?
Not really. I didn't find it worth the trouble after using it in a few experimental projects and basically let it go like six years ago.
The compiler has significantly changed since then, so it'd have to be rewritten. You might use the ldc fork with emscripten instead (of you don't mind code bloat. that is something that bothers me...)
|
Copyright © 1999-2021 by the D Language Foundation