On Wednesday, 30 April 2014 at 02:43:43 UTC, Rikki Cattermole wrote:
> On Tuesday, 29 April 2014 at 14:41:19 UTC, James wrote:
>> I have a friend that is a web developer. I, however want to collaborate with him, so I am trying to get him to learn D. I  don't know how to persuade him! How can D be used to greatly assist an HTML5/JavaScript web developer? I decided to go here to get some good answers. How can D be used to interopt with modern web development?
>
> If you want to show him what's possible with D, just show him Cmsed[0] ;)
> All I'm saying is, if you ever not want to write ajax code again, Cmsed is your friend [1].
>
> [0] https://github.com/rikkimax/Cmsed
> [1] https://gist.github.com/rikkimax/11043210

Having a quick look at Cmsed I must admit I like plain vibe.d much more despite the added features :( Forced module coupling and OO-heavy design is big loss compared to design simplicity and independence of base vibe.d modules.

For example I can't imagine a single case when I'd prefer class-based route definition to stock delegate-based.

On Wednesday, 30 April 2014 at 03:20:16 UTC, Rikki Cattermole wrote:
> We should probably work together on this sort of stuff! As we seem to have similar ideas

Yea, I wrote my version several years ago (IIRC 2009 or early 2010) and since then D has grown as has my knowledge of it. I kinda want to write a web.d 2.0 that cleans everything up but eh I have a lot of things I want to do and web.d 1.0 works so no big rush.

The 1.0 has a lot of cool stuff though, like it can avoid JS calls by referencing the result of another function in the URL, all pretty transparently. So like if you wrote, in JS:

Foo.add(Foo.add(1,2), 3).get(alert), it should only result in one HTTP request. The proxy object when used as an argument just emits an indirect reference through magic URL params. Kinda cool, though it doesn't go as far as I'd like.


Among what I'd like to clean in web.d 2.0:

web.d supports what it calls "ApiObjects", which map to RESTful uris:

class Poo : ApiObject {
   this(ApiProvider parent, string identifier) {}
   auto GET() { }
   auto POST() {} // etc
   auto bar() {}
}

If you went to:

/Poo/cool-beans

it would call (new Poo(parent, "cool-beans")).GET(). Then /Poo/a/bar calls new Poo("a").bar and so on.

The problem is this is really reliant on things like the ending slash, and it issues redirects to force it to be there or not be there.

The implementation is also kinda buggy in general, it is supposed to beautifully nest, but it only kinda does. Getting an index of all things also doesn't work quite right, you have to write a separate method for that.

So I'd like to clean all that up and actually design it instead of growing on cool hacks as they come to mind.

Nested ApiProviders don't work exactly right either. They are supposed to do a chain of magic:

class Foo : ApiProvider { auto whatever() {} }
class Bar : ApiProvider {
   alias Foo foo;
}

Then, /foo/whatever does (new Foo((new Bar))).whatever. That part works. The things is each class can also provide a postProcess method to modify the document after it is generated. That's *supposed* hit everything, but sometimes it doesn't, I think it only works two levels deep right now, really hairy implementation.

The other problem is the Javascript generator doesn't really understand nesting. Ideally, nested ApiProviders are made available through dots and nested ApiObjects are workable through JS proxy objects.

This looks like what you managed to do so that's cool.


I also need to clean up the reflection generation to make it easier to use and make path info accessible outside just the automatic routing (or the low level Cgi.pathInfo which doesn't tell you where it starts!).

Reflection should be generated once upon startup then reused forever as an immutable object. Currently, reflection is partially regenerated on each request - eek.


I also wrote a _register*Processor family fairly recently (like December 2012) that kinda obviates the old postProcess and back in January this year, changed the session to put it all in cookies instead of files. That stuff is awesome, so much better than the old way. Should consider doing them from the ground up now!

(Also, ironically, I was a big pusher for UDAs for web.d... but I barely actually used them after they were made available. I really wanted to put them on parameters tho, otherwise convention over configuration is kinda how i play it LOLOL)



oh yeah and it could be documented somewhere other than my brain, the sloppy source, and random forum posts so ppl can know about it all. but meh.

All that said, it manages to get the job done for me so I'm not in a huge rush to actually fix any of it.

On Tue, 2014-04-29 at 22:09 +0000, Adam D. Ruppe via Digitalmars-d
wrote:
[…]
> I can just get stuff done in D in a fraction of a time it takes to do even less in RoR.

This is the stuff marketing campaigns are made from. As well as informing the cabal that is this mailing list, there needs to be tweets, Facebook, G+, and proper publishing articles of people switching from RoR, Grails, Django to web.d and vibe.d and discovering (measured and guaranteed) significant performance benefits in both time to market and run time.

Go has gained much of it's traction from provably and consistently producing simpler, faster and more reliable systems that C, C++, Python, etc. and getting articles about the success out there. HN is all very well but it is really another inward looking cabal. Articles about rewrites of systems written in sober yet humorous tones presenting real benefits will over a period of a couple of year generate a groundswell of support.

D may be a lot older than Go, but there is a lot to be learned from the way non-Google folk created the "buzz" for Go by doing and publishing data about, as well as chatting on the mailing list. It also helped that a faction in Canonical switched from Python to Go and got on and did things that contributed positively to Ubuntu. Whatever your feelings towards Canonical and Ubuntu, their use of Go has contributed strongly to the progress and acceptance of the language.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 30 April 2014 at 04:10:14 UTC, Dicebot wrote:
> On Wednesday, 30 April 2014 at 02:43:43 UTC, Rikki Cattermole wrote:
>> On Tuesday, 29 April 2014 at 14:41:19 UTC, James wrote:
>>> I have a friend that is a web developer. I, however want to collaborate with him, so I am trying to get him to learn D. I
>>>  don't know how to persuade him! How can D be used to greatly assist an HTML5/JavaScript web developer? I decided to go here to get some good answers. How can D be used to interopt with modern web development?
>>
>> If you want to show him what's possible with D, just show him Cmsed[0] ;)
>> All I'm saying is, if you ever not want to write ajax code again, Cmsed is your friend [1].
>>
>> [0] https://github.com/rikkimax/Cmsed
>> [1] https://gist.github.com/rikkimax/11043210
>
> Having a quick look at Cmsed I must admit I like plain vibe.d much more despite the added features :( Forced module coupling and OO-heavy design is big loss compared to design simplicity and independence of base vibe.d modules.
>
> For example I can't imagine a single case when I'd prefer class-based route definition to stock delegate-based.

The classes are unfortunately just a container for routes. So if you got a better way, that can provide the same functionality, I'd love for a plan on how to do it!

Basically my idea is that you register as little as possible. That was why I went with a class for routes.

I'm really gunning for less, simpler = more. And for medium-large sites thats kinda important.

It may be a good time to repeat, we need a marketing manager for D!
Somebody really really needs to focus on getting us out there.

On Wednesday, 30 April 2014 at 04:12:59 UTC, Adam D. Ruppe wrote:
> On Wednesday, 30 April 2014 at 03:20:16 UTC, Rikki Cattermole wrote:
>> We should probably work together on this sort of stuff! As we seem to have similar ideas
>
> Yea, I wrote my version several years ago (IIRC 2009 or early 2010) and since then D has grown as has my knowledge of it. I kinda want to write a web.d 2.0 that cleans everything up but eh I have a lot of things I want to do and web.d 1.0 works so no big rush.
>
> The 1.0 has a lot of cool stuff though, like it can avoid JS calls by referencing the result of another function in the URL, all pretty transparently. So like if you wrote, in JS:
>
> Foo.add(Foo.add(1,2), 3).get(alert), it should only result in one HTTP request. The proxy object when used as an argument just emits an indirect reference through magic URL params. Kinda cool, though it doesn't go as far as I'd like.
>
>
> Among what I'd like to clean in web.d 2.0:
>
> web.d supports what it calls "ApiObjects", which map to RESTful uris:
>
> class Poo : ApiObject {
>    this(ApiProvider parent, string identifier) {}
>    auto GET() { }
>    auto POST() {} // etc
>    auto bar() {}
> }
>
> If you went to:
>
> /Poo/cool-beans
>
> it would call (new Poo(parent, "cool-beans")).GET(). Then /Poo/a/bar calls new Poo("a").bar and so on.
>
> The problem is this is really reliant on things like the ending slash, and it issues redirects to force it to be there or not be there.
>
> The implementation is also kinda buggy in general, it is supposed to beautifully nest, but it only kinda does. Getting an index of all things also doesn't work quite right, you have to write a separate method for that.
>
> So I'd like to clean all that up and actually design it instead of growing on cool hacks as they come to mind.
>
> Nested ApiProviders don't work exactly right either. They are supposed to do a chain of magic:
>
> class Foo : ApiProvider { auto whatever() {} }
> class Bar : ApiProvider {
>    alias Foo foo;
> }
>
> Then, /foo/whatever does (new Foo((new Bar))).whatever. That part works. The things is each class can also provide a postProcess method to modify the document after it is generated. That's *supposed* hit everything, but sometimes it doesn't, I think it only works two levels deep right now, really hairy implementation.
>
> The other problem is the Javascript generator doesn't really understand nesting. Ideally, nested ApiProviders are made available through dots and nested ApiObjects are workable through JS proxy objects.
>
> This looks like what you managed to do so that's cool.
>
>
> I also need to clean up the reflection generation to make it easier to use and make path info accessible outside just the automatic routing (or the low level Cgi.pathInfo which doesn't tell you where it starts!).
>
> Reflection should be generated once upon startup then reused forever as an immutable object. Currently, reflection is partially regenerated on each request - eek.
>
>
> I also wrote a _register*Processor family fairly recently (like December 2012) that kinda obviates the old postProcess and back in January this year, changed the session to put it all in cookies instead of files. That stuff is awesome, so much better than the old way. Should consider doing them from the ground up now!
>
> (Also, ironically, I was a big pusher for UDAs for web.d... but I barely actually used them after they were made available. I really wanted to put them on parameters tho, otherwise convention over configuration is kinda how i play it LOLOL)
>
>
>
> oh yeah and it could be documented somewhere other than my brain, the sloppy source, and random forum posts so ppl can know about it all. but meh.
>
> All that said, it manages to get the job done for me so I'm not in a huge rush to actually fix any of it.

It does look like web.d was a bit of a precursor to Cmsed (unintentionally) strangely enough.
Although I definitely would like to hear more about asynchronous javascript instead of my synchronous based code and how I can combine it at some point.

On Wed, 2014-04-30 at 04:12 +0000, Adam D. Ruppe via Digitalmars-d
wrote:
[…]
> Yea, I wrote my version several years ago (IIRC 2009 or early 2010) and since then D has grown as has my knowledge of it. I kinda want to write a web.d 2.0 that cleans everything up but eh I have a lot of things I want to do and web.d 1.0 works so no big rush.

I disagree. The lesson from the Bottle/Flask/Tornado experience over the last few years is that it is always better to be working on the next version rather than just stick to maintaining the current version.

Yes for using 1.0 on the current jobs, but definitely yes to starting on 2.0 now, especially if there are other to join in and help with the work.

Web is not my area per se and I don't have a web-related project I can pin helping out with this effort on, but I would encourage you to work on 2.0.

I will have to be looking at Python's asyncio which is Python's "play" in the arena that Twisted used to be king; more vibe.d than web.d.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via Digitalmars-d wrote:
> On Tue, 2014-04-29 at 22:09 +0000, Adam D. Ruppe via Digitalmars-d
> wrote:
> […]
>> I can just get stuff done in D in a fraction of a time it takes to do even less in RoR.
>
> This is the stuff marketing campaigns are made from. As well as
> informing the cabal that is this mailing list, there needs to be tweets,
> Facebook, G+, and proper publishing articles of people switching from
> RoR, Grails, Django to web.d and vibe.d and discovering (measured and
> guaranteed) significant performance benefits in both time to market and
> run time.

I have a friend who has switched to vibe.d after being Erlang Cowboy devoted user for years. Trying to convince him to write an article about it but no luck so far :( Reason to switch in two words : "static typing".

On Wednesday, 30 April 2014 at 04:32:37 UTC, Russel Winder via Digitalmars-d wrote:
> On Wed, 2014-04-30 at 04:12 +0000, Adam D. Ruppe via Digitalmars-d
> wrote:
> […]
>> Yea, I wrote my version several years ago (IIRC 2009 or early 2010) and since then D has grown as has my knowledge of it. I kinda want to write a web.d 2.0 that cleans everything up but eh I have a lot of things I want to do and web.d 1.0 works so no big rush.
>
> I disagree. The lesson from the Bottle/Flask/Tornado experience over the
> last few years is that it is always better to be working on the next
> version rather than just stick to maintaining the current version.
>
> Yes for using 1.0 on the current jobs, but definitely yes to starting on
> 2.0 now, especially if there are other to join in and help with the
> work.
>
> Web is not my area per se and I don't have a web-related project I can
> pin helping out with this effort on, but I would encourage you to work
> on 2.0.
>
> I will have to be looking at Python's asyncio which is Python's "play"
> in the arena that Twisted used to be king; more vibe.d than web.d.

I've been working on Cmsed/Dvorm/Dakka specifically in the mind of a rather (major) web service. Haven't started it yet, but possibly next semester.
I'm of the opinion that we all need to work together to get a damn nice web service framework together.
I split up my ORM for this purpose so even if you don't want to use Cmsed you can use it at least. Won't be very nice for normal Vibe users though.

I really do want help, Dakka (Actor framework) needs somebody who knows threading/networking communication. I'll eventually get it communicating with other nodes but.. Will opensource if there is interest.

Dvorm needs work to make it be usable with relational databases. At worse that means I need OpenDBX dlls for 32/64bit (wasn't as easy to compile as I thought).
The hardest part really is how to handle indexes.

Cmsed needs documentation by the bucket load. Its also blocked at the moment on dub to make it sensible to do reloading of templates/routes/models. Which will change the way you structure it.

Cmsed is already at the point of comparable to other web service frameworks in most other languages.

On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via Digitalmars-d wrote:
> Go has gained much of it's traction from provably and consistently
> producing simpler, faster and more reliable systems that C, C++, Python,
> etc. and getting articles about the success out there.

Python is simpler than Go for web. There is a reason for why Go is still not in production on App Engine, you end up with more convoluted code as far as I can tell. Faster, yep.