On Sunday, 26 July 2015 at 04:33:57 UTC, Rikki Cattermole wrote:
> On 26/07/2015 10:47 a.m., Brandon Ragland wrote:
>> [...]
>
> I wrote Cmsed[0], web service framework which uses Vibe.d and Dvorm (ORM)[1].
> They are both sunsetted.
>
> I'm currently working on a web server[2] that will ultimately replace a good bit of what Vibe.d is currently being used for. Which will be using libasync[3] (backend for vibe.d but purely in D) instead of Vibe.d.
>
> Of course progress is slow and my current set of code is not up in the repository as I wrote it on stream[4]. My intention is there, is once std.experimental.image gets more boring again / can't do much on stream I'll start work on it again. Once it comparable to what I've got on repo, I'll update it.
> In terms of what the web server will be like, Apache httpd config syntax[5] but a LOT more dynamic ala JSP style.
>
> Once web server is done then I'll continue with my web service framework based upon Cmsed. Most of that code is ready to go. It's just things like reloading and templates that need rewriting.
>
> [0] https://github.com/rikkimax/cmsed
> [1] https://github.com/rikkimax/dvorm
> [2] https://github.com/DNetDev/webserver
> [3] https://github.com/etcimon/libasync
> [4] https://www.livecoding.tv/alphaglosined/
> [5] https://github.com/DNetDev/apache_httpd_format

The idea of a JSP like system would bring a lot of the Java guys over to D.

JSP has JSTL and EL markup on the JSP pages that work well with servlets and EJBs.

I've been fooling around the repos posted here and thinking about what it might take to get a framework on top of vibe.d to perform similar functions as a Java container.

I appreciate the links / responses guys. It's always worth the read.

-Brandon

On 27/07/2015 6:18 a.m., Brandon Ragland wrote:
> On Sunday, 26 July 2015 at 04:33:57 UTC, Rikki Cattermole wrote:
>> On 26/07/2015 10:47 a.m., Brandon Ragland wrote:
>>> [...]
>>
>> I wrote Cmsed[0], web service framework which uses Vibe.d and Dvorm
>> (ORM)[1].
>> They are both sunsetted.
>>
>> I'm currently working on a web server[2] that will ultimately replace
>> a good bit of what Vibe.d is currently being used for. Which will be
>> using libasync[3] (backend for vibe.d but purely in D) instead of Vibe.d.
>>
>> Of course progress is slow and my current set of code is not up in the
>> repository as I wrote it on stream[4]. My intention is there, is once
>> std.experimental.image gets more boring again / can't do much on
>> stream I'll start work on it again. Once it comparable to what I've
>> got on repo, I'll update it.
>> In terms of what the web server will be like, Apache httpd config
>> syntax[5] but a LOT more dynamic ala JSP style.
>>
>> Once web server is done then I'll continue with my web service
>> framework based upon Cmsed. Most of that code is ready to go. It's
>> just things like reloading and templates that need rewriting.
>>
>> [0] https://github.com/rikkimax/cmsed
>> [1] https://github.com/rikkimax/dvorm
>> [2] https://github.com/DNetDev/webserver
>> [3] https://github.com/etcimon/libasync
>> [4] https://www.livecoding.tv/alphaglosined/
>> [5] https://github.com/DNetDev/apache_httpd_format
>
> The idea of a JSP like system would bring a lot of the Java guys over to D.
>
> JSP has JSTL and EL markup on the JSP pages that work well with servlets
> and EJBs.
>
> I've been fooling around the repos posted here and thinking about what
> it might take to get a framework on top of vibe.d to perform similar
> functions as a Java container.
>
> I appreciate the links / responses guys. It's always worth the read.
>
> -Brandon

What I currently have is code templates as follows:

<?lua
	echo("<p>" .. consumeNextText() .. "</p>")
?>

Hi there, this is some text!
Woopity doo.

<?lua
	include_text("<?lua echo(\"boo\") ?>")
?>

So it would output something like:
<p>
Hi there, this is some text!
Woopity doo.
</p>boo

The languages supported would have to be known and configured at compile time. But theoretically other languages such as Squirrel and PHP should work.
D on the other hand, would be ugh hard.

