Prado Roadmap - v3.2 or v4?

[jake]

Hello,

I'm wondering where the Prado's future is headed. Looking from the Trac I don't really see any new goals besides minor bug fixing and a little tweak here and there. Even if Prado doesn't move anywhere within the next year it probably will still be my favorite framework just because of the nature of how it functions however I would like to know what the Prado team has in store for us in the future.

Sooner or later PHP is going to be up to speed with namespace support and with that feature alone I can see that the way people develop PHP might change, for the better at least. ASP.NET and Tapestry have also been morphing into greater frameworks and aren't exactly what they were a few years ago and I would like to know if Prado is aiming to catch up to them or is Prado going to be a dead fish in the sea?

I'd really hate for that to happen because I come back to the forums every now and then and I don't really see the senior developers around anymore but I still see new people joining and asking questions every once in a while. Of course that doesn't mean the senior developers are 100% gone but I'd like to know if they still care and if this project still has a future.

Thanks,
- Jake

[Kabayan]

Well, I think they are quite busy right know.
But one think for sure, they are fixing the bugs and creating something new.

[drigolin]

More Performances from my point of view is a key point Prado should address in the near future.
Prado extension project or other redesign to have something like a TQuickPage instead of TPage where only render or load&render phase are present and maybe accessing only viewstate and not having all component structure be "recreated".
Or any other lightversion of components to increase performances in various areas where at the moment Prado is suffering compared to other emerging framework.

Maybe better caching strategies could help. In my performace tests "Performace" and "Debug" doesn't seems to affect too much application speed. Template compilation to a pure PHP instead of serialize/deserialize.

Prado::using efficency.

The primary critic to  Prado is related to performance compared to other like Symphony, Solar o ZendFramework. Basically I saw many benchmark where they are compared our simple helloworld application implemented into any framework. No DB access and so on. In this scenario Prado pays a bigger basic layer also into simple scenarios like helloworld application.

My idea of having a "light" version of prado page or prado application should make prado faster into simple scenarios and also provide a way to increase RPS on some specific case. One example is autocomplete on complex pages (many components) in any case the "load phases" of the page during the callback is more than a 30% and having a sort of "direct callbacks" called on server and avoiding the all page "status reload" if a need only few things.

This post is more a brainstorming than a real list of features. I hope this could be a starting point for other people to discuss the future of Prado Framework.

Dario

[jft]

I, for one, am very impressed with this application - all power & appreciation to those who have committed their time and effort to get it to this point! 
May PRADO continue to forge ahead ...!!!

Thanks guys,
John

[rojaro]

I have a pretty huge and complex PRADO based application running, which peaks at about 50 to 70 requests per second that are handled by a single webserver (excluding static images, static css and static javascript which are served from a separate cache server) and the machine still has enough resources left to handle twice the load it currently has to handle. Getting this excellent performance with PRADO was actually pretty simple. Have a look at this list (written by the guy that actually maintains the eioba.com website which is also a pretty huge and successful PRADO based project) which is fairly complete and describes the basic steps to be taken to get a really fast PRADO application.

However, the most important point, which is unfortunately missing in that mentioned list, is the quality of your code. If you write shitty code, you cant expect PRADO to perform wonders. When you write your code, think about it's complexity and whether there is a more elegant and faster method to achive the same result. That starts with simple things such as using

if($foo === null) { ... }

instead of

if(is_null($foo)) { ... }

as the first construct is a simple language construct which unlike the latter example doesnt require any function lookups to be done by the PHP interpreter. That will save you just a few CPU cycles, but imagine having to serve more than a few requests per second, then the performance payoff is actually pretty big as you probably have several of these constructs in your code. You can find more examples in this list or if you really want to learn something (unless you know shit), have a look at this article which is a little bit old (and mainly talks about PHP4) but it's teachings are still valid today.

The same applies to writing SQL code: Keep your SQL as simple as possible and also try to optimize your queries if they really have to be complex (especially when doing complex joins). MySQL is often faster handling two simple queries than handling one complex one and try to cache your queries where ever it makes sense (which is probably the case with at least half of all the queries in complex applications).

Just to give you an idea what difference just the caching makes: When i disable the caching in my application, the server is running hot at max load while only handling about 5 requests per second.

Greetings from Hamburg / Germany
- rojaro -

