Slashdot Mirror
New Language CURL Merges HTML And Javascript
jluxe writes: "CNN reports that a new language, Curl, was presented at the Software Development Forum in Palo Alto. This language works via a plug-in to browsers, and attempts to merge the gap between HTML, javascript, java, and even C++. It also supports the Macromedia Flash plug-in. Interesting to note that Tim Berners-Lee is listed as a financial backer of this venture, as well as an adviser." Here's the Curl Corporation's official website as well.
Hmmm look at the bandwidth available even using GPRS and I'd say the bandwith/client processing power still stands. Even your mobile phone will be able to process and manipule data client side and will probably give a better client experience if it does rather than having to do page refreshes every time something minimal changes on the page. The PC will be with us for a long time yet...it'll get smaller, you may wear it instead of sitting in front of it, but No-one is going to want to use a spreadsheet which has to submit back to the server to do a formula calculation in a cell. In fact the ONLY web based office suites I've seen which work are either Java based, or in the case of the brainbox spreadsheet (www.brainbox.com) Use javascript EXTENSIVELY. You only have to look at the rise in P2P style applications to see that distributed computing power, it taking off. I'd say the era of the 'HTML web browser' should be coming to a close. I want an application browser which downloads application elements rather than an HTML based interface that's just a jumped way of displaying static information. I'd say you wont be using a TV to watch streamed video anymore - you'll watch TV on your PC.
People have seen the short-comings of Java, with the client-side operating environment practically bringing your machine to its knees
I'm sorry, but that's complete bull. I'm typing this in galeon 0.11 on a P3 450 with 256MB of RAM, with JBuilder 4 Pro (a pure Java IDE) running on another desktop, KDE2.1, KMail running, etc, and the machine is running just fine, thank you very much.
Java has come a long way in the last couple of years. True, most popular browsers still use an outdated version (1.1?), but don't let that blind you to what a real JDK can do.
I work for a web agency, and we do all our server-side work in Java (on Linux). No, I wouldn't recommend using Java client-side for a web site, but that's just because of most browsers' crappy Java support.
Personally, I'll be watching CURL with interest. I don't think it'll take off anytime soon, if at all (12meg download for a plugin? Not over a modem...), and I can't see us using it, but at least someone is trying something new.
Cheers,
Tim
It's official. Most of you are morons.
I didn't follow this. Could you explain? (I work for Curl, so I'd like to know.) There are a couple of things going on here. First, one might deliver in Curl for functionality, development&maintenance, or bandwidth. Sometimes these are tradeoffs. More functionality (e.g., interaction on the client) MAY mean a bigger "program". Reducing graphics transfers by switching from a server-built image to procedural graphics generated on the client MAY increase development&maintenance costs. However, there are some pure win/win situations, too. HTML/XML is pretty verbose compared with Curl, so that alone saves a bit in both bandwidth and development&maintenance. Of course, that's not enough by itself and I wouldn't want people writing Web pages in Perl! It's just one thing that enters into it. More important, is basic abstraction. If you use something twice, you can define it once and reference it many times. When the abstractions take parameters (i.e., are procedures), you really win on both bandwidth and development&maintenance. The biggest win, though, comes when there are multiple interactions. Build a layout and interaction mechanism once and use it in a bunch-o-projects. Once the client has it cached, they don't need to get it again. Then just send the "data" that changes with each interaction. No need to resend what hasn't changed and no need to flicker the user's screen. Smaller, faster, better. Yes, this part is the same idea as XML, and the transfered "data" might very well be encoded in XML. You could think of Curl technology as a way to deploy a specialized XML viewer. By combining these (including the procedural graphics), we're seeing order of magnitude bandwidth decreases. Since big sites pay for bandwidth, the decreases more than offset the cost of a commercial use of the technology. The snapier and more fun interactions for the user are a bonus.
Howard Stearns - I work at Curl Corporation, but I speak for myself.
You assume your hardware is powerfull however we are quickly moving toward the use of minimal systems to interact with the net. Do I want to locally compile and process a load of data on my flash new mobile phone? No Sir...
The era of the PC is coming to a close - we are moving towards lots of small tailored solutions - mobile phones, settop boxes and the like. You won't be browsing the web (at home) from a PC - it will be a TV...
It's interesting. People have seen the short-comings of Java, with the client-side operating environment practically bringing your machine to its knees, not to mention certain IE vulnerabilities with older versions of JDK. So we tried to move away from that environment by performing server-side processing. ASP, JSP, ColdFusion, and the ever-powerful PHP. Why is it that we want to go away from the server-side arena when we know what it is like?
Now the reason I'm directly mentioning PHP is because this plugin boasts the ability to merge C++ with your webpages. Well, you can write CGI with C++, but that is usually rather painful. PHP is (to me) Perl and C/C++ all wrapped into one. You want classes? Sure, you got them. You want great string manipulation? Sure, that's there too. Not to mention you can embed Javascript in their if you NEED to use it. And now that PHP supports some level of GTK for graphics, why would you even want to use Java, especially since you can ram all the Shockwave and Macromedia Flash into a PHP-generated page that you want? I just don't see the benefit, if there is any, of trying this, when server-side dynamic pages have proven to be incredible, and give all and even more functionality that this product boasts. Who knows though, maybe it will be better than we all expect.
What will the fine folks who made cUrl ("the client that groks the urls") say of this ?
:)
If I had a chance to sue some vaporware e-bullshit company out of existence, I'd sure jump on the occasion
-Billco, Fnarg.com
Lucky for us, and too bad for them it won't fly. People who have actually worked on large-scale web development already know that mixing code and content in this way is a maintenance headache. And the others seem reasonably happy with JavaScript and VBScript.
Curl may not be any more proprietary than Java, but the site constantly bares its legal teeth at you. My gut reaction is to stay away.
I imagine my assessment at the time still stands: Using a plugin as the deployment technology could be useful to get a critical mass of developers and libraries, until it becomes semi-standard. However, since I can't recall seeing anything at all related to Curl in these months since the last story, I'd say critical mass is not forthcoming. :(
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
How is this viewed generally in terms of Web development. It seems to be something that was designed specifically for this intercompatability. i would like to know what has been compromised in terms of other functionalities for CURL, in order to be all things to all people? Especially since as a plugin, it will be something that people can try and remove quickly if they don't like it. As has been discussed in previous posts there has not been a lot of interest thus far. If it were kickass, it would be a little more popular now 'cause everyone can use it with their existing work on the web, right?
.tv domains specifically restricted to sites in such isolative languages, in order to support TV-appliance technology using the Web and other peripheral economies.
Furthermore, I have always believed that a universal standard is not always a good thing for its own sake. Consider the commercial applications of sites on the Web that are only readable through a particular technology, and translator programs do not capture the full glory of the site. Yes you can translate but it's like dewatermarking a copyrighted music file, it sounds and looks like shit. For visual media on the Net, like maybe sitcoms or whatever that want to broadcast there rather than on TV, it would probably be a good idea to write in a language that's isolated from others commonly used on the Web. I could even see rules that make the
Goat sex free since 2001