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.
