Take a look at Google Web Toolkit. The default model is to use Java (not JavaScript; Java is translated into JS for the client side) both one the client and the server side. But if you are not happy with this model, you can of course use a different language/runtime on the server (such as Perl, C# or C++). As I said before, it is not a panacea, but a nice model IMO.
Indeed GWT is not a panacea. But it can definitely be called a general-purpose programming environment for client/server applications, with the client running as a browser application on a broad base of browsers without any browser-specific coding required. It is also true that because it is general-purpose, the programmer must create "data-bindings" from widgets to database tables explicitly, if his application requires this. But how should it be done differently, if GWT is supposed to be the basis of Google Mail, Google Office applications and any other application one can think of running inside a browser ? GWT is not just a database-based framework, but a very generic widget-based programming infrastructure from which programmers can build whatever they can think of.
..you can write a web app in assembly language. It will just be more time-consuming do develop than using perl, C#, Java, GWT or similar technologies. It will probably be much smaller in memory footprint and much faster in execution perfomance, though. I guess the number of security problems will also be higher with assembly language, similar to using C.
Google Web Toolkit allows you to create nice web client applications without any significant knowledge of HTML or CSS. Instead, you have to know the GWT Java classes (not JavaScript; it gets translated into that automagically). I used it in a real project and had to deal with CSS only to make it "nice to see".
Slashdot Mirror
My Linux machine is well-protected and I don't need your meddling nor do I need Microsoft's.
Take a look at Google Web Toolkit. The default model is to use Java (not JavaScript; Java is translated into JS for the client side) both one the client and the server side. But if you are not happy with this model, you can of course use a different language/runtime on the server (such as Perl, C# or C++). As I said before, it is not a panacea, but a nice model IMO.
Indeed GWT is not a panacea. But it can definitely be called a general-purpose programming environment for client/server applications, with the client running as a browser application on a broad base of browsers without any browser-specific coding required. It is also true that because it is general-purpose, the programmer must create "data-bindings" from widgets to database tables explicitly, if his application requires this. But how should it be done differently, if GWT is supposed to be the basis of Google Mail, Google Office applications and any other application one can think of running inside a browser ? GWT is not just a database-based framework, but a very generic widget-based programming infrastructure from which programmers can build whatever they can think of.
..you can write a web app in assembly language. It will just be more time-consuming do develop than using perl, C#, Java, GWT or similar technologies. It will probably be much smaller in memory footprint and much faster in execution perfomance, though. I guess the number of security problems will also be higher with assembly language, similar to using C.
..either. Retry your argument.
Google Web Toolkit allows you to create nice web client applications without any significant knowledge of HTML or CSS. Instead, you have to know the GWT Java classes (not JavaScript; it gets translated into that automagically). I used it in a real project and had to deal with CSS only to make it "nice to see".