[Lazarus] FCL-Web and new WebDesign packages

Marco van de Voort marcov at stack.nl
Thu Jan 28 16:20:42 CET 2010


On Thu, Jan 28, 2010 at 08:57:56AM -0600, Andrew Brunner wrote:
> >> because Pascal is not as well suited for dynamic languages and
> >> environments -
> 
> Do you mean scripting languages like JavaScript?  If this is the case
> than you should know that there are pascal based scripting utilities
> for server side scripting.

Not my line.
 
> 
> > It has variant, dispatch interfaces, and can interface with such
> > environments if need be. But the question is if that is really neccessary or
> > applicable to webapps.
> 
> None if it is.  I'm speaking from experience when I say all that is
> needed is good AJAX experience for designing the front-end.  I don't
> see pascal overtaking JavaScript anytime soon as it's not needed.  No
> need to re-invent the wheel.  Javascript with Prototype does the job.

The Ajax and JS is already embedded in the widgets you use serverside. No
need to do that manually. 

> >> I use pascal since 30 years for my every day development
> >> and love it - but IMHO for web programming, it is more productive to
> >> have a dynamic language
> 
> I agree.  A widely adopted scripting language (JavaScript) is required
> for real-time web applications.  

1. while needed for functioning of webapps, it might not need to be written (see e.g.
general ASP.NET use) by maker of webapps. Just like you don't need to know
the gore of assembler when programming pascal.
2. Javascripts sole point is that it is standarised in browsers. Nothing
more. Any sandboxable language is suitable for that.

> But let's not confuse back-enda development with front-end applications
> over the Internet - which will always require some sort of interpreting
> and/or dynamic code execution.

Do not confuse javascript being the only more or less guaranteed browser
language to a need to actually churn out javascript as part of a standard
webapp. There are examples enough that prove otherwise for the majority 
of the application, where components hook into a standard JS library,
without programmer intervention.
 
> > Care to explain? I don't see the need for this at all.
> >> it is the nature of websites.
> >
> > I don't see this either.
> 
> For my back end I use a Social computing platform that supports serves
> the back-end and provides the client side with feature rich
> applications over the Internet using HTTP.  Front-Ends are provided to
> web-browser utilizing javascript and the app makes calls back to the
> server that processes via compiled "core" objects.  Each core object
> executes with minimal interpretation.

This is comparable with the fact that CPUs only execute machinecode. Yet
there are other languages available for PC. The fact that JS is the only
language available browserside doesn't mean you always have to deal with it.


> Feature rich client-server application over the Web requires many
> different technologies.  And FPC will never be a catch all one shot
> solution...  unless it builds an execution environment, and that is
> extremely out of the scope of anything I've seen so far.

A FPC based framework that for the browser side parts of its widgets  hooks
into existing javascript helper libs would be enough.

I think this is the way where webdevelopment is going.
 
> > SNIP >>>> There is IMHO nothing inheritly untyped or dynamically typed in webprogramming, save tradition.
> 
> The only insight I have to offer is to refer you to see JavaScript prototyping.

Explain.





More information about the Lazarus mailing list