PS. Benchmarks mean shit. You cant compare apples with trees or cars and comparing "Hello World" performance of Cake, Symfony, Zend and other frameworks or languages (Ruby, Python, Java, PHP, C# ...) says nothing about each frameworks real world application performance with your specific application needs/requirements. As Scotty used to say: "Always use the right tool for the right job" ... PRADO might just not be the right tool for you.

PPS. Dont feel offended by this post. I dont mean anybody personally  ;-)

[rojaro]

Back to the original topic

The namespace support is probably one of the most important things that should be fixed in 3.2, but of course not before PHP 5.3 is officially out. That would probably mean loosing backwards compatibility with PHP 5.2.x, but i actually like moving ahead much more than being stuck ...

Another important thing - which i would project for 4.0 - is a complete overhaul of the prado JavaScript. Second, the JavaScript code needs to be much better documented and third there should be support for multiple/paralell callbacks.

Greetings from Hamburg / Germany
- rojaro -

[drigolin]

I have also application running fast enough on prado but at cost to do many optimization.
Activating caching ad avoiding TRepeater and TDataGrid and having custom component doing direct rendering of HTML is a solution common for us, but I still thinking that many aspect of prado speed can be increased.

I'm thinking that we should also work on profiling and optimizing prado because I think we can do more on that area.
My ideas was suggestion to increase the adoption of prado. Many forums and communities look at Prado like a FAT and powerful framework and I know that with work and expertise we can make it running fast. But at first look prado seems/is slow.

A Prado happy user...

[mikl]

rojaro, thanks for that really useful compilation of tipps. I think all the information on the pages you listed would be worth a wiki article to keep the information handy for new users.

I also second your request for a complete ovherhaul of the javascript code. Adapters for all the famous frameworks (Prototype, YUI, extJS, etc.) would be really cool.  The current code IMHO isn't really future proof. Whenever i think about the clientside, i lose myself in complexity. It somehow feels wrong to do more complex stuff with the ActiveControls we have now.

Just for example: You want to create a DataGrid with the option to open an edit panel for each entry on the clientside. A task that's quite basic with a framework like for example YUI or extJS. But making this work together with server components of prado can become a real headache - at least for me. In the end we will always do some kind of code generation for the clientside which feels like a bad thing for me. It's so much easier to do the clientside coding in the language where it belongs: javascript. Maybe a Prado clientside framework built on top of other frameworks that's optimized to interact with the server and take over lots of UI stuff might be a solution to this. But that's not more than a rough idea.

BTW: I've started documenting the current js implementation some time ago and  the generator is already in SVN. I never had much feedback on this and some helping hand would be great.

[pradofungus]

Currently I'm starting to evaluate several PHP (CodeIgniter, Symfony, Zoop, Solar, Kohana, P4A... there are tons! ) and non-PHP frameworks (RoR?  ) because I need something which scales well over a server farm and is fast.

One point Prado should improve, if there's more development on it, is performance (read this and this). And also scalability. Better and transparent AJAX/Javascript support is also a must.

[rojaro]

@pradofungus,

Have your read the comments to that blog article you've linked? Again, comparing "Hello World" performance of Cake, Symfony, Zend and all the other frameworks or languages (Ruby, Python, Java, PHP, C# ...) says nothing about each frameworks real world application performance with your specific application needs/requirements. Also the quality of the code you're producing is one of the major factors. In the end it comes down to selecting the right framework over its completeness, documentation, quality of the code within, programming methods used, extendability and the possibilities each framework offers. I am not saying that PRADO is the best framework, but that you just cannot compare diffrent frameworks and programming/scripting languages through benchmarks. Benchmarks over frameworks mean shit.