I will be supporting the ability to pass in e.g. data models and even query them. Thanks to reflection that I've added since Cmsed.

On Monday, 27 July 2015 at 04:11:50 UTC, Rikki Cattermole wrote:
> What I currently have is code templates as follows:
>
> <?lua
> 	echo("<p>" .. consumeNextText() .. "</p>")
> ?>
>
> Hi there, this is some text!
> Woopity doo.
>
> <?lua
> 	include_text("<?lua echo(\"boo\") ?>")
> ?>
>
> So it would output something like:
> <p>
> Hi there, this is some text!
> Woopity doo.
> </p>boo
>
> The languages supported would have to be known and configured at compile time. But theoretically other languages such as Squirrel and PHP should work.
> D on the other hand, would be ugh hard.
>
> I will be supporting the ability to pass in e.g. data models and even query them. Thanks to reflection that I've added since Cmsed.

I don't think it makes sense doing any page rendering in D, there are plenty of good tools that you don't want to compete with.

For instance, for rendering pages I would rather front the D backend with some (stateless) node app that fetches the data from the D backend and uses something like React to render server/client side. If the D backend could implement the upcoming GraphQL that would be awesome.

It has the benefit that a) the frontend-end devs still get their familiar language, tools and libraries; and b) that all the real stuff happens in D.

But I thought this was about Web Services Applications? Which I assume to be the outer container/process manager that allows services to be registered, re-loaded, routed, etc.

On 27/07/2015 6:10 p.m., Sebastiaan Koppe wrote:
> On Monday, 27 July 2015 at 04:11:50 UTC, Rikki Cattermole wrote:
>> What I currently have is code templates as follows:
>>
>> <?lua
>>     echo("<p>" .. consumeNextText() .. "</p>")
>> ?>
>>
>> Hi there, this is some text!
>> Woopity doo.
>>
>> <?lua
>>     include_text("<?lua echo(\"boo\") ?>")
>> ?>
>>
>> So it would output something like:
>> <p>
>> Hi there, this is some text!
>> Woopity doo.
>> </p>boo
>>
>> The languages supported would have to be known and configured at
>> compile time. But theoretically other languages such as Squirrel and
>> PHP should work.
>> D on the other hand, would be ugh hard.
>>
>> I will be supporting the ability to pass in e.g. data models and even
>> query them. Thanks to reflection that I've added since Cmsed.
>
> I don't think it makes sense doing any page rendering in D, there are
> plenty of good tools that you don't want to compete with.
>
> For instance, for rendering pages I would rather front the D backend
> with some (stateless) node app that fetches the data from the D backend
> and uses something like React to render server/client side. If the D
> backend could implement the upcoming GraphQL that would be awesome.
>
> It has the benefit that a) the frontend-end devs still get their
> familiar language, tools and libraries; and b) that all the real stuff
> happens in D.
>
> But I thought this was about Web Services Applications? Which I assume
> to be the outer container/process manager that allows services to be
> registered, re-loaded, routed, etc.

Most people will want to write web applications not web services, although they are _almost_ one in the same thing.

So, I've got to take that into account. Although nobody will force you to use it.

On 2015-07-26 20:18, Brandon Ragland wrote:

> The idea of a JSP like system would bring a lot of the Java guys over to D.
>
> JSP has JSTL and EL markup on the JSP pages that work well with servlets
> and EJBs.
>
> I've been fooling around the repos posted here and thinking about what
> it might take to get a framework on top of vibe.d to perform similar
> functions as a Java container.
>
> I appreciate the links / responses guys. It's always worth the read.

vibe.d has something called Diet templates [1].

[1] http://vibed.org/docs#html-templates

-- 
/Jacob Carlborg

On Tuesday, 28 July 2015 at 13:44:59 UTC, Jacob Carlborg wrote:
> On 2015-07-26 20:18, Brandon Ragland wrote:
>
>> The idea of a JSP like system would bring a lot of the Java guys over to D.
>>
>> JSP has JSTL and EL markup on the JSP pages that work well with servlets
>> and EJBs.
>>
>> I've been fooling around the repos posted here and thinking about what
>> it might take to get a framework on top of vibe.d to perform similar
>> functions as a Java container.
>>
>> I appreciate the links / responses guys. It's always worth the read.
>
> vibe.d has something called Diet templates [1].
>
> [1] http://vibed.org/docs#html-templates

