On 20.09.2006, at 13:36, Gustaf Neumann wrote:
just my 2 cents...
Very valuable insights from (obvious) experience ... Look at for example our case... We have 3 people VERY good at C and "low-level" programming (including kernel-level drivers). We have one guy pretty experienced in Web GUI development. We need to have at least one or two more in that area. So, basically, good knowledge of HTML, XML and CSS are absolute prerequisites. But, we need to create server-side pages. That is, you need to add the Tcl, as there is nothing in Naviserver that you can use instead. Mostly, people having written some "home-page"-kind of apps (if you can call this application at all) HAVE some experience in Javascript. Because more and more functionality will be done in JS (client-side) you need to have those people learn JS pretty good and this is what they will do. Now, why not piggybacking on that and give them the tools to employ their knowledge on the server-side as well? They need not write async code nor concurrent MT-code. For that we have libraries either in Tcl or (mostly) in C written by a. people (see below). In the near future, most of the Web-applications will be even more (heavily) based on JS then they are now. So people will invest more and more in that area. Why not take advantage of that? I believe one thing that we've isolated so far is: a. To write serves-side code (libraries, complex logic, etc) we will mostly stay with Tcl and C as I know this is unbeatable combination. Years and years of experience have thought me so. b. To write dynamic HTML pages to produce a client-based "application" will (always) be the case of mixing HTML/CSS/JS hence by using JS both server and client side simplifies the task of the programmer. He/she, after all, has already enough to do in order to mix JS with HTML/CSS. Adding something else (Tcl, PHP, whatever) was out of the necessity (historical reasons) and not out of the design reasons. To find people doing a. is very hard. But when you find them, then the language question is secondary. They already have enough experience to learn and be productive quickly given XYZ tool. This is NOT the audience I'm talking about. To find people doing b. is simpler. But as they do NOT have that extensive programming background, you can't expect from them to learn 4 different languages (HTML/CSS/JS/TCL) to write a web-based application. Even HTML/CSS/JS is pretty enough for them. By having the server-side pendant of JS just simplifies things for b. people. So, it is the b. I'm talking about. I'd like to make the burden of working with NS lower by adding alternative language to compose dynamic pages.