If you would want to build a pool in your backyards lawn, you would not use a spoon to dig a hole in your garden just because you can (least performance). You also would not use a chain dredger or dynamite (highest performance and i know they'd be both be lots of fun). You'd select the tool that serves the purpose without doing too much damage to the rest of your lawn/backyard. So either you're using a small skid loader or get a few friends, hand everyone a shovel (plus a few beers) and eventually get the job done in the usually most economic way.

Also, PRADOs performance is really great. As drigolin already said: "Many forums and communities look at Prado like a FAT and powerful framework and I know that with work and expertise we can make it running fast. But at first look prado seems/is slow." and therein lies the rub: If it is not performing well enough for you, than you just didnt do what it takes to get it performing well (e.g. Byte Code Caching, Memory Caching as well as clean, structured & optimized code development). PRADO is actually designed to be used with (a great choice of) caching mechanisms and will perform badly when not used correctly as it is a huge and complex framework.

Therefore my advice to you: Write tests, read into each frameworks code, figure out how things are done, which possibilities are offered and then use the thing that serves your purpose best. In the end, all good web frameworks, all good web programming languages rely on the very same methods to get em quick: Tuning and Caching. If you cant use these two methods with a framework/language, dont even think about using it.

Anyway, PRADO is also not a system, a network, or a process, but a framework (which can be extended, modified and improved) and therefore scalability has never been an issue. When talking about scalability you have to talk about the database servers (e.g. MySQL, PostgreSQL, Oracle), webserver software (e.g. Apache, LightTPD), language interpreters/bytecode compilers (PHP, Python, Ruby, Java etc.) and of course hardware you're using.

However, as i already wrote in one of my previous posts, i totally agree with you that the JavaScript part needs a complete overhaul.

Greetings from Hamburg / Germany
- rojaro -

PS. 100 page requests per second are nice, but how many page request are needed to earn you a single cent? If it would take just 5 page requests to earn an €uro while having 100 page requests per second ... I'd book a trip to the space station

[rojaro]

@mikl,

i totally agree. I'm also no expert at JavaScript and in that regard i really miss Wei and his ongoing contributions and support in the forums. I bet he could solve these problems easily and since i know that'd be a shitload of work, I would actually pay him to do it ...

Greetings from Hamburg / Germany
- rojaro -

[mikl]

Javascript itself would not be a problem. You can meanwhile develop a full application in javascript that takes over the complete controller/view part and only talks to the server to reload/store data. I've done that and its really cool to work this way. Suddenly your web-applications become full-fledged desktop like apps.

My problem is, how could an integration with Prado's server components be achieved - and can it be achieved at all? It feels like two totally different concepts: Generating every component by the server (the way PRADO does it) or giving the client more power to decide by the last user action, if (and which) component must be instantiated (an edit form? a treeview? a tab panel?).

Take for example extJS' LayoutManager, which allows to use different frame like panels that you can populate with any other component you like (treeview, edit form, etc.). And switch between them with a single click. How can we think of combining that with prado? Prado always wants to know about each and every component on a page. If we keep this paradigm, we loose flexibility on the clientside. If we abandon it, we need a completely different philosophy for Prado.

I'm not sure if anyone gets my point . But i'd be interested to hear ideas, how to approach this problem.

[rojaro]

I havent looked at it yet (got the tip like two days ago and been busy working on a project), but PHP-Ext ( http://php-ext.quimera-solutions.com/ ) might provide a few ideas. If i've read it right, they already implemented the layout stuff as generalized PHP class. Should not be too difficult to adapt for PRADO.

Greetings from Hamburg / Germany
- rojaro -

[notzippy]

Hi

Currently the issue (as I see it) is that the page is a completed puzzle, you cannot add or remove pieces without disrupting the page as a whole, but if the page was more like a tree trunk and the controls could be pruned or grafted on. If (for example) each TLimbControl (extends TTemplateControl) serialized its own information separately but each control linked back to the page in a manner which transparently still allowed access to all the controls, then there would be no need for the entire page to be rebuilt on every request (currently a big issue if controls need to be dynamically added (or removed)). Form validation could potentially be a challenge to do but probably an opt in / opt out strategy would work.

I am not sure where prado is going but I am definitely on board for the long run. There have been a lot of frameworks in various languages using MVC, prado is by far the easiest to implement and the cleanest to build a structure with. Keep up the excellent work !

z

p.s. I like jquery for javascript, the core is simple, intelligent and expandable, recently they added a UI library plug-in that adds new capabilities that provide event more client side capabilities.

[pradofungus]

Have your read the comments to that blog article you've linked? Again, comparing "Hello World" performance of Cake, Symfony, Zend and all the other frameworks or languages (Ruby, Python, Java, PHP, C# ...) says nothing about each frameworks real world application

Of course not, but they give you a basic idea. I'm not saying Prado is bad (I liked the idea a lot since 1.x), I'm just pointing to some benchmarks. Of course, there are tons of others factors to consider when choosing a framework or language: which extensions do they offer, how hard to learn is, how clean the separation between layers is, the quantity/quality of components (if any) provided... and the list goes on and on. Performance is also part of that list.

Anyway, PRADO is also not a system, a network, or a process, but a framework (which can be extended, modified and improved) and therefore scalability has never been an issue.

As you say, it just needs to be modified, specifically the pagestate thing.

However, as i already wrote in one of my previous posts, i totally agree with you that the JavaScript part needs a complete overhaul.

Ok, back on topic, it'd be great to have all the controls AJAX-aware transparently (again, the pagestate thing...)

Regards
The fungus.