http://code.dlang.org/packages/mustache-d
http://code.dlang.org/packages/temple

On Monday, 27 July 2015 at 06:10:29 UTC, Sebastiaan Koppe wrote:
> On Monday, 27 July 2015 at 04:11:50 UTC, Rikki Cattermole wrote:
>> What I currently have is code templates as follows:
>>
>> <?lua
>> 	echo("<p>" .. consumeNextText() .. "</p>")
>> ?>
>>
>> Hi there, this is some text!
>> Woopity doo.
>>
>> <?lua
>> 	include_text("<?lua echo(\"boo\") ?>")
>> ?>
>>
>> So it would output something like:
>> <p>
>> Hi there, this is some text!
>> Woopity doo.
>> </p>boo
>>
>> The languages supported would have to be known and configured at compile time. But theoretically other languages such as Squirrel and PHP should work.
>> D on the other hand, would be ugh hard.
>>
>> I will be supporting the ability to pass in e.g. data models and even query them. Thanks to reflection that I've added since Cmsed.
>
> I don't think it makes sense doing any page rendering in D, there are plenty of good tools that you don't want to compete with.
>
> For instance, for rendering pages I would rather front the D backend with some (stateless) node app that fetches the data from the D backend and uses something like React to render server/client side. If the D backend could implement the upcoming GraphQL that would be awesome.
>
> It has the benefit that a) the frontend-end devs still get their familiar language, tools and libraries; and b) that all the real stuff happens in D.
>
> But I thought this was about Web Services Applications? Which I assume to be the outer container/process manager that allows services to be registered, re-loaded, routed, etc.

The reality is D would be adapted for Web Apps in the tradition sense much more readily if indeed we implemented just the Web Services in D and left the familiar languages such as Java, PHP, etc. alone.

However, those languages (erhmm, especially PHP) are terribly slow and do not scale well. Java on the other hand may use vast amounts of Ram, but does actually perform fairly well, considering the extremely high level of abstraction, and then the complexity of that very same extraction with the JMS and EJBs.

A web services container in D would be the most _readily_ useful method of injecting performant D into the web services and web apps fields.

The idea that D is difficult to use as rendering language is certainly true, as is PHP in many respects.

A JSP style implementation without the stupid scriptlets that people try to inject is much better for this kind of a task.

Say we have a templated, standard, HTML / CSS / JS page. We could then take a tagging language such as the ones like Java's JSTL and Expression Language to insert information from the D based servlets.

Rendering a complete page inside D would be unnecessary, and a major source of headaches. However a D based servlet that consists of maybe ~50 lines total that could make callbacks to a database, or the web services containers to retrieve basic information, wouldn't be a bad idea.

Joking aside, a web services container would be best for D. And vibe.d seems to have a fairly good standing ground for this.

For actual web applications, and front-end development currently done in your more traditional languages, D could be used, in a style similar to Java's JSP, JSTL, and EL. Just without the notion of scripts in the pages themselves, as this would mean writing an on-the-fly interpreter, or compiling whole pages, which surely isn't an option for a compiled performant language; if we want it to be readily adapted.

Apologizes if I jumped around a lot, and misspelled. More difficult than I thought typing from my phone.

On Wednesday, 29 July 2015 at 00:12:21 UTC, Brandon Ragland wrote:
> For actual web applications, and front-end development currently done in your more traditional languages, D could be used, in a style similar to Java's JSP, JSTL, and EL. Just without the notion of scripts in the pages themselves, as this would mean writing an on-the-fly interpreter, or compiling whole pages, which surely isn't an option for a compiled performant language; if we want it to be readily adapted.
>
> Apologizes if I jumped around a lot, and misspelled. More difficult than I thought typing from my phone.

Most developers nowadays are having a lot of success building web apps with an AngularJS MVC & Vibe.d, rather than rendering the page entirely from the back-end. Heck, they can even build android or ios native apps with this architecture (see Ionic framework). So I think this makes more sense than rendering pages in the back-end, even if most legacy web stuff did that.

