As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Delphi developers has several tools (several alternatives to ASP.NET) for building web applications.
While No.1 framework is Intraweb, there is a lot of interest around ExtJS, that has 2 incarnations:
1) the opensource ExtPascal
2) the closedsource Raudus
Now the products are different, Raudus never supports the latest ExtJS version (while ExtPascal does because as far as I read it "almost automatically updates itself to the latest ExJS version"), Raudus "seems" much RAD (much similar to Intraweb from the RAD point of view).
Anyway why chose one or the other?
Why Raudus (since it is free) cannot become Open Source? Or does Raudus use ExtPascal behind the scenes?
Comment: uniGUI seems at first sight to combine the good part of Raudus (the RAD part) and ExtPascal (being based on extPascal).
Talking about Raudus, I'd be careful! You can download it for free, indeed. I was about to start using it when I realized there's no single word on its usage license. There's no license in fact, or I was unable to find it under "standard" locations (website? no. installer? no. README / LICENSE file? no.)
Thus I'd be careful with using library which doesn't specify it's license. Especially if you're about to start some project which will use it intensely - just imagine what happens when it comes out that you need to pay big amount of money for using it ...
Why use any of them? RAD in the form of Intraweb and tools like it, is not appropriate for web programing. It doens't separate the GUI from bussines logic well. In other words there is no true MVC approach there. Maybe ExtPascal is different here, but the point is elsewhere.
ExtJS is a very well written RAI JS library. It feels almost like putting blocks of code together in a very object oriented way. You can easily build whole GUI with ExtJS without any backend support. This way your whole GUI is in javascript files and no backend is needed. Backend only processes the ajax call and provides data / processes data. This way you have a clear separation of concerns.
This can be easily done without any frameworks. Yes framework would come in handy but it would have to be done in a ASP.NET MVC or Ruby on Rails way. No RAD and no visual designers. New web developers often make those mistakes. But if you program for the web long enough you come to appreciate the separation of GUI and logic and the simplicity of HTML. Web programming is different from desktop programming at least to a degree.
To answer your question. From what I have seen, I like ExtPascal better. It seems a purer web development tool than Raudus. But I admit I have only seen both from the surface and from demo videos, so I cannot judge, only speculate :)
The Raudus developer put up a new blog post in late October and claims, well I'll let you read the snippet for yourself:
"Raudus license is freeware as written in license.txt. You CAN use Raudus in commercial projects. Raudus sources are not available yet."
Edit: There is a license statement at the bottom of the http://www.raudus.com/ page.
"License
Raudus is freeware. You can freely use Raudus for commercial purposes."
As to contacting the author, try this from the same page: E-mail: igor#klopov.com
After using Raudus for a few months I decided to post my own answer.
The framework is improving, Sencha touch support now it is not complete but sufficient to create usable web applications optimized for mobile devices.
RFE, a new front end, not based on Sencha Touch is under developement and in next Raudus release (that should be out soon) there will be a usable preview of the new controls set.
So while ExtPascal seems frozen, Raudus is in progress and promising.
Update: I stopped using Raudus, it dropped ExtJs support and now it ships with own controls, that will never match the beauty and richness of extjs components. I am now going for IW + cgdevtools components that are Jquery UI for IW.
user193655 --> Depending on what you do be carefull with both approaches. I am really a big fan on Delphi or Freepascal/Lazarus - I am not very certain if the approach of bringing 3GL bindings to the Javascript stuff is wise.
MVC - depending on what you do - in PHP you have the Yii Framwork or Prado. Maybe the second has some ideas from .net built in which are very easy to understand by Delphi developers. PRADO is an event driven approach while YII Framework is absolutely cool and unix like.
After using Raudus it seems that it is not practical for large scale of applications.
According to their documentation and I have also sampled, it serializes all client request into single main thread. However it process client request and response generation part in multi-threaded enviornment.
But main thread issue is quite important as it directly impact the response time if one action is taking more time in the main thread, others will keep waiting.
Any suggestions to resolve this issue?
Raudus:
Relies upon Delphi, in which:
Is verbose;
Relies upon Microsoft Windows;
High-cost to adapt to or to maintain;
Quote from raudus.com: "Raudus is freeware. You can freely use Raudus for commercial purposes. Raudus sources are not available yet." — This, to me, will be never a license. On the homepage, simply there is no documentation about Terms of Service or something like that. Hence I won't deal with their services.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I hope that this question gets clear to everyone.
What I find great about Delphi is that with RAD (rapid application development) we can pick components and put them directly to the form and connect them to other components and methods.
It's so good that when I need to make an application that share information I use a remote online database server, but I don't make a Web site. I use zeos library and make a Delphi application.
But it is become dangerous as my clients are beginning to ask for use with tablets and smartphones.
What I hate about Web is the hard manual development of the interface and connection with the controllers.
But I might be wrong as there could exist great tools and Delphi like ide to work as fast as the real Delphi.
*Does anyone experience that? *
I tried rad php xe but I find it very complicated to code as you have to mix php and javascript in the same files and does not have a good mvc structure.
Dreamweaver is full of bugs and does not have a debug
PhpEd has good code control but does not have interface editor.
So,How to make a master-detail database Web site as fast as making the same with Delphi. Which visual IDE should I use?
DevExpress offers beautiful grids and other controls in case that's what you are looking for. It's not for Delphi but ASP.NET.
ASP.NET Controls, MVC Extensions at DevExpress
There are a number of large and small considerations to make when developing a website, that differ from making a desktop application. It's easy to imagine a RAD IDE environment that allows you to drag and drop components onto a page, and have the work done for you to convert it into a website that responds to requests, but it in general this will hide a lot of important properties of the website that have a big impact on its operation and performance.
A website is hosted on a webserver (or several webservers), generally serves concurrent requests for multiple users, and streams content to a web-browser that renders the page on screen. Any self-respecting modern website will also use smaller AJAX requests to add data to an existing page, and use client-side scripting for validation and navigation. Not to forget alternate views for the visually impaired, mobile devices, or other applications that want to hook up to an API.
The truth is a platform that does all this for you could exist, but in my opinion will underperform, produce overly large pages and will have made important decisions for you, you will run into as soon as the applications gets more complex, or needs to perform under a certain load.
There is a reason cutting-edge web-developers work close to the code (HTML, JavaScript, CSS...) and even prefer to have pieces of code and server-side logic in the same source files, like PHP,ASP,Cold Fusion,Ruby,Python... I wanted to combine this with the speed and power of the Delphi compiler and started http://xxm.sf.net/ that enables you to create both small and huge projects, keep in close touch with the code that constructs the response for a request, and lets you choose how and where you host the website.
I hope this in part answers your question, though you did not ask for ways to make a master-detail website with Delphi.
I suggest Delphi using IntraWeb. I've used it in the past, and it worked fairly well.
I suggest looking at the thread Alternatives for IntraWeb in Delphi? as a starting point which also discusses IntraWeb like products.
A description of IntraWeb from that thread:
Intraweb is a framework for developing web applications using Delphi/VCL. In the IDE you design and code using Delphi language and components. Intraweb's engine generates HTML pages using JavaScript/Ajax and those pages look and behave more or less like Delphi forms and components, but in the browser context. An Intraweb application is deployed using a webServer of some sort, which serves up those pages to browser based clients. – Mikey May 21 '11 at 6:09
You would, of course, have to host the app on a Windows server, since the code that Intraweb creates will only run on Windows.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I've just been redirected by a firend on the uniGUI website. In a previous question I asked about a comparison between Raudus and ExtPascal.
Now this unigui seems to be an alternative to Raudus, that moreover has the advantage of allowing you to compile the win32 exe at the same time with the same source code (of course if you limit yourself to use only uniGUI approved UI components).
I think this is amazing, even if this idea at a first sight willnot make happy all the web apps purists, but in my opionion having this kind of tool is great.
There are many (even small) applications, that can benefit for this code once, get a double UI.
Anyway which are your feelings about this? Do you think it has a future?
ADDITIONAL NOTE: In order not to start a general discussion please try to answer by mentioniong uniGUI specifically, not only a general answer. Thanks.
I started developing uniGUI (or whatever name it may adopt in future) around two years ago. Since then it has evolved a lot. Initial version was based on VCL for the Web. With addition of ExtPascal and Ext JS it has become a very advanced tool to develop Web apps based on Delphi.
uniGUI simply defines itself as a Web Application Development framework. The concept of Web Application has been controversial since its first inception. Some people claim that Web is stateless but applications are statefull, one should not mix these two. However, nowadays with an increasing demand for web applications such notions only remain as a philosophical point of view.
More and more people want to access their desktop apps from the internet. Companies want their local accounting software to be accessible to other branches. A security company wants a web gateway for their access control software. These are all examples for the increasing demand for web apps.
We can consider uniGUI as an abstraction layer for Delphi VCL controls which extends them to the Web. Like all other abstraction layers it helps developer to focus on application logic rather than the development tool itself. It tries to fully integrate the RAD approach into Delphi based Web development.
Dual nature of uniGUI is simply a plus. I'm referring to its ability to deploy same application to both web and desktop using same codebase. This feature maybe useful for some developers but useless for others and it can be completely ignored by those who focus on Web development only.
As for the scalability, the best target for uniGUI and other similar tools seems to be the intranet where the number of clients are predictable and connection speed is a non-issue.
That said, nothing prevents developers from developing web apps that target the internet. At end it is all Ext JS on the client side and Delphi event handlers on the server side. It all depends on how smart you design your app and how efficient you manage your resources. If each of your sessions consumes 10 MB of memory then you're likely to run out of memory very soon.
In conclusion, this framework will have a group of users which will find it best for their needs. There is no black or white here only big gray areas. Like any other tool it depends on the company, the particular project and the available deployment options to see if it is the right tool for you or not.
Web applications are very different from GUI ones. Mixing two approaches for something
more serious then simple form or several buttons I think is just wrong.
I think that the UniGUI idea is a great one. But I think that Embarcadero is the one that should offer that as one more option for developers instead of a independent one. Delphi developers always wanted an easy way to create web applications, and sincerely WebBroker is very poor.
Anyway which are your feelings about this? Do you think it has a future?
The general idea definitely has a future, if only in the PT Barnum sense. This particular implementation doesn't seem to be anything special - there's nothing in it that grabs me as being a great solution to any of the problems I currently have to deal with. But then, I see thick client apps, especially traditional Delphi 2 tier apps, as quite different from web apps.
I'd be more interested if uniGUI worked the other way, and provided a solid MVC framework for Delphi, then extended that to the web. That way you could more easily have your data + business logic + GUI in three connected pieces, rather than the traditional Delphi/RAD problem that business logic gets all tangled up in the GUI, then the web application is a pain to develop because the layers "have to be" separated. This smells like "solving" that problem by letting you leave the business logic mixed into the GUI when you move to the web.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm building a new game and I need to build a web app to help manage content generation. The app would consist of a couple simple forms that would tie into a MySQL db.
I've been really interested in learning Lua for a long time due to it's large popularity in the video game industry and was wondering how well it works as a server side language. I could easily write the web app in PHP but I'd rather use this opportunity to learn Lua if it makes sense.
What do you all think?
Cheers,
Sure it can be done. Good idea if you just want to learn Lua. You should start here: http://www.keplerproject.org/
Of course, if your app would consist of a couple simple forms, you can use all what you want. But if it is more complex (will become more complex in future) it will be better to use some industry standard languages like Python or Ruby (or, at least PHP), there are a lot of good frameworks writen in them that very simplify your work (I don't know about any complete lua web frameworks) .
You should remember, that in future other people will have to maintain your code and there are very few web-developers who know Lua.
Probably, there will be problems with documentation and basic libraries too.
While LUA is a nice language for embedded development but i would extremely vote against LUA for web development.
The reason is that in Games you simply don't have an external API. All is done with your own objects only some calls into your game engine.
But the web world is so full of stuff you need, like SMTP, POP3, IMAP, SSL, Amazon APIs, Google APIs, RSS Apis, Imaging etc. and while the checklist for LUA may have a check mark behind all this words - it doesn't mean anything. Most of the stuff i have seen is just a "me too| implementation but not industrial strength. They are projects by hobbyists and are published on a "Its good enough for me" basis which is total unacceptable if you ever go mission critical.
There is a reason why it takes years and a huge community to get this up. Lua has an extremely small community of web developers.
So if this is a professional project where you put your money i can only say hands off. On the other side if you have enough money i still have some snake oil here for sale, please contact me.
I have been using lua for years as a web language. Initially using the Xavante project and more recently apache2.
Dont listen to any neigh sayers, its a great language for web developement and we use it to write business software, and not just for form processing, for graphical applications too.
Also it offers us seamless integration to any other lua or system functions we might need to call.
Good Luck!
Have a look at Nanoki which is built on a pretty minimal set of libraries (lfs, luasocket, lzlib, slncrypto)
and Sputnik which is built on Xavante or CGI
Lua is a good language but it is best suited to embedding within an existing project in order to quickly extend the capabilities of that project. In particular, the interesting aspect comes with how you bind it to the host application. This is definitely the case when programming for games where it is an embedded language rather than the language the whole app tends to be written in. So using a web app to learn about Lua with a view to making games is probably not a very good approach, especially since the syntax is very simple and would be picked up quite quickly anyway.
I think that specific variants of lua can be used successfully for web applications and I have done that in the past using the maintained weblibrary. It can depend on if the lower level software on the computer is itself written in lua because of its high speed and this may cause a clash of lua versions. Regarding a serverside possibility the server would need a compatible version of the script developing facility for the hardware and a suitable bytecode or VM instructions and custom VM runtime implementation for running the application.
I've been developing a pure Lua Web Server, you could always check it out and see if it suits your needs
Lua4Web https://github.com/schme16/Lua4Web
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I was just wondering about the opinions out there. What do you think promotes faster development times for a web application? Silverlight or .Net MVC?
And could Silverlight be a replacement for a true http web application?
Feel free to rant or give as much details as necessary.
could Silverlight be a true replacement for a true http web application?
No. Just as Flash can't, Silverlight and any other presentation viewing plugin will never be an acceptable replacement for good HTML.
I can cite a million reasons but here are the highlights:
Plugin-availability (especially on other platforms, phones, etc)
Performance is awful compared to HTML
Maintenance is a PITA, requires complete recompilation and uploading. You just edit what you need in HTML.
Accessibility!
I can't comment on speed but I frankly think it's irrelevant. You shouldn't use Silverlight/Flash/whatever to build a full website.
What technology to use depends completely of your requirements. You should start there.
As far as Silverlight (or Flash for that matter) goes, you will be creating a web application but not a web site.
Disadvantages?
People will be reluctant to install Flash or Silverlight plugin.
Flash/Silverlight sites will not be visible to search engines.
People won't be able to bookmark them and share the links.
Back/Forward/Reload browser buttons will not work
No/partial support in Mac world
Advantages?
Rich UI
My personal opinion is that you shouldn't use Flash/Silverlight except in cases where raw HTML/CSS won't work. And HTML 5 with CSS 3 are quite powerful. Web is full of pointless Flash sites which do nothing interactive just present a few static pieces of information. It could easily be done with ordinary pages. Somebody thought a Flash site was cool, but it isn't. It's heavy, slow and inaccessible.
Silverlight and MVC/ASP.NET both have there places:
MVC/ASP.NET are great for things things like blogs informational web sites, online stores
basically when your application needs to be spidered by search engines.
For online applications like Turbo Tax or Sales Force basically applications that at one time where on your desktop but for many reasons have been moved to the web I would use Silverlight or Flex.
With the above in mind:
Having worked with MVC/ASP.NET and Silverlight extensively I find Silverlight development much faster once you get the hang of xaml.
This is repeated many times, but I never seen anyone mention such disatvantage of the "modern" technologies like Flash/Silverlight as lack of years of browser/usability support:
you generally can't copy text of arbitrary item
you don't have things like Stylish, AdBlock, or Greasemonkey at your fingertips to improve what "designers" think is good for you
browsers doesn't know about your forms and can't provide autocompletion or save values after crash/reload
accessibility solutions like zoom methods or third-party formatters do not work
And I can continue. From users prospective, Flash/Silverlight is a nightmare, stone-age, while HTML-based applications have all the modern usability stuff available for users.
Yes, there're development problems (nothing beats FireBug even in HTML area) but what matters is, please, be kind to your users. Even corporate people are people.
IMO - I look at Silverlight/Flash/HTML forming the "View" part of the website/web application.
If you can structure you site/application code properly, the View should be interchangeable and/or can support multiple formats of the view for the end user/device to choose from.
IMO - it is very hard to predict the user usage patterns of the site/application and there might be devices which need to be supported in the future. So, might as well develop applications which are structured in a way to help make that move a lot simpler in the future, in which case the rendering of the view can be anything you want to meet your current goals...
HTH.
A previous answer makes the statement "You just edit what you need in HTML". While this is true for a simple static web site. It is not true for a web 'application' as is stated in the OP. The functionality is not in the HTML. You might have some functionality in Javascript that yhou could edit this way, but doing edit-in-production of Javascript is NOT recommended.
For all but the simplest static web sites I would recommend that any change to a production web site or application should be managed in an source versioning system, tested, and reviewed before deploying to production. In such an environment adding a compile step is trivial.
I would never recommend Silverlight to replace what could be done in a static website. I cannot imagine that anyone would. HTML is designed for static content. Silverlight is not.
To address the performance issue: the statement that Silverlight performance is awful is just wrong. Certainly, it takes longer to load a Silverlight application than to load a web page, but once loaded the user interaction of a well designed Silverlight application is much faster than continually rendering complete web pages.
The lack of portability for Silverlight has been significanly overstated in some of the responses here. Silverlight has the same capability on MAC that it does on PC. Linux availability via Moonlight is not far behind. MonoTouch for the iPhone, soon to come Mono support for the Android and the Silverlight programming environment for the upcoming Windows Phone 7 also bring a lot of possibilities for mobile environments.
Having said all of that, I would not use Silverlight to develop many types of web applications. I would be reluctant to do a consumer oriented e-commerce site using Silverlight (or Flash) because of the previously mentioned reluctance by some to download the runtime. But for the SaaS application that I am currently doing that is not an issue, the vast majority of users a more than willing to do a small download to get the far richer user interface.
It is possible to achieve some of the same improved user interface 'richness' by applying Ajax/JavaScript, but I find the Silverlight development experience to be more productive. One thing to consider is generally an Ajax/Javascript application while giving a better user experience than traditional web application will still look and feel like a web application and a Silverlight application will feel more like a traditional windows application. This may or may not be a factor in your decision.
I find it a bit disappointing that a repsonse that misses the point of the OP and does not seem to understand the difference between a web application and a web site has gotten more up votes than some answers that were on point.
The response by Anthony is spot on.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have been using Grails for the past few months and I really like it, specially GORM. However, I am getting interested into Scala's Lift. Therefore, I would like to know your opinion about which kind of web apps are better suited for which of those two frameworks or it is just a matter of taste, which framework to use?
Finally, which of those frameworks do you think will be more used in the future?
I have the feeling that Grails is far from reaching a critical mass and it still remains very obscure (in the past few months I had the opportunity to work with middle size companies and IT startups working mostly with the JVM stack and only one person knew and used Grails) and I am not even sure if it can become the "RoR" of the Java world (Indeed reports a drop of growth in the last few months even if other frameworks have a positive growing rate). And I love Groovy, it is really easy to learn but I have noticed how slow it can be for some tasks.
On the other hand, Scala seems to be more popular (Tiobe Index) and the fact that Twitter is using it now gave it even more presence in the blogosphere with lots of lovers and haters making buzz. It is famous for being fast and scalable. However, the language seems somewhat hard to understand and learn for lots of developers (so maybe it will never gain mainstream status). Lift is little known and I have read some reports that it is better suited for small apps (less than 20 domain classes).
By seeing the number of books published Groovy-Grails dominate right now, but many publishers have Scala books on the works, so I think this advantage will not last long.
Finally, we have the problem that both languages and frameworks still have poor IDE support (it is getting better by the day but far away from what Java shops expect to be productive).
I do not want to start a flame wars, but I would be very interested to hear other users' opinions.
The accepted answer here takes a really ignorant view on Groovy - it is a modern, dynamic language (dynamic vs. static is a huge debate in and of itself, and not particularly relevant here). This is by design, and therefore not a disadvantage, just a difference. It has a lot of modern language features that Java does not have such as closures, native regexp, polymorphic iteration, some optional static typing (matter of debate, but also look at groovy++), native syntax for lists and maps, etc.- you can see a comparison here http://groovy.codehaus.org/Differences+from+Java
To address the actual question of Grails vs. Lift, I'd say Grails hands-down. It has the SpringSource behind it, and just look at the plugins page http://www.grails.org/plugin/category/all - I can't even find what plugins or equivalent are available for Lift. Grails is also on top of the latest cloud-friendly technologies, with features like native RabbitMQ messaging support, and turnkey GORM support for MongoDB and Redis.
Grails is a nice idea(but only "stolen" from rails) but the fact that the groovy guys are not interested in getting proper Eclipse support is hindering it's success a lot. I've even seen Eclipse questions not being answered at all on the grails lists.
I agree with Tim that Netbeans 6.7 finally delivers the first half way usable Open Source IDE support for groovy/grails - and eventually, SpringIDE will also feature better groovy/grails support.
The reason many Java folks love Java is the static typing, which enables tools to help you a lot with many things. This is lost with a language as groovy.
Yes, I could write every really important piece of Code in Java and still use Grails - but then, why should I, just to save a bunch of lines of glue code, do that instead of learning to use a Java framework highly effectively?
To come to an end: I did not yet look at scala, but built some simple apps with grails - and I tend to go back to java, even reimplementing every app that needs further development in a plain Java framework - I think wicket and Seam.
I'll also look at Scala/Lift, I heard many good things about it!
BTW: I'd compare communities and look at mailing lists - how many peope are there, do they get good answers on their important questions?
Grails seems to have a non-answered rate from nearly 50%, which I feel is bad.
Grails support in netbeans 6.7 is really good, as well as the idea intellij support in Maia.
Eclipse is still pretty sucky.
I looked at lift, but was concerned about the resources available now; this will change in the future, but my projects can't wait.
I would like to specifically answer the question "for which kind of applications". The main difference between the philosophies of Grails and Lift seems to be that Grails enforces MVC whereas Lift seems to be more liberal i.e. it doesn't enforce MVC but provides enough avenues to use MVC if you want to.
Also Lift seems to be excellent for 'Single-Page Applications', especially if you need to implement a server-push functionality using technology like Comet (which obviously doesn't imply it's not good for other types of applications). On the other hand, Grails seems to be better for the 'Enterprisy' applications, especially if you are already familiar with Spring and Hibernate but want your app to be much more concise (using Convention over Configuration) than what a non-Grails app would be using these technologies.
References:
Simply Lift, chapter 13
Single-Page Application
Disclaimer:
I have just started exploring Lift and built some simple apps using Grails.
With all the performance improvements and advancements of Grails2.0, with great support provided by IntelliJ 11 for the framework, an ability to plugin pretty much any advanced web technology into your grails app., and yes - VMware weight behind it - I really don't see how Lift could be an advantage or a good choice. Just think of using two different languages in the same application, need for double expertise in the team, etc.
The original question has been posted like 2+ years ago and I think time showed on which side is the choice of the dev community ;)