March 07, 2012
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
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
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
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
Did this thing ever get to a release/usable point?
April 19, 2018
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...)
2 3 4 5 6 7 8 9 10 11 12
Next ›   Last »