D Web Services Application Potential?

[Brandon Ragland via Digitalmars-d]

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.