I'll chime in, I did a haxe servlet server called hxServlet, it's available on libs.haxe.org. I'm thinking of doing something similar for fpc. First, hxServlet is like ruby on rails mongrel, indeed it uses the http header parser from mongrel, however it uses haXe's neko vm as the server, and it's use is behind a proxy for delivering dynamic content as it's not a full featured httpd.
Anyway, what I'm considering for fpc is wrapping jsapi, spidermonkey's API, and link it into a pascal binary, which could contain a web server for server side apps, and could just be a scripting language for desktop apps. My focus tends to be web apps. I think with spidermonkey now able to JIT and a server side JS API movement taking shape, http://groups.google.com/group/serverjs, that server side Javascript backed by a pascal runtime is quite a nice combination. My goal would be to use RTTI to expose any pascal object as a js global without pain and be able to create a servlet e.g. (off the top of my head) ... makeServlet(function(srv) { srv.url ="/servlets/helloworld"; srv.doGet(function(headers)) { sqlite.query("select * from ...") ; print "hello world" }) }) It would be easy to decide which code should be written in JS and which to be moved to Pascal for speed or plumbing, in this example, sqlite a global JS object registered from fpc hopefully transparently. Maybe this has been done already - for another language? - if so great !. Regards, targeted and compiled javascript on the client, like gwt or haxe (i did a haxe hxScriptlet similar to jquery), the problem is debugging it, and using existing libs, you can, but it's painful, and my takeaway from trying it, is it's not worth it, as you're fighting against the tide. If you give it some time JS is actually very nice, and with a tool like JSlint or a sophisticated editor like netbeans you can remove most of the pain points. I would think the inclusion of tooling for JS within lazarus, codetools for JS, would be a good (for me anyway :)) - so that development could be done naturally from one place. I'm fairly new to fpc and and object pascal, but I've decided that I'm fed up with VMs, when I look at fpc I wonder where the huge advancements in VMs are apart from complexity and memory consumption - i do make a distinction with a VM in a scripting language, but for something I have to compile anyway i'm not convinced of the wins. Thanks for fpc, it's very pleasant to work with. Cheers bd On Mon, 2009-03-30 at 21:16 +0200, Dariusz Mazur wrote: > Adrian Veith pisze: > > Dariusz Mazur schrieb: > > > >> Marco van de Voort pisze: > >> > >>> In our previous episode, Michael Van Canneyt said: > >>> > >>> > >>>>> But maybe I dont understand your need. > >>>>> You think about counterpart of LCL level, or computation wide > >>>>> consist in event > >>>>> (form.onclick, form.onedit) function in Delphi ? > >>>>> > >>>>> > >>>> All events and almost any class I need should be available in the > >>>> client... > >>>> > >>>> > >>> Aren't you talking about two different classes? Webapps with some > >>> browser > >>> (Ajax) support, and more RIA-like JS apps? > >>> > >>> At least that is how it sounds to me, with Michael going more to the RIA > >>> direction. > >>> > >>> > >>> > >> I don't talk about any compromise with appearance of application. > >> Everything, as you imagine should be done with HTML+CSS. > >> I dont think (I testing it every day) that is any bigger issue, that > >> can't be done on server side with small JS addons on browser. > >> RIA means for users beautiful, with 3D, alfa and animations efect. All > >> can be done with small assistance of JS. > >> > > That's the point - how do you define small ?!? > > > As i mention before 1..2 kLOC all JS code for whole application. But it > doesn't matter. Most of them is universal, as LCL. > Is small as assembler inlines in most of applications. > > If you can't do everything on the server, you have to perform some part > > of the logic on the client. > Why any on logic move to client. I say only about GUI computation. > > And the richer the client gets, the more > > logic has to be performed on the client. Now you have the choice: > > > > 1. do the small part in JS - with the knowledge, that this part will > > likely increase in the future > > 2. or look for an alternative language, which is as close to what you > > are used to program as possible > > > > My decision is clear, after some hours hunting a bug, because i > > declared a var "id" and somewhere made a test against "Id". I am using > > the haxe to JS compiler, because its typesafe. If there were a pascal to > > JS compiler, it would be an option to. But I doubt, that is feasible to > > convert the libraries to work under that environment. And that's the > > next problem. A language is only as good as its supporting libraries. > > > I have the same point. Strong language is best choice for huge > application. I don't want to leave pascal, because it work: on desktop, > on web side, without imaginable limitation (performance, portables, > flexibility). > Second: I don't want depend from users computer, name and version > browser, plugins. But if you move more code to client side, then more > dependences you acquire. > > And about HAXE. Its tool to write application for browser. For it seems > good. But I told about moving desktop, client-server, multiuser > application to web-based. Maybe HAXE in outline similar to FPC, but till > now hundred times smaller. Who trust this young and unknown technology > and base huge application on it. And server side ? You can translate > client site to JS, server site to PHP, but what about communication > client-server. > > > Darek > > > _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
