Bob Balaban's Blog

     
    alt

    Bob Balaban

     

    What if....."JavaScript" is inevitable?

    Bob Balaban  June 19 2007 08:35:51 AM
    Greetings, Geeks!  

    I hope that all of you in the Northern Hemisphere are enjoying the onset of Summer, and that all of you in the Southern Hemisphere are enjoying the prospect of cooler times. I hope that all of you in between are....well, finding something to enjoy!

    So! *Everyone* who knows me knows that I am a BIG fan of LotusScript, and that I have a very long history with it. I have taken every opportunity at every conference I have spoken at in the last 10 years (and that's a LOT of conferences), and in most of the articles I have written to point out (sometimes with the help of a great Monty Python video clip from the "Holy Grail" film) that LotusScript is NOT DEAD (yet). That is STILL TRUE today.

    The back-end classes for LotusScript (and Java, and COM and CORBA) continue to be improved and extended. The LotusScript front-end classes work just fine in the Notes 8/Hannover client. I will have more to say on the topic of back- and front-end classes and on improvements to LotusScript itself in a future post, but for now there's no way this stuff is going to disappear anytime soon.

    Having said that, my major focus for 8.5 (NMFR - "next major feature release") is on Web application development (I'm not ignoring Notes appdev or anything else, but this is a strategic thing for 8.5 NMFR). Anyone doing web development on Domino knows that this area needs some work to be great again (dare I say, "kick-ass"?). LotusScript will continue to play an important role in Domino Web appdev, in the form of WQO/WQS agents, as before. However, LotusScript has one rather large drawback in this space: it does not run in browsers.

    It seems clear to me (please tell me if you disagree) that:
      a) We need to be putting code on browser clients to make the user experience and the data transfer good
      b) Nobody wants to use Java applets for this purpose anymore
      c) IBM is not going to hand control of its technology future in this space over to someone else's "custom player" (e.g., Flash, Dreamweaver, some Microsoft thing...)
      d) We're left with the inevitability of JavaScript, in some form.

    So, fellow Geeks, here are some questions on which I would like to get your feedback:

      1) Is "JavaScript" generic enough these days that we don't need to care much about what flavor of it is running in given browser?
      2) If we have to pick a version of "JavaScript" on which to standardize, what should it be? ECMAScript? Something else? What are the tradeoffs?
      3) Of course, JavaScript by itself is probably no longer good enough. It seems to me that people (developers) are expecting some kind of browser-resident framework to handle the low-level tasks involved with AJAX, rendering, XML processing, and so on. If IBM picked one to be our "default", but still let you deploy whatever other one you wanted, is that ok? (If you didn't use the one we provide, my assumption is you would likely have to do some extra coding)

    Is there more we should do to "embrace" JavaScript? Is server-side scripting in JS a requirement? If so, what are you likely to do with it?

    As always, dear Geeks, thank you for your dedication and feedback!
    Comments

    1russ radkiewicz  6/19/2007 1:29:35 PM  What if..... JavaScript is inevitable?

    Notes has classes for LotusScript and Java . . . why not have classes for JavaScript!!

    For those of us who don't want to spend the the time to learn/use the DOM, it would be nice to have pre-built classes that simulate the LotusScript classes.

    Just an old mans dream.

    rr

    2Rob McDonagh  6/19/2007 1:47:07 PM  What if..... JavaScript is inevitable?

    Just don't pick Dojo as the default. Man, talk about a pig. That library is the biggest waste of bandwidth ever developed. Please pick a default that doesn't assume all our users have a dedicated T3 to the desktop, ok? Dojo is to Javascript development what the Java applets have been to Domino web development since R5: so bloated that anyone interested in real web development will write articles telling developers to avoid it like the plague. If IBM chooses Dojo, and I expect them to, I will officially declare Domino web development dead (not that anyone will care what I say on the subject, but you get my drift).

    3Joe Litton  6/19/2007 2:07:50 PM  What if..... JavaScript is inevitable?

    Emulating the LS classes would be wonderful.

    Many of us have been incorporating editors like FCKEditor into Domino apps to let users format text without the weight of the applet. If that's not already being considered, please add it to the list.

    I've stolen some brilliant code from Scott Good and others for AJAX in Domino ...still takes a bit of work to get things operating nicely in custom views (pagination, indentation of responses, etc). Tools to manage AJAX functionality would be great ...sort of the way Property Broker Editor shields folks from editing the raw WSDL for composite apps.

    Gosh, and just to deviate for a moment to the Notes client side ...implementing more JavaScript in the rich client would be sweet ......long as I'm dreaming :)

    4Larsson  6/19/2007 2:09:47 PM  What if..... JavaScript is inevitable?

    Follow the stream! stick to the "de facto standards" such as prototype, scriptaculuos (or whatever framework). Even if IBM is making it's own "plugin" it will probably end up like the Applets did in Domino, just because it's heavy to maintain and then gets obsolete over time.

    On the client-side there is a tremendous development of opensource modules depending on these frameworks and it's not going to slow down.

    This makes the Serverside and the communication to it more interesting.

    5Tim Tripcony  6/19/2007 2:22:34 PM  What if..... JavaScript is inevitable?

    Developers are going to expect a fair amount of encapsulation; that's the goal of Ext.nd: make it "easy" to leverage the strengths of Domino from within a browser. In my opinion, one of the primary advantages of any JavaScript framework is the encapsulation of browser quirks, which are still quite rampant. Any JavaScript written without leveraging a framework still needs to account for CSS variations, ActiveX vs. XMLHttpRequest, etc. The best frameworks (Ext, YUI, mootools, Dojo) wrap those variances in layers that shield the developer from having to remember how each specific browser needs to be coddled to achieve the desired result.

    Each framework, however, has its tradeoffs. As Rob mentioned, Dojo is enormous. It's also a pain to work with. That's why fans of Ext love it: it's just so darn easy to use. But at the same time, it's incredibly powerful and extensible (the latter being the whole idea behind its creation). Ext.nd takes advantage of both advantages by providing an API that "feels" similar to LotusScript. IBM has taken a similar approach to the Java classes in Domino: with the exception of the UI classes, each LotusScript class has its Java equivalent, with similar properties and methods in each. I'd love to see them do the same with JavaScript, providing fledgling web developers the same API they have now, just in a different context and language. They'll still need to learn the syntactical differences, and to develop anything particularly powerful they'll need to probe the strengths of the language, but being able to start with code that feels familiar should lower the learning curve dramatically.

    P.S. Stay far, far away from Protaculous (Prototype and Script.aculo.us): functionally they're sound, do a decent job at browser quirk encapsulation, and are easy to use, but syntactically they're a mess. They leave out curly braces and semicolons all over the place, trusting to the browser's auto-insertion to know where those characters should go. Additionally, their structure relies on an abundance of global functions and variables instead of using layered namespacing. Both of these approaches can cause significant runtime performance issues, which is bad enough, but they also encourage bad habits in developers using them as a "role model" for how to write JavaScript... in my opinion, that's even worse.

    6Dan Sickles  6/19/2007 2:30:37 PM  What if..... JavaScript is inevitable?

    Are you thinking of using the existing jvm javascript from LCD or building/adapting a native javascript? As for which version, go for javascript 2 (ECMAScript 4):

    { Link }

    { Link }

    Server side? I don't see why not. Sure beats Lotusscript (in it's present state).

    7Mike VandeVelde  6/19/2007 3:01:06 PM  What if..... JavaScript is inevitable?

    Has anyone out there written say a NotesDocument object in JavaScript? How would that work exactly, living in the browser? A bunch of XMLHTTPRequests that fill in all the properties onload? Or as used? Could be interesting...

    A default JavaScript framework built in might be handy to get people pounding out prototypes rapidly, but do you really have to do anything to let us choose our own frameworks? We can dump into an nsf all the JavaScript libraries we care to get our hands on right now can't we? What exactly do you see building to make that easier? *A proper JavaScript function browser?* **A proper class browser for JavaScript and LotusScript?!** But won't all that come by default with an Eclipse based Domino Designer, plus colour coded HTML? I'm not really sure what you are offering here?

    a) Yes.

    b) Not especially.

    c) Please don't!!!

    d) Pretty much.

    Server Side JavaScript - read about that here and there, but realized it wasn't available with Domino so didn't get too deep into it, that's where you could get interesting...

    8Viktor Krantz  6/19/2007 3:29:58 PM  What if..... JavaScript is inevitable?

    In my opinion Dojo has always had the most potential of all the frameworks. I agree that it's been giant, a bit clumsy and difficult to work with. But the .9 release is shaping up and nobody is coming close to addressing all the issues that Dojo has taken on. With big investments in internationalization (I18N) and localization (L10N) and the fact that IBM is already a big contributor make Dojo the natural choice to me.

    9Nathan T. Freeman  6/19/2007 4:15:44 PM  What if..... JavaScript is inevitable?

    A) Don't lock us to one JavaScript framework. That would be a gigantic mistake.

    B) IBM already has a JavaScript framework deployed on every Domino 7 server. Nobody ever talks about it. But the DOM Foundation Classes in dfc/dfc100.nsf on your Domino 7 server is a pretty powerful library set that's used for the excellent Domino Web Administrator.

    C) I'm not sure that any generic library is even directly applicable. As Ext.ND demonstrates quite well, there's a major amount of work that goes into turning the data API results from ?ReadEntries into a proper data grid.

    10Robert  6/19/2007 4:20:54 PM  What if..... JavaScript is inevitable?

    First, to use JavaScript in the browser very well, you'll have to clean up and enhance the HTML markup generated by the Domino server. Generate IDs for every label and field in a predictable way (perhaps the tag for an input field would be the name of the field). Use CSS instead of embedding the style in the HTML.

    Second, everywhere there's a Java applet option ("Use applet in the browser") replace or add an equivalent JavaScript option.

    Third, when I write an input validation formula or an input translation formula, generate the correct JavaScript to do this in the browser.

    Fourth, make the "Refresh fields on keyword change" use AJAX to do the refresh instead of a page load.

    If you did these four things I think you'd have to have adopted a framework we could all use.

    Oh and fifth, publish all the code and explain the inner workings so we can extend and change things without having to reverse engineer the code (like we did for _doClick).

    I love my Notes!

    Rob

    11Sean Burgess  6/19/2007 4:38:22 PM  What if..... JavaScript is inevitable?

    If I were in charge of adding a JS framework to Domino, I would want it to help me do what Notes does great already. As an APPLICATION DEVELOPER, I really don't care as much about making my logo flame or spin, but rather I care about making an app that my users don't hate using.

    - Don't make me have to know what kind of field it is (radio vs select vs regular) to determine whether or not it is empty.

    - Give me easy JS replacements for @Failure, @Unique, and @Sort.

    - Give me JS widgets for date and time entry.

    - Give me an EASY way to make my drop down lists dynamic, changing the choices based on other values in the document.

    - And, for the love of Notes, please allow me to click a checkbox to make a field display as a text area instead of having to make it a multivalue field. (I know it's not a JS issue, but it irks me none the less)

    My hope is that you would take the strengths of the Notes environment and bring them to the web via JavaScript. Taking that approach for 8.5 should make it a winner.

    12Jason Dodds  6/19/2007 4:49:27 PM  What if..... JavaScript is inevitable?

    I agree that IBM settling in on one JS framework is not necessarily a good thing, but I do think it would be a good idea for IBM to support open source code/libraries that help out the Domino user base. I mention this with regards to the Ext/Ext.nd platform and it's future role in domino web development. Most of the work by contributors to these two projects is done on their own free time and without compensation (apart from making the domino world a better place). Would IBM consider funding a few of these talented individuals for a few months so Ext 2.0 and Ext.nd can get to a production level? I think it would take a minimal investment from Big Blue and it would finally give us developers something to sing with regards to web dev in domino.

    13Benoit de TARADE  6/19/2007 4:51:34 PM  What if..... JavaScript is inevitable?

    In MY opinion, Ext.nd have the best potential due to reasons why it is born.

    Ext.nd is a Domino framework, before beeing a Javascript framework.

    So why, I think it's a good START to throw a eye in this way.

    However, to answer your asking "what are you likely to do with it?";

    "All we can do whith LS", I say.

    YUI provide a good "Theater" about users needs. More and more customers provide use a VB or Access app, and ask use to provide web apps with same capabilities. (drag/drop, MDI, tree, dialog, etc...)

    Providing a JS Framework did'nt imply we are forced to use it. WSAD provide Struts capabilities, but you are not forced to use it. We are not forced to start http task.

    Also, all current framework need to send many request to get all js and css. Providing one js and one css could improve loading perf.

    Best regards

    14Zak Karachiwala  6/19/2007 10:19:52 PM  What if..... JavaScript is inevitable?

    I myself am using Ext but I think a platform independent approach would be best. Tying Domino down to a particular framework may limit it in the future. Look at how domino was tied to a particular Java implementation because of its integration.

    Instead what should be looked at is the commonalities that all these frameworks provide. What can Domino do to make using these frameworks easier.

    Things such as a better output format for views instead of the cumbersome readviewentries. The ability to generate XML /JSON directly from search results. The ability to tag all domino generated design elements with DOM IDs (action bar table, view table etc). All these would make things much easier to work with.

    15Roland Reddekop  6/19/2007 10:38:08 PM  Javascript Framework Wars

    *Warning* Dojo-biased reality check follows.

    It doesn't take a genius to understand that a JS framework, and probably a fairly heavy one, is required to give Notes Devs the same functionality they are used to in NotesWorld (@Functions, LS, etc.) in the WebWorld. Hence, since this is generally understood, we are clearly seeing many parties subtly and not so subtly seeking to influence direction and "positioning" their favourite JS library as the basis that IBM could simply "extend" into the next release of the product. Clearly, evidence suggests that Dojo IS already the frontrunner and its not likely this will change: IBM has invested in the organization both financially and with their braintrust. Futher they are releasing a strategic product that leverages it within the next 10 days (Quickr). Not having any particular stake in any one JS library, I am quite happy to start learning Dojo (don't ask me where to start) and not be pulled in different directions. Maybe its not the perfect library (or so I am told), but we need Standards, we need consolidation of effort and resources into a shared programming model so the Domino community can rally together and teach each other how to make great apps. Sure, not forcing anyone into a particular library is fine and I don't believe Bob is suggesting that any library will be forced upon anyone. Example: Nobody MUST use the Notes supplied Java applets on the web. Just as you can program today in Notes and into the future using any library you choose (just import it or place it into the HTML directory and program away). However, incorporating a good and extensible library natively into the Notes/Domino IDE, similar to how they did for the Java applets is a good thing, only this time the technology is better. For example, if you drop a date field onto a form, who wouldn't want a simple option like "check here to make this date field show up using a Dojo widget on the web"? Do you have to use the Dojo widget? No, of course not. The more sophisticated programmers will probably "roll their own" anyway and use a class or ID attribute to link the field to a library they are more comfortable with. But having a base-library for the beginner to intermediate programmer to easily use is a fantastic idea.

    16Andrew Price  6/19/2007 11:23:59 PM  What if..... JavaScript is inevitable?

    a) Yes

    b) AGREED!!!, java applets (in general) suck

    c) Understandable

    d) Agreed

    1) Yes. If it runs on latest versions of FF & IE I think that is all anyway cares deeply about (ok, ok Opera and Safari too).

    2) I think you should stick to a subset that ensures compatibility (I don't know enough to know what this results in I'm afraid).

    3) What you say makes sense, obviously since this will be a somewhat 'Notes like' experience that people are expecting to produce that talks to an NSF-is-default backend I expect people would like a Notes-ish interaction between client and server.

    I think ability to plug into a variety of tools is key, but I would suggest that simplicity of adoption is vastly more important than comprehensiveness, provided as I say, it comes with easy interaction with other things.

    Thus (judging only from comments above) Dojo sounds LESS like a good solution than ext.nd (I know neither).

    I have to say I am a big Google fan and really like the work they have done (and OPEN-SOURCED) especially google gears. This being another company's project might be mitigated by the OS aspect I hope. I suspect that developers will have ever DECREASING tolerance of closed source tools.

    HTH. Everything you are saying sounds really encouraging Bob. Nice work.

    Andy

    17Dietrich Willing  6/20/2007 12:08:14 AM  What if..... JavaScript is inevitable?

    I don't mind which Javascript framework is the default. But it must be easy to update it or swap it for another.

    It would be preferable that it apply at the server level with the capacity to exclude specified databases. For companies that use developers with different capabilities or where a database is sold, having the capacity to use different frameworks (in different databases) on the same server provides flexibility that would be appreciated.

    I agree with the requirements as set out by @Robert and @Sean Burgess. I think some of the items could be produced by IBM's programmers using the default javascript framework (eg widgets for date and time entry) while others need Domino changes (eg replace "Refresh fields on keyword change" with Ajax).

    Are the browsers generic enough? If the server produces standards compliant XHTML they are.

    18Wild Bill  6/20/2007 3:35:06 AM  All of the above

    Yup. In a framework. And possibly able to be inserted in other frameworks. Documented so it could be extended. Fast.

    Everything really.

    ;-)

    ---* Bill

    19Dwight Wilbanks  6/20/2007 4:45:21 AM  What if..... JavaScript is inevitable?

    >>Is there more we should do to "embrace" JavaScript?

    The "embracing" that has been done so far for domino has been around "sexy". Don't get me wrong, sexy is important, but, notes/domino has a dual path development model, there are things that you have to do to the notes client that have no impact on the web and visa versa, except by the nature of the complicated work arounds sometimes needed often time uninteneded consequences get in the way.

    I can't stress enough, Im all in favor of sexy dhtml/axax frameworks, but, at its core when a company hires on a college grad to do lotus work, what technologies are required to be proficient day one.

    Well you can't work without formula language, thats a given.

    Its hard to get away from lotusscript, its pretty essential for backend processing and sometime client UI

    Some would claim that Java knowledge is a must, I would agree for non-microsoft shops you pretty much have to use Java, because all other OS's don't include the MS ActiveX objects

    Now you want to do web work, for web, strong javascript knowledge is required.

    Lotusscript and Java have very similar backend classes, so, you can leverage knowlege of one language to learn the other, but, thats where it stops. Formula language and JS are completly unique in how they accomplish things. Requiring developer knowlege and experiance.

    I was truely excited to see the javascript event object on the notes field UI, I was excited until I tried to use them. Without a debugger or any clue what type of object model IBM implemented. I was especially tickled by the corrected spelling of "referrer" on the document object, which indicates to me that spelling is more important than usability. I personally like the wrong spelling and "referer" spelled how it is, has a defined meaning.

    As of this writing the IrisJSConsole (which is an exposed property of the window object in the notes D.O.M.) is competely undocumented, nobody even asking questions about it

    http://www.google.com/search?q=IrisJSConsole

    http://www.ibm.com/Search/?q=IrisJSConsole

    http://www-12.lotus.com/ldd/doc/domino_notes/7.0/help7_designer.nsf/(help)?searchview&Query=IrisJSConsole

    As of this writing each of those searches came back with zero results.

    Upon a deaper search I found one page:

    http://www-10.lotus.com/ldd/__00256C3E0030650D.nsf/0/677BEA20980E0F8785256D4200452FF3?Open&Highlight=0,IrisJSConsole

    I think of what I actually use client site formula language for:

    if you entered a value here, then you must enter a value there,

    trim,

    if not blank

    does the value that you entered exist in some specified view (or not exist), etc.

    For the most part,, If there was a single programming language for the web and for the notes client, I would choose that language on new projects (assuming it worked mimimally well), I would even choose it if there were some drawbacks or shortcomings.

    >>Is server-side scripting in JS a requirement?

    From a code flow persective Java & LotusScript do little more than tie together the notes backend classes, its those classes that do the real work,

    JS also could tie together the backend classes equally well. The language is every bit capable enough manipulate the backend classess and control flow,

    I think there is a significant advantage to the small/medium size company that may not even have a dedicated notes developer, Notes is getting (has gotten?) too complicated for entry level developers.

    Another advantage of server side JS is running the exact validation code on the backend as was run on the web client. Since actions taken on the front end can be forged very easily, validation still needs to happen on the server too, but, dont make us implement the same code twice in 2 different langages the way that we have been.

    >>If so, what are you likely to do with it?

    I would probably use a robust full featured JS server agent engine, with solid integration into the backend classes as my primary language.

    LotusScript is not dead, but, we still don't have a class editor. (we do however have promises now, thats new!)

    >>ECMAScript? Something else? What are the tradeoffs?

    Im not sure technically whats the difference between variations, but, at least a subset needs to be 100% syntax compatible with the web browsers. Thats the key question to me.

    20Michael Bourak  6/20/2007 4:55:52 AM  What if..... JavaScript is inevitable?

    Do not forget that, to design accessible (w3c way) web site, they need to work without javascript. So please, do not "couple" the new html rendering stuff with the new javascript stuff cause, for now, to be able to design an accessible site in domino, you MUST uncheck the database properties "use javascript..."

    And I'm not sure we need a way to have the Domino api in JS. We much more need "stronger" server side scripting (agents beeing as fast as servlets, ability to have "session" to store objects etc, ability to cache data as in websphere dynacache/domino command cache). This plus a rest API and developers will have all we need to design web app (I mean, don't spend all the effort in recreating the LS access to the API in JS, but better provide us for way to do it and spend time on improving the core domino web engine).

    PS : I agree about Dojo, seems very very big so please do not make the use of such a pig a requierement.

    Thanks.

    21John Foldager  6/20/2007 7:31:25 AM  What if..... JavaScript is inevitable?

    @14, @20

    I think that Zak and Michael has the strongest arguments here. Don't tie us to Dojo, Ext (or even Ext.nd). Just make Domino faster and better in generating JSON and XML content -- then leave the browser UI up to us.

    As far as server-side JavaScript scripting I - for one - could really use this! I've already created a framework running at a couple of customer sites that actually runs on the Domino server using a Java agent and Mozilla Rhino ({ Link } ) which runs great. Why? Because the customers can use a standard language [JavaScript] to create libraries of functionalities that can run in the browser [client] as well as the server and even have access to the same Java API's as a normal Java agent [server side that is].

    22Michel Van der Meiren  6/20/2007 7:47:16 AM  What if..... JavaScript is inevitable?

    I've been programming JavaScript and Domino for over 10 years now. The only thing that Domino lacks at present: control over the HTML for error messages and search. Please don't go with the flow: existing Ajax libraries are your worst nightmare, mainly because of their footprint. Using only out-of-the-box JavaScript allows you to build a much lighter framework for Domino. I agree with Sean Burgess (comment no 11). All you need is just a few simple functions and widgets. Make your pages load under 0.5 seconds!

    23Baiju Thomas  6/20/2007 8:19:54 AM  What if..... JavaScript is inevitable?

    @20 Michael - I fully agree with you. Creating an LS equivalent in JS would not help as the run time environment is different. Also a big no to the dependancy on any frame work available today. Some of the things we need as web developers -

    -AJAX enabled fields to avoid form refresh

    -Automatic calendar widget for date fields

    -Professional looking view rendering(views should not look like "views". They should look like data grids - look and feel controlled by CSS)

    - Client side sorting option for view columns(without form refresh and without the need to have the back end view to have all types of sorting)

    -Better looking view navigation (With page numbers, previous, next etc)

    -Better use of CSS by domino web engine rather than generating lot of HTML tags

    -Option to render a categorized view as a tree control without browser refresh

    -JS/CSS controlled Professional looking Tabbed tables

    -An id generated for each field

    -An AJAX enabled name picker widget - (customizable so that it can be used with any view from any database)

    -Ability to customize the look and feel of all the domino generated widgets using style sheets

    -Ability to add validations to fields that work in the browser

    We do all these things in our applications. But if domino can automatically generate them for us it would be great.

    Also the HTML footprint should be kept as minimum as possible.

    24Brian Miller  6/20/2007 9:48:59 AM  What if..... JavaScript is inevitable?

    I still think that Dojo is a bad idea.

    My feeling is that IBM should write their own JS "Framework", and ship it with Domino. In a way, this has already been done with the Web Administrator and Webmail/iNotes.

    Anyway, this is what the JS *should* do:

    In the designer, give us some options with each element (field, view, tabbed table, name selector, etc.) to use a "vanilla" version, a "better" version (referring back to a previous discussion here about generating better HTML rendering), and an "advanced" version, which uses javascript to enhance/animate the UI component in the browser.

    Advantages:

    * Developers get to click a radio button, and just have their element "work" on the web.

    * Changes to the JS can be pinned to the releases of Domino. If you use any of the third-party OS frameworks, you're going to have the exact same problem that Domino has with the JVM today - it's perpetually a version behind.

    * IBM will have the opportunity to use JS to solve specific problems related to the rendering of Domino elements in the browser, while being able to keep the code clean, efficient, and small.

    * IBM can take ideas from the best parts of the existing frameworks, and combine them to get the best system possible. (e.g. jQuery's DOM selection, the good widgets from YUI/Dojo/Ext/Mootools, some of the intuitive and helpful convenience objects from Prototype or Mochikit, etc.)

    I'm in agreement with Baiju's (@20) basic ideas. Solve specific problems that will make developers happy. Provide an instant date and time picker for web apps, or a Web-2.0-style name picker, without requiring anything besides selecting the appropriate option in Designer. Trust me, it will be easier if IBM builds these things from scratch.

    25mdm-adph  6/20/2007 10:24:16 AM  What if..... JavaScript is inevitable?

    While I personally believe that Ext ({ Link } ) and Ext.nd work wonderfully with Notes/Domino -- never before have I seen a JS library so easily integrated into Notes on the web -- I second the calls to not tie developers down to any one framework.

    JavaScript has been largely standardized today (compared to 6-7 years ago), but don't worry too much about that -- the community will take care of that with various JS libraries such as Ext and jQuery.

    26Richard Collette  6/20/2007 12:27:15 PM  Developing our own ui components

    The problem here, is not that we do not have a framework. Adding the framework to the app is the easy part. And as you can see, everyone has their favorite framework, so choice is necessary. The problem here is that we do not have the ability to extend the Lotus components (fields, etc.) in a reusable manner that integrates with a graphical form design environment. This is already possible in both Java (JSF) and .NET and I can't see IBM putting resources to good use trying to reinvent the wheel.

    What is required is the ability for these AJAX frameworks to also include the GUI component/widget that works with Domino. So, lets say Lotus provides a base set of standard JSF/.NET web components. The ext.nd group should be able to extend those components to work with ext.nd. The designer can then drop the ext.nd jsf components onto their form design the same way the base components can be dropped on. In my shop, we might want to further extend the ext.nd/JSF component to suit our needs and we should be able to do that in a reusable manner as well.

    Using something like JSF is possible today. The barrier to wide usage has been that it has to be done outside of the Notes design/data (notice that I am not saying doing it outside the IDE is a barrier). The form you develop then does not replicate with the data, it does not necessarily run on the client (well maybe with expediter but there it requires additional code to be aware of connection status). In the end, you've lost a good portion of Domino's capabilities.

    Years ago when workplace was first brought up, the notion was that Domino was going to transform into a service platform. Think replication, calendaring, data and design storage, security. While it scarred everyone else, it is a sound concept. Now, we are instead seeing a focus on trying to "fix the ide", develop new languages (think LCD @ formulas), etc. and the focus has been lost on the value IBM was delivering in the first place, the services.

    I keep saying this. IBM should focus on delivering a standards based (.NET being a defacto standard) service platform that plugs into the great development environments that are already out there. Let me replicate my design, configuration and data between servers and clients with the same ease that I can in Notes. Allow me to work with data in a rapid development manner(easily binding fields to documents, not having to worry about the data storage schema, etc.). Let me work in a disconnected mode that does not require the application to be aware it is doing so. Let me extend that functionality as I see fit in a reusable manner. Don't force me into a particular IDE. Don't force me to use a language that is not taught in any college in the world. Don't restrict me to certain frameworks.

    27anonymous  6/20/2007 12:32:32 PM  What if..... JavaScript is inevitable?

    I am a web domino developer and I've been doing complex javascript within domino for years. I have agree with the comments:

    - build your own framework

    - keep it simple and light

    - focus on things that developers will actually use:

    - nice-looking web views using AJAX

    - widgets for date, time, name picker, etc

    - DHTML rich text editor

    - easy javascript field validation

    28Samuel deHuszar Allen  6/20/2007 4:59:13 PM  What if..... JavaScript is inevitable?

    I would vote for more JavaScript support. Moreover, I'm always frustrated with IBM's claim that Lotus Notes allows you to extend your current knowledge into the Notes universe. The inference is and sometimes even the advertising reads (approximately), "if you know Java/JavaScript/XML/SOA/KitchenSink then you'll feel right at home and be able to use those skills to make Notes applications." What no one tells you until you're knee deep is that while there are certainly DOM classes and bindings for all your favorite languages, there is very little feature parity between languages. Obviously caveats like LotusScript not rendering in the browser is an obstacle, but a lot of the obstacles are arbitrary. There's no reason (that I am aware of) why I shouldn't be able to use JavaScript to script behavior in the Notes client. If that were the case, then I'd be able to write my scripts for the app and they'd run in all environments.

    Granted, feature parity between language classes is a monumental task, but I'm not the one writing the ads and doing press. A more realistic ad would read, "if you know Java, you'll be able to do certain types of things for certain types of applications, but if you want the app to work as you envision it, you'll have to also learn LotusScript, JavaScript, Formula, etc."

    My point is, anything to increase feature parity is a good thing. And for the new blood, who might get PO'ed by having their Java/JavaScript coding dreams for the Notes platform, please be a little more forthcoming about where the languages are applicable, or tone down the ads a bit.

    29Samuel deHuszar Allen  6/20/2007 5:06:59 PM  What if..... JavaScript is inevitable?

    Oh, and why couldn't IBM write FF extensions and ActiveX apps to handle client-side LotusScript?

    30Ian  6/20/2007 6:46:53 PM  What if..... JavaScript is inevitable?

    The thought of a lean, mean JS framework developed and evolved by IBM in conjunction with the extra tickboxes/settings on the various Notes design objects sounds like a good approach. Nothing too advanced - we need to keep all that developer resource for all the other areas of Notes/Domino that we want improved!

    Having said that, it's not really *that* difficult to get round Domino's limitations on the web at the moment, is it? I would class myself as an experienced, competent Notes/Web developer (but by no means a super-developer) and I've been able to come up with web apps that are not recognisable Domino apps for years, even without the help of the latest wave of frameworks (which I am only now beginning to investigate - JQuery is a very nice little one for starters). And asking developers to know Formula, LotusScript, JavaScript, HTML, CSS, XML/XSL is not really asking the world, is it? I think sometimes we want everything too easy!

    31Andrew Tjecklowsky  6/21/2007 8:29:23 AM  What if..... JavaScript is inevitable?

    Please do not create or endorse a JavaScript API for UI. Please just make Domino able to handle large strings (no limits!), make @ReplaceSubstring on RichText fields, make sure that we as developers can tweak Domino in every directions.

    32Brian Miller  6/21/2007 8:37:58 AM  What if..... JavaScript is inevitable?

    I had another thought...

    You also mentioned server-side JS. That's great. It should go in right along with Ruby and Python support, once IBM manages to integrate BSF as has been suggested in a previous post.

    Also, what would be really great - and doable - is to add first-class functions and anonymous objects to the next version of LS. That way, all the "cool" stuff that's done in JS can be also done in LS.

    Lastly, for more mashup goodness, can the current client-side JS implementation call LS or Java in a manner similar to what LS2J does today? Or, perhaps, vice-versa? Ideally, whatever language and tools you want to use to get the job done should be able to take care of the whole thing, soup to nuts. It's a long road, but we'd be real happy if we got there.

    33Dan Sickles  6/21/2007 9:49:09 AM  What if..... JavaScript is inevitable?

    @32 - Yes..just drop the favelanguage.jar in and fire up your favorite editor in Eclipse.

    The server side JS already exists with the LCD JS engine. I'd love to use jython but it's so far behind the current python that I'm using Groovy instead. Python through the COM API works very well and is fast. I use it for most db admin tasks. JRuby just went 1.0!

    In addition to first class functions in LS, I'd add generators, a real List type with literal construction syntax and a lazy XML parser for them big docs. Right after the OO implementation is significantly improved.

    34Erik Brooks  6/21/2007 10:18:22 AM  What if..... JavaScript is inevitable?

    Bob, I've been waiting for this question for awhile.

    1) You don't need to care much about what flavor of JS is running in a given browser *if* you limit yourself to fairly basic functions and set a bare-minimum (e.g. goodbye Navigator 4.x). I would bet that the iNotes team can give you lots of good input here.

    2) See #1

    3) Absolutely. IBM needs to "pick one" so that there is something that developers can use out-of-the-box and have it be supported. Please don't lock us in, though. Give us the flexibility to choose. You don't, however, need to make it ultra-simple for us to use a different framework. A bit of extra configuration/coding in this case would be fine.

    Server-side JS scripting would be a "nice to have" but not a requirement. Clicking a checkbox on a time field for "Show widget" and having magic occur should be the top priority.

    @9 - Thanks for mentioning the DFC database. I was wondering if anybody else had looked at that.

    @30 - Getting around Domino's current web limitations is not that difficult ("Hey, there's always pass-thru HTML!"), but it definitely isn't RAD. IBM wants Domino to remain a serious RAD platform, and if they don't invest heavily in the web area then it won't be anything near RAD when NMFR ships.

    Here's my input on the Dojo vs. Ext thing:

    Ext is nice. It's here today. It works.

    Dojo 0.4.x is elegant in language and implementation. In execution it's clunky, a bloated pig, and downright horrible.

    That being said, Dojo as a whole has a much broader mission statement and goal. The i18n and l10n requirements and goals alone are some serious stuff. From what I've seen so far the 0.9 release and 1.0 release should make for a decent framework, especially since they've decided to aim for zero backwards compatibility pre-1.0 (some of the early implementations of things were downright awful).

    The bandwidth arguments against Dojo don't hold up to me. It's a very modular framework with regards to dependencies, and caches nicely. Also, when NMFR ships that will be a good 2+ years from now, and broadband will be even more popular.

    But, as they say, "The proof is in the pudding." If IBM backs Ext I'll cheer. If Dojo 1.0 (due September if I recall) is as clean as Ext and IBM backs that I'll cheer.

    35Rob McDonagh  6/21/2007 12:34:05 PM  What if..... JavaScript is inevitable?

    @34 The bandwidth argument will be valid no matter how many years pass. Speaking as a purist, the fact that many (never all) users have lots of bandwidth is not a reason to bloat our code. Speaking as a pragmatist, I represent one of IBM larger customers (currently 1500 Domino servers), and there is no chance our remote sites will have broadband speeds until and unless they drop in cost below satellite network costs. That may never happen. And caching only applies to subsequent visits to a site, and in many PCI- and SOX-compliant organizations it has been forbidden for security reasons. The size of the library absolutely matters.

    Otherwise, we're in complete agreement. I don't really care what IBM picks (I have no doubt whatsoever that it will be Dojo, I'm just trying to make sure they understand that a certain number of customers are going to be very unhappy about it) as long as we can swap it out. In my organization, I won't allow the developers who work for me to use Dojo unless the size issue is resolved. So it will be swapped out, or turned off, or we won't do Domino development anymore. It doesn't have to be particularly easy to do, but the replacement technique does have to be documented and supported - not a hack.

    36Bjorn Cintra  6/21/2007 2:20:15 PM  What if..... JavaScript is inevitable?

    Firstly, the size of js resources can be greatly reduced by compressing them, and then gzipping them. Also for a high traffic site, you would be crazy not to use client-side caching.

    Secondly, the de-facto language for browser scripting is javascript, I don't think there is any point in discussing anything else in this space. When it comes to the library of choice, I must say I rather approve of the way it is done in Rails (oppinionated software). If you use the included prototype/scriptaculous, there is a built in DSL (Domain Specific Language) so that you can build javascript functions using Ruby. But they certainly don't force you.

    Thirdly, having server side javascript, running in a proper VM would be great. (btw, also having support for Ruby and Python would be even better). But also having a complete DOM implementation clientside would be great. For example, ability to access things by id, or dynamically insert DOM objects.

    When that is said, the things that really need to be "fixed" (in my opinion) are backend server thingys. Like making LS more dynamic and modern, make WQO agents so they can interact with the form after the fields are computed (and before), give us proper session handling that can handle both a shared-nothing and a sticky architecture. Oh, and give us a class for using memcached from LS :D

    37Scott Good  6/22/2007 8:24:49 AM  What if..... JavaScript is inevitable?

    There are a lot of great ideas here. A lot. And, many you'd be crazy not to consider putting into the product almost immediately. But, as a reality check, let's keep one thing in mind: The folks weighing in here constitute a large percentage of the best and brightest Domino developers ANYWHERE.

    As such, they are not typical. Not even close.

    While we are (rightly) arguing the nuances of third-party frameworks, server-side scripting and cross-platform compatibility issues, there are endless cube farms around the globe filled with secretaries given the Notes development job simply because they were good typists.

    At the end of the day, those of us here don't actually need what we're all talking about having added to Domino. Do we want it? HELL YES, but we don't need it...we've already worked out work-arounds. We're, if you'll pardon the comparison, the superheros of this particular game. Superman doesn't need a bullet-proof vest, either...it's the mortals out there who need those.

    The same goes here. As long a list as I (and the rest of the folks here) may have of obscure, hopelessly advanced, and probably seldom-needed functionality we feel we simply MUST have in the next release, what Domino REALLY needs is more functionality that can be immediately implemented by the unwashed masses--by the mortals--preferably without them even having to even know it's happening.

    The things 80%+ of the Domino developers out there need are mundane, and most of them have been touched on already by folks earlier in this thread. Things like NAB and date pickers that work automatically without you having to do anything more than click an option. AJAX-based field refreshing. An easy-to-use web equivalent of all the @Prompt and @Picklist options. None of these are hard, but all of these will help EVERYBODY out there building even the most mundane (which is to say, most) Domino applications.

    Do the stuff being talked about here, please, but let's not forget the folks who are really out there in the trenches. We'd like it. They NEED it.

    38Nathan T. Freeman  6/22/2007 11:55:11 AM  What if..... JavaScript is inevitable?

    @37 - Hey... just 'cause I don't write wicked AJAX apps in Domino doesn't mean I don't bathe regularly! ;-)

    @34 - Large customer or no, your bandwidth constraints are the exception. Lotus just isn't likely to move a lot of 3rd-world browser CALs, no matter what the framework is. Building applications to the concerns of users in South America or Africa, while failing to service the needs of first world users is not going to be a winning strategy. Particularly in light of the fact that if you don't like the new version, you can always take a page from the MS-shops and simply not upgrade.

    39Rob McDonagh  6/22/2007 1:29:13 PM  What if..... JavaScript is inevitable?

    @38 - I think you meant @35, since I'm the one griping about bandwidth. FYI, my company is based in the US, Canada and Europe. 1st World (developed country) all the way around. So your suggestion that IBM ignore the 3rd World as long as it keeps the 1st World happy doesn't exactly address my situation. In any event, I never said we were *typical* - I simply pointed out that there are companies, some of them very large IBM customers, who do not run at broadband speeds (latency is the bigger issue) in their internal networks. Look at the retail, oil/gas, and manufacturing industries. There are Fortune 100 companies in those industries who rely on satellite-based networks to service hundreds or thousands of remote sites.

    The larger issue, to me, is one of development best practices. The fact that all of *us* have great bandwidth in our homes and offices does not mean we should deploy bloated code. Even if it runs at a reasonable speed, it would run BETTER if it wasn't bloated. And IBM should not set its development community up for failure by making the default configuration of Domino apps a worst practices scenario. They did that in R5 with the Java applets, and all of the good Domino developers immediately wrote alternatives and hacks so they didn't have to use them. All of the mediocre Domino developers just *used* the Java applets, and thus contributed to Domino's poor reputation as a web application platform. [Aside: the bad Domino developers never figured out why their LotusScript UI calls didn't work in the browser..... ;)]

    Considering Scott's point @37, which I completely agree with, if Dojo is the default then all the NORMAL (bad and mediocre and almost good) Domino developers will leave it that way. The result in some cases will be acceptable, but in others Domino will maintain its reputation as a sluggish web application platform. Is that the target? Does that make Domino a "kick ass" development platform? Not by my standards, not by a long shot.

    In daydream mode, I idly wish for two standard configurations. One would provide maximum functionality with no regard for performance limitations, which would be perfect for intranet apps in many corporations. The other would provide reasonable functionality but be optimized for performance, which would be better for some corporations as well as for pure internet sites. Broadband penetration in US homes is still only 60% - 80% (depending on whose survey you believe), European broadband penetration ranges from 10% to 50% - or so The Google tells me - and the developing countries are in worse shape. If those people are your customers, bandwidth matters.

    40Baiju Thomas  6/22/2007 2:18:20 PM  What if..... JavaScript is inevitable?

    Well said Rob ans Scott. I have worked for the largest organizations in the world as a Domino developer and belive me what Rob has said is completely correct. I had to rewamp some domino applications recently which were not usable even in our high end intranet setup(In the US). Reason:The developer did not think about the performance implications of the default domino options and included what ever JS frameworks available for download just to make his work easy. And this is exactly what happens when IBM includes all the client side JS and frameworks as default. Smart people would always think about performance but a large number of people will develop applications with what ever default and easiest options available for them. You won't feel the problem as long as you deal with small databases. But when it grows, you are going to get the complaint "Domino is not scalable". And it is affecting the users in the first world and third world alike..

    41Erik Brooks  6/22/2007 2:36:51 PM  What if..... JavaScript is inevitable?

    @39 - I could definitely see some concerns since you have to worry about satellite access (though that is mostly latency, NOT bandwidth), especially if you have to enforce a strict never-cache policy on those machines. But I'm going to guess that overall that "perfect storm" scenario is a very, very small piece of the target Lotus userbase.

    I still don't think it's going to be that big a deal down-the-road -- let me explain:

    Dojo.js is ~160K or so in the horrible 0.4.x versions. With absolutely every library, widget, etc. included it's something ridiculous like 1 or 2 megs.

    For 0.9, one of the major goals is significantly smaller size. I believe that today Dojo.js (in 0.9) is down to nearly a third of 0.4.x's size (~65K if memory serves me correctly).

    Also, by NMFR I would think that IBM will have worked out the bugs and Domino will fully support GZIP compression with HTTP - right Bob? ;-) That should bring your bandwidth impact down even further.

    It sounds like we won't be forced to use Dojo, or even any framework at all. So If you *really* need to go ultra-lean-and-mean, then you should be able to uncheck the "Use Widget" option and roll-your-own with our best friend, Pass-Thru HTML.

    I'm just brainstorming other options here, but couldn't you also consider a local install of Dojo on your remote users' machines and reference that on your pages? I'm not sure if that would satisfy your security requirements or not, but if it would then you could get the best of both worlds -- good functionality and low bandwidth.

    42Rob McDonagh  6/22/2007 4:15:50 PM  What if..... JavaScript is inevitable?

    @41 - I am *very* interested in .9 and its smaller size. And I'm also interested in gzip, though to a lesser extent because it isn't always successful with javascript libraries - I could hack my Domino servers to support it now but it isn't reliable enough (at least in IE 5 & 6), and when it fails it doesn't just slow you down it simply mangles your code so it doesn't load.

    Again, I'm not suggesting we're typical. But we're not *that* unusual, either, in businesses with large numbers of remote locations. In certain industries, we're the norm. And IBM has a big presence in those industries, precisely because Notes has always been a good fit for iffy network connections.

    re: local installations, we've tried to go down that road with applets and activeX controls, but the security settings required in the browser to allow local installations violate our corporate policies too (don't get me started on the fact that our security policy allows us to use IE and Windows in the first place...). And dropping stuff into the local cache folders doesn't work 'cause we wipe that folder deliberately. As usual, security and convenience are two endpoints on a continuum...

    43Robert  6/22/2007 6:52:36 PM  What if..... JavaScript is inevitable?

    @20: I don't take jobs that don't involve authentication so turning JavaScript off is not an option. (Basic authentication isn't acceptable either.)

    Can you make a Domino web application with authentication truly "accessible"?

    44Nathan T. Freeman  6/23/2007 9:38:30 AM  What if..... JavaScript is inevitable?

    @42 - Yes, Rob, I was talking to you. :-)

    NMFR is probably 3 years away. Figure another year for an organization of your size to deploy it and at least 6 months to write anything substantial in it.

    Do you still expect those sites to be living in a low-bandwidth world in 2012? What was broadband deployment in the US in 2002 vs today? Particularly with wireless broadband becoming the norm (my Blackberry gets me 1Mbps even today) I just don't see the logic in holding the platform back.

    Now, that being said, I'm not the world's biggest Dojo fan either. Since I'm working on the Ext.nd project, I obviously have a certain allegiance to that toolkit. And I think it's fair to say that IBM is serious about preventing lock-in to any solution we don't like -- so you're always going to be able to turn off the extra code layers, just as you can today.

    @41 - Passthru is not your friend. Passthru is not anyone's friend. ;-)

    45Rob McDonagh  6/23/2007 2:17:51 PM  What if..... JavaScript is inevitable?

    @44 Given that our satellite network was installed in 1995, I think it's fair for me to assume it will still be there in a few years, yes. Consumer bandwidth will increase, of course, but businesses with low profit margins need cost justifications before they spend money on IT. Businesses of our size need major justification because the expenses are also major.

    In any event, I don't consider optimizing Domino for performance to be "holding the platform back" at all. Quite the reverse. I want the Domino web application platform to compete on all levels - functionality, RAD, and performance, and in its current incarnation at least, Dojo doesn't meet the last two requirements. In Domino's current incarnation, it doesn't meet any of the 3. As we all know. Until we hand-write alternatives to the built-in constructs from IBM, which many of us here have no trouble doing. But again to Scott's point, the vast majority of Domino developers DO have trouble doing it. Bob's talking about IBM developing a platform that kicks ass OUT OF THE BOX, not after a good developer throws away the RAD controls and features to write better ones.

    And I completely agree, Passthru is my mortal enemy. But IBM has forced me to cohabit with the b*st*rd and I'm stuck with him.

    46Bob Balaban  6/24/2007 10:44:31 AM  What if..... JavaScript is inevitable?

    Greetings, Geeks!

    I continue to be surprised (in a good way) at the amount of feedback I've been getting on this blog (hey, I'm new to this, and I'm no Rocky or Vowe or Ed, or Rob, or Alan).

    What is especially nice is that so many of your comments are really interesting and helpful, and that there's a decent amount of "conversation" as well.

    Keep it up, Geeks!

    And so, without further ado, some comments/replies for ya:

    @1 - Russ, I can't say a lot about this now, but stay tuned!

    @2, @35, @39, @42, @45 - Rob! I think you get the "most comments per blog entry" award!! Heartfelt thanks for taking this topic seriously and for contributing to the discussion - Reallyl!

    Re: "I will officially declare Domino web development dead...", I intend to convince you otherwise, even if it takes more than one release to do it (we most likely cannot accomplish all that we want to in release NAE ("number after eight"), but we will not abandon the plan just because of that).

    Firstly, the Domino web appdev strategy depends on a lot more than which Javascript framework we pick to support "out of the box". We have MANY things in mind for improving the Web-related or Web-delivered features of Domino (read some of the other blog entries I've written, you'll get the drift), hooking stuff up with Javascript is only one of those.

    Even though it's too soon to declare the selection process over (someday I gotta write a blog entry on "Software Development Is Done by Lawyers"...), but rest assured that I am hearing quite a LOT from The Geekdom that we better get the architecture right. Meaning, we should go ahead and pick one for those who either don't care or who don't have the time or skills to use a different one, but we have to make sure that we're not preventing others from using something else.

    To get just a bit more specific -- let's say hypothetically that we choose a Javascript framework called "Cujo" (I sure hope there isn't reallyl one named that, and that Stephen King does not read this blog...) to bundle on the Domino server package. Let's say further that Lotus writes some "Cujo" plug-ins that add value to the framework by, say, being able to interact nicely with Domino Views and other PODDOs (plain old Domino Data Objects). Thus, developers would get to use these things easily in some future version of Domino Designer. I have no idea (yet) what that UI would look like. Probably something that said, "for the action bar, use a Javascript widget", and you pick one.

    Of course, you would be able to put your own .JS files on the server, and write (or acquire somewhere) your own set of plugins for it. We are NOT going to force you to use the one we pick (that, IMHO would be stupid). We think we DO need to provide one, in order to enhance not only the design-time experience for developers, but also to improve the run-time behavior of the apps that the designers build. But if you want to use a different one, it is our goal not to care.

    This will NOT be a hack (not even a righteous one). The size/performance issue is a real one for lots of WOJOs (Wads O' Javascript) that we would like to ship from the server to the client. Clearly size was a factor in the now near-total avoidance of Java applets as a Web technique. I see a complex tradeoff matrix here, where on the one hand you might want smaller JS files to speed up loading, but if you have too many then you have to make too many trips to the server, with resulting high HTTP overhead. You can adopt the same AJAX-style background loading for your code as you do for your data, but that's tricky too: how do you make sure that all the code you need is really there at the time you need to use it to do something? You could, of course, just use less code, but then you risk degrading the user experience or (even worse, IMHO, though I know I am a minority in this) the functionality of the app.

    No easy answers (unfortunately). We're going to continue to work on it, though.

    @3 - We are figuring out what to do about supplying a rich text editor that is not written in Java. Stay tuned. Hooking up AJAX behavior in easy ways is DEFINITELY in our plan.

    @4 - I hear you, but see above responses to Rob McD. I'm surprised that nobody seems worried about the fact that if you put a ton of functionality into JavaScript code, you give away your source code to everyone. I expect this could be a problem for ISVs, for example. I don't think there's an easy answer, except perhaps to architect your app so that your family-jewels biz logic runs only on the server.

    And what about XSS (cross-site scripting)?? I'll probably make a dedicated blog entry on this topic....

    @5 - ext is impressive, and ext.nd even more so. There are some IBM realities with which I must deal that may lead us to make another choice, however. This is not necessarily a bad thing! And, we do NOT want to prevent you from using whatever you want, you won't be forced to adopt our choice.

    @6 - My thinking has evolved a bit, now I'm pretty much expecting that whatever JS framework we pick to isolate us from browser differences. As for your comment on LotusScript, have you been following Maureen's blog??

    @7 - A lot of what you're asking for would (I expect) be accomplished on the tools side (i.e., in Domino Designer). I'm not really "offering" anything, just floating some hypothetical ideas and looking for feedback. My overall goals are 1) Avoid wasting time by doing stupid things, b) Add value to Domino as a Web application platform. Clearly the Greater Geekdom has lots of valuable feedback to offer!

    @8 - Thanks, ViktR!

    @10 - Re: HTML, Bingo! Re: Applets, Bingo! Re: generating javascript from (I assume you mean) @functions, would love to be able to do that, but I'm concerned about how robust we'd be able to make it. Wouldn't you want to just be able to write those functions in JS? Easier to debug, no loss of function throgh translation, etc...?

    Re: AJAX, Bingo! As for publishing the source code, obviously you'd get that for anything we do in Javascript. Wanna volunteer (WAY in advance...) to join the team that will write the redbook for this stuff? :-)

    @11 - Great suggestions, thanks Sean!

    @18 - Ah, Wild Bill wants it to be a floor wax AND a dessert topping! Well, why not? "In the fullness of time..." as Kevin Cavanaugh might say

    @19 - Re: IrisJSConsole, I am investigating. And thanks for all your other suggestions, very insightful.

    @20 - I understand your concerns about accessibility. I am told that Dojo, at least, is working on resolving these (and other) limitations.

    @23 - Great suggestions, thanks! CSS is most definitely on my list of things to make better in Domino

    @24 - Thanks for the suggestions, Brian. Many of these are, of course, things that would need to be implemented in the Designer. Stay tuned!

    @26 - Interesting references to JSF. My understanding, however, is that this is a server-side technology, that it doesn't run in browsers. Regarding your comment about IDEs, I think it will be true for a while longer that if you want to create a Domino (or Notes) app, you will pretty much need to use Domino Designer.

    @28 - Valid points of criticism, for sure. Bringing parity to the set of languages we already support for the back-end classes is definitely on our list of things to do.

    @29 - We probably could, but I don't think we want to be locked into supporting multiple code bases for specific target platforms, which will probably continue to change/evolve over time.

    @32 - Hmm. Well, if I were going to make a JS version of the back-end classes, I'd probably just ride it on top of the Java stuff, and take advantage fo the fact that JS has bult-in support for calling Java, right? Much more complicated to deal with other languages (php, ruby, python, etc)

    @34 - Thanks Erik, glad the waiting is finally over! :-)

    Re: DFC, I located the author, still investigating

    @37 - Scott, your common-sense comments are (as always) as a warm spring breeze, bearing the scent of the first spring flowers. Or whatever. Pretty much. I look forward to getting more of your feature suggestions

    @38 - TMI! TMI!

    @41 - Yes, GZIP is on our list too. Cannot make any promises about specific releases.

    @43 - Can you tell me more about what problems you're having in this area? Email is ok (bob underscore balaban AT us DOT ibm DOT com)

    @44 - Don't be so sure about timeframes, Nathan!! :-)

    47Erik Brooks  6/25/2007 1:53:05 PM  What if..... JavaScript is inevitable?

    @42 - That GZIP hack is definitely broken, if I recall. I'm not sure if IE 5 / 6 are the major problem, but I know there were serious problems of Domino databases becoming corrupted if you switched it on.

    I've done a lot of research. Ext out-of-the-box is great, but I'm really amped about where Dojo is going. The core people involved are impressive, and the architectural goals seem solid. I remember that one of the first things I really liked was how it loaded dependencies -- e.g. if you "include"d the Calendar widget, it loaded just the libraries needed for the Calendar. It wouldn't bother downloading the SVG package or the crypto package or anything else it didn't need.

    ...and then I tried it in practice and it puttered and sputtered and coughed and lived for a brief moment and then leaked memory like mad and crashed the browser.

    But that was 0.1, 0.2, 0.3, and 0.4. 0.9 is in many cases a complete gut, and they've done some things completely differently (such as separating out "Dojo" to be the core javascript libraries, and "Dijit" being the widget libraries).

    @46 - Bob, (in reference to your @10) I for one would be more than happy to write InputTranslation code, etc. in Javascript IF all of the power of the @Formula language was brought over.

    This means list handling support, functions we take for granted like @Propercase, @CheckFormulaSyntax, date-range support e.g. [1/1/2000 - 1/31/2000], etc. Heck, I've already got some of these functions written, like atRightBack().

    If IBM doesn't provide all of this then all you've really done is put a wrapper into onBlur() or onSubmit() for us to continue to "roll our own" JS, and you've simply saved us one step.

    If, on the other hand, all of this support DOES make it in, then you're really only a stone's throw away from a @Formula <> JS translator anyway, aren't you?

    From there I could see IBM possibly wanting to deprecate the @Formula language, so that all new functions are JS. If that was the case then you would definitely need a backend JS processor (and syntax to hook into the Domino objects such as views, etc.) so that agents and backend code could leverage the capabilities.

    But then you're only a stone's throw away from an AJAX layer to be able to hook into the backend Domino objects from a browser!

    Lots of "if"s, "and"s, and "but"s, not to mention a bit of stone-throwing... but definitely interesting.

    48Nathan T. Freeman  6/25/2007 6:30:15 PM  What if..... JavaScript is inevitable?

    "then you're really only a stone's throw away from a @Formula <> JS translator anyway, aren't you?"

    Actually, Lotus Component Designer already does a big chunk of this.

    49Maureen Leland  6/25/2007 10:02:10 PM  What if..... JavaScript is inevitable?

    Yes, indeed, LCD already has most @functions rewritten as JS methods. We need to add a bit of abstraction around data sources for those @functions that are data centric, but that is pretty easy to do :-)

    Another point - while JSF does do lots of server side stuff, its implementation in LCD also offers partial page updates and client side scripting, so there is much flexibility in the model.

    50Tim Tripcony  6/26/2007 12:42:02 AM  What if..... JavaScript is inevitable?

    @46 - Loved the New Shimmer reference. "Calm down, you two."

    @47 - You're right, the GZIP option that's tucked away in the server document is quite unreliable... but there's an option that works just fine for JS frameworks (or any other static content, really), using Internet Site substitution rules:

    { Link }

    51Fredrik Stöckel  6/26/2007 3:01:47 AM  What if..... JavaScript is inevitable?

    A "minor" thing comes to mind:

    Implement Proper/correct http status codes for session based authentication (this is very usefull when using XHR calls).

    52Charles Robinson  6/26/2007 9:15:12 AM  What if..... JavaScript is inevitable?

    @37 - Thanks for bringing up the plight of us little guys in this sea of giants. :-)

    53Rob McDonagh  6/26/2007 10:28:01 AM  What if..... JavaScript is inevitable?

    @47, @50 - I was actually talking about 2 known issues with IE versions when dealing with ANY gzip'd content, not Domino-specific issues. IE (5.x and 6.x anyway - don't know about 7) has a bad habit of firing OnLoad when it receives the JS file, not after it has decompressed it, so your compressed code may not be correctly interpreted.

    Also, there's a bug in UrlMon.dll:

    { Link }

    In that case, the browser drops the first 2k of data returned as compressed. The fix requires modifying the registry on the client, which for public sites is a non-starter. Neat, huh?

    54Dan Sickles  6/26/2007 4:21:25 PM  What if..... JavaScript is inevitable?

    @46 - My version question was in reference to javascript language version. I would llike to see javascript 1.7, the version in Firefox 2.x, and a roadmap to Javascript 2.0. The minimum required to support framework x, y or z could be met with a rather old versiion of javascript. While framework support is clearly a priority, I hope that minimum requirements don't set an upper limit on the language.

    I love what Maureen is doing with Lotusscript on Eclipse. I'm a freak for tools. I'm also hoping for some significant language enhancements (unless I've missed something).

    55Erik Brooks  6/26/2007 9:38:32 PM  What if..... JavaScript is inevitable?

    @53 - Ouch... I'm not surprised IE5 munches GZip'd content, but 6? Ugh. Fortunately the UrlMon.dll bug seems to be fixed in IE6 Service Pack 1.

    Your "Neat" had me rolling! I just finished working with IBM on my 3rd PMR-turned-SPR in about 18 hours, and one of those definitely qualifies for the term.

    56Brian Miller  6/27/2007 9:40:39 AM  What if..... JavaScript is inevitable?

    @46 (re: server-side scripting):

    I still contend that, if integrating BSF done properly, you can have every scripting language that it supports. You get one, you get them all. And, it's *probably* easier than baking in a JS engine by itself.

    57Dan Sickles  6/27/2007 2:19:04 PM  What if..... JavaScript is inevitable?

    @56 - I agree. The current version of java (6.0) does include Rhino as a JSR223 (essentialy replacing BSF) reference implementation so I think it would be a good default option. And Rhino is still improving:

    { Link }

    (add an NSF adapter and run it in the new improved forthcoming domino servlet container ;-)

    IBM rolled their own JS/JVM engine for LCD due to potential licensing problems (per the folks in the Lab at LSphere '06). That's why I'm concerned about maintaining a current language version on the server. I hope they use Rhino, spidermonkey or the new spidermonkey+tamarin that mozilla is moving to.

    58Tom Roberts  7/9/2007 11:55:30 PM  What if..... JavaScript is inevitable?

    Sorry for joining the party a little late...

    Yes, Javascript adds a great deal of functionality and appeal to the client, but there is one point that, imho, cannot be overlooked. The site MUST downgrade nicely if js is not present.

    I'm trying to get the majority of our company applications to the point that they can accessed at anytime from anywhere. This is a fairly easy sell in principal. Unfortunately, many of the latest apps coming out under the Lotus brand simply do not work if js is not present (Quickr specifically). I can pull up and use Basecamp on my blackberry, but it's difficult to try to sell why we should use Quickr over Basecamp when I can't access Quickr with my blackberry.

    My Sametime server runs a great number of production apps that are exposed to the web. Unfortunately with it, the login page for the server checks for js and does not even let users authenticate with the server. Yes, I can move them (or sametime) to a different server. Point is, I shouldn't _have_ to do that.

    If js is not present, fine - display the info without all the fancy stuff. Please don't ignore accessibility.

    59Bob Balaban  7/14/2007 9:56:33 AM  What if..... JavaScript is inevitable?

    @58 - Thanks for the comments, Tom. I agree with you about apps "degrading gracefully" in the absence of JavaScript on the client.

    However, I think your reference to the Blackberry is really a different problem. There are many Web sites that don't make heavy use of JS which look terrible on the BB (I've been poking around with mine, it's sometimes shockingly bad)

    60Tom Roberts  7/16/2007 9:13:44 PM  What if..... JavaScript is inevitable?

    That is certainly true as well - sites that make good use of css for layout typically degrade much better than sites that use complex tables and images, imho.

    I read the post a while ago but didn't post for a while. The tipping point for me was an issue where I'm trying to get Quickplace/Quickr adopted when users are adopting Basecamp. The comparison for my users is Quickr vs Basecamp. Basecamp wins hands down on degrading gracefully, including great support on the blackberry.

    On a somewhat related note, back a few years ago Scott Good and I had a thread ({ Link } ) going on his site discussing being able to flag design elements as using css instead of substituting font tags when going through Domino.

    I've watched some of the threads regarding different ways Domino engine could generate html in the future. Back in the 2004 post, I stated "Domino storage is essentially xml (document truly only contains name & value pairs (and multi)). It seems like it has all the fundamentals needed to have domino spit out an xslt and xml to format individual documents. And force the user to use styles (if db is tagged for css only) or simply create css for all the styles (to an external css of course), and use inline css instead of font tags everywhere else."

    In other words, if an xslt document could be a design element similar to a form (and views could use form formulas that resolved to an xslt doc), developers could have much greater control over the presentation of data stored in an nsf. I believe Lotus already has a designer product along those lines (Workplace Forms Designer).

    Given your present position and directive, has this been discussed? Is it feasible?

    61John Vaughan  8/17/2007 11:04:12 AM  What if..... JavaScript is inevitable?

    It would be nice if there was a focus on not just the base functionality (@formula to javascript etc) but also on the UI possiblities. The best example seems to be EXT/EXTnd as far as frameworks go. If you guys can keep kick ass UI as one of the primary goals, right up there with ease of development, Domino will win a lot more skirmishes on corporate battlefields. Developers and end users will be shinier and happier all around. :-)

    62mike woolsey  8/28/2007 1:31:55 PM  What if..... JavaScript is inevitable?

    On another side -- I've been just ditzing with Ruby on Rails as a newbie -- the use of scriptaculous components there is just very slick. I don't know how it might fit into Domino, but just saying "oh make it this" without stuffing and slicing bits of Javascript all over the place is really quite nice.