Well said, as usual. T.
> On Mon, Aug 2, 2010 at 14:58, Petr KobalÃÄ�ek > <[email protected]>wrote: > >> Hi, >> >> do you think that javascript is a good language to use it on >> server-side? >> For me it's worst language I ever worked with, but there is no other I >> can >> use to write multibrowser web-pages / web-apps. >> > > Different strokes for different folks. Having used many languages over the > past 1/4 century, JavaScript is currently my favorite of any I've ever > used. > > >> Javascript is singlethreaded language, > > > Good. Threads are a debugging and maintenance nightmare. Been there, done > that. I recommend against using them for nearly all applications. (They do > have appropriate uses; I just feel they're way overused when it is > inappropriate, and many developers who attempt to use them don't have the > skill set to do so properly.) There are better mechanisms to use in most > cases: heavy-weight processes if they're not fired up too frequently; an > event loop (often a great solution); etc. > > >> performance/memory footprint is problem, > > > Performance, possibly. With the latest JIT JavaScript interpreters, I'm > not > even sure if that's much of an issue any longer. Memory footprint is not > an > issue in anything but embedded systems (memory is practically free, and > computers come with lots of it), and even in the embedded environment I'd > have to do some experimenting to see whether the memory footprint really > greatly exceeds (or exceeds to an untenable extent) the footprint of a > compiled application. > > >> it's not type-safe > > > Type-safe is highly over-rated. Types were necessary in early compiled > languages in order to tell the compiler how to allocate memory. Types do > allow hints to be given to the developer when something bad is assigned, > but > I think the flexibility of, for example, storing numbers in some elements > of > an array and strings or even object references in other elements far > outweigh the benefits of rigid types. > > >> and there are no libraries. > > > That will likely change soon. In the interim, as with PHP, C libraries can > likely be linked in to provide external functionality. > > >> Personally I can't understand why to use qooxdoo on server side, what >> you >> gain? Using oo model, > > > My biggest problem with JavaScript as a language is its non-standard > prototype-based object model. qooxdoo has pretty much fixed that, giving > it > a similar object model to other current and common languages. > > >> Using dom or widgets, what is it good for? > > > Nothing. They likely have nothing to do with server-side JavaScript > programming. > > I respect your opinion, and I believe it's a fairly common opinion. I also > see an evolution to a different (better, IMO) paradigm for many > applications, and JavaScript on the server is part of that evolution. > > Derrell > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm_______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
