Re:vs. Curl (Score 1)

I think we're agreeing that developers can do whatever computation they want on an XWT client. As I understand it, there are two ways:

1. XWT UI descriptions can include Javascript. Javascript is terrific. It's well known by lots of people, and easy to learn for others. However, there's no perfect language for all purposes. Javascript was specifically designed for short scripts. As a consequence:
   • It doesn't have the programming-in-the-large support needed for large projects involving many people or organizations, or for modeling complex problems.
   • It is very difficult to build an implementation in which it executes very efficiently (e.g., on the scale of inner loops of a graphics app).
   None of this is a problem for XWT's stated design space -- UIs to applications that execute on the other end of a network connection. But suppose you do want to something fast and complex on the client? This brings us to...
2. You can write a dedicated client app in C++ or some such, get it to the user's machine, and then communicate with it through XML-RPC. I can imagine other similar communications through the browser. This can be nice, because each part of the job is done with a tool that is designed for that domain. Different people with entirely different skill sets can work on the different parts. However, whenever you mix technologies and try to have tight communication between them, there can sometimes be problems. I'm not sure that this scenario is really the best way to deliver on the benefits that lead us to Web-based apps in the first place (see the start of my original posting, vs. Curl).

I also agree with Adam that Surge isn't as approachable as it could be. If a Javascript-based UI-architecture starts to slip as the complexity or responsiveness requirements go up, you would think that it should be possible to approach things the other way and use just the parts of Surge you need for doing simple UI stuff? Surge was indeed designed to let simple things be simple. For example, there's an integrated layout and formatting engine that makes it easy to declare how stuff should be organized such that you don't have to write code to handle resizing of windows while avoiding horizontal scroll bars. And you don't have to include type definitions, or write procedure or class definitions.

But as a practical matter, there is a lot there, and it is different enough that I can understand how a time-pressed developer wouldn't want to learn something new. And the "gentle slope" approach isn't perfect. For example, I'd rather see undeclared numbers use decimal or bignum integer representations than fixed size representations. (Although Javascript has the same problem. By the way, Adam, where did you count 18 int types? I count six with two more pseudonyms. Java has five, C eight, and C# nine.) Anyway, the point is that Surge is really more optimized right now more for enterprise-level programmers with big problems then for mass adoption by designers.

So where's the dividing line today? The XWT FAQ mentions that interactive games are probably not appropriate to a Javascript-based UI-server approach. Anything else? Right now, Curl seems to be resonating most with people developing enterprise stuff with a high degree of custom business logic, tight response times, high interactivity, and changing requirements. My personal feeling is that there isn't much like this on the consumer web because there hasn't been a reliable way to develop and deliver it before. The space of simple applications hasn't yet been exhausted, and for these, UI-servers are plenty good enough. Comments?