On Wednesday, 29 July 2015 at 01:23:54 UTC, Etienne Cimon wrote:
> Most developers nowadays are having a lot of success building web apps with an AngularJS MVC & Vibe.d, rather than rendering

Sorry, I meant with an AngularJS MVC & Web services

On 29/07/2015 12:12 p.m., Brandon Ragland wrote:
> On Monday, 27 July 2015 at 06:10:29 UTC, Sebastiaan Koppe wrote:
>> On Monday, 27 July 2015 at 04:11:50 UTC, Rikki Cattermole wrote:
>>> What I currently have is code templates as follows:
>>>
>>> <?lua
>>>     echo("<p>" .. consumeNextText() .. "</p>")
>>> ?>
>>>
>>> Hi there, this is some text!
>>> Woopity doo.
>>>
>>> <?lua
>>>     include_text("<?lua echo(\"boo\") ?>")
>>> ?>
>>>
>>> So it would output something like:
>>> <p>
>>> Hi there, this is some text!
>>> Woopity doo.
>>> </p>boo
>>>
>>> The languages supported would have to be known and configured at
>>> compile time. But theoretically other languages such as Squirrel and
>>> PHP should work.
>>> D on the other hand, would be ugh hard.
>>>
>>> I will be supporting the ability to pass in e.g. data models and even
>>> query them. Thanks to reflection that I've added since Cmsed.
>>
>> I don't think it makes sense doing any page rendering in D, there are
>> plenty of good tools that you don't want to compete with.
>>
>> For instance, for rendering pages I would rather front the D backend
>> with some (stateless) node app that fetches the data from the D
>> backend and uses something like React to render server/client side. If
>> the D backend could implement the upcoming GraphQL that would be awesome.
>>
>> It has the benefit that a) the frontend-end devs still get their
>> familiar language, tools and libraries; and b) that all the real stuff
>> happens in D.
>>
>> But I thought this was about Web Services Applications? Which I assume
>> to be the outer container/process manager that allows services to be
>> registered, re-loaded, routed, etc.
>
> The reality is D would be adapted for Web Apps in the tradition sense
> much more readily if indeed we implemented just the Web Services in D
> and left the familiar languages such as Java, PHP, etc. alone.
>
> However, those languages (erhmm, especially PHP) are terribly slow and
> do not scale well. Java on the other hand may use vast amounts of Ram,
> but does actually perform fairly well, considering the extremely high
> level of abstraction, and then the complexity of that very same
> extraction with the JMS and EJBs.
>
> A web services container in D would be the most _readily_ useful method
> of injecting performant D into the web services and web apps fields.
>
> The idea that D is difficult to use as rendering language is certainly
> true, as is PHP in many respects.
>
> A JSP style implementation without the stupid scriptlets that people try
> to inject is much better for this kind of a task.
>
> Say we have a templated, standard, HTML / CSS / JS page. We could then
> take a tagging language such as the ones like Java's JSTL and Expression
> Language to insert information from the D based servlets.
>
> Rendering a complete page inside D would be unnecessary, and a major
> source of headaches. However a D based servlet that consists of maybe
> ~50 lines total that could make callbacks to a database, or the web
> services containers to retrieve basic information, wouldn't be a bad idea.
>
> Joking aside, a web services container would be best for D. And vibe.d
> seems to have a fairly good standing ground for this.
>
> For actual web applications, and front-end development currently done in
> your more traditional languages, D could be used, in a style similar to
> Java's JSP, JSTL, and EL. Just without the notion of scripts in the
> pages themselves, as this would mean writing an on-the-fly interpreter,
> or compiling whole pages, which surely isn't an option for a compiled
> performant language; if we want it to be readily adapted.
>
> Apologizes if I jumped around a lot, and misspelled. More difficult than
> I thought typing from my phone.

One of the benefits for D is that we can build up e.g. RESTFUL/SOAP web services rather easily. We don't need to serve up generated html/css/js but we can serve up assets which are html/css/js that could go through a preprocessor and then cache the result.

Either way, I have long since felt that using D in templates is a waste of resources. It's doable, very. Just not really worth it.