Besides the completely irrelevant whinings about Curl's website using JSP pages (geez people, that's like saying a web page promoting Java is using _HTML_ to disseminate information about the language.. oh the horror!), we seem to be getting some good informed feedback here which I think is great! I've read through most of it and would like to both summarize a few points that have been made, as well as comment on my expectations and view of the language.
Applications at present are almost universally server-dependant, and the average client machine isn't using a fraction of its own processing power. While bandwidth may be increasing, we're also wasting it with unnecessary server requests. On the whole it would seem logical to reduce server load and increase client load since servers are in general overloaded and clients are underloaded. Client computers are getting cheaper and faster, but current internet architectures don't take advantage of this at all. Curl does, and this is makes it a good thing!
Yet as with all things, there is a downside. What about those of us with slow computers? Receiving purely HTML content is not a big deal, but the minimum requirements for installing the Curl plugin are somewhat high. This worries me. Without improvements in this respect, I do not think Curl will be a viable replacement for HTML, or even the current HTML + CSS + DHTML + Javascript model. Why? Because it's a bit too powerful, complicated, and requires a bit too much computing power for the simple things. Slightly dynamic, nicely laid-out documents should not require this kind of processing power. And this is too bad, because I like the idea of using one language with the capabilities of all four. (I especially want to get rid of Javascript, that hacked crap language that gives Java -- which I know and love -- a bad name.)
On the other hand, I can see Curl as a serious competitor to some of the "Flash"-ier sites, with its native 3D support and built-in 2D library. Flash development sucks ass. (Whoops, pardon my language.) Curl also has the advantage of integrated powerful layout capabilities. Text/graphic layout using HTML/CSS still has me smashing my head against the walls in frustration, especially when I get things JUST right in Netscape only to have it be a complete mess in IE. Frankly, it's too much of a pain to do simple layout with HTML+CSS and I've been itching for something better all these years, even if it means learning a new language.
Hopefully improvements will be made in reducing the requirements for the plugin. (And btw, I think the fact that it is a plugin and not a whole new browser is a good idea. That makes it more compatible with existing technologies, and means the company spends more time on making the Curl language work rather than making HTML/everything else work.) Curl is still a new language and we really have to give it time to develop. The underlying concepts are good though... utilizing client processing power, providing powerful graphics capabilities and much simplified layout functionalities. What the company aims to do -- address the shortcomings of current client-side web languages -- is very ambitious. I think the specification is pretty cool even if the implementation leaves some things to be desired.
I sincerely hope the company is working really hard to get the Mac/Linux plugins running as soon as possible, since that's a big selling point. And that it works as specified... no platform inconsistencies and real platform independence would be a real win. It would, of course, have to be faster than Java to REALLY sell though (JVM was a good idea for this but in the end, makes Java slower than I'd like).
I too would like Curl to rethink their marketing strategy. Although they initially only charge for commercial sites, the wording they use implies that they may start charging everyone. If they ever start charging noncommercial sites employing Curl content I will likely never support them, not while there are alternatives. Even for commercial sites, charging on an executionary basis is less than ideal; for example, what about those sites with high browse to buy ratios? The pricing scheme really sounds very bad to me. The solution? Make it open source and free. This is the one true path to enlightenment and eventual perfection.
I hope Curl survives long enough to work out their initial bugs (and work through the initial criticism of the largely uninformed public). I think it could be a really revolutionary thing for the internet community, but it needs support/acceptance and before that, more development and marketing work. I'd say that starting with educational facilities is definitely the way to go... the current generation of web programmers already knows alternative languages that are widely accepted and thus marketable. I also point out that Java will also always likely be easier to learn for those who already know C/C++, and the fact that it is THE hot language to know for internet application development gives Curl little leeway to break through in today's market without a carefully thought-out marketing strategy.
At the moment, I simply don't have the free time/resources to spend learning a new language that might conceivably turn out to be a waste (though I really hope not!) no matter how easy it is to learn and use, so I am not investing much energy into learning Curl. I already know enough about programming in general that I probably won't gain anything by learning yet another new language. However, students just starting to learn web programming might find it educational to begin with Curl as opposed to HTML (I never thought the HTML syntax was pretty anyway)... another reason why I think Curl should consider targetting the younger generation.
So in short, if Curl Surge is included as a plugin packaged in the basic install of Netscape and IE for every platform, free of charge, I think over 85% of Curl's problems would be solved.;) Java extraordinare that I may be, they will likely have my support. In the meantime, I look forward to seeing what changes might be included in future releases of Curl.
Slashdot Mirror
Besides the completely irrelevant whinings about Curl's website using JSP pages (geez people, that's like saying a web page promoting Java is using _HTML_ to disseminate information about the language.. oh the horror!), we seem to be getting some good informed feedback here which I think is great! I've read through most of it and would like to both summarize a few points that have been made, as well as comment on my expectations and view of the language.
;) Java extraordinare that I may be, they will likely have my support. In the meantime, I look forward to seeing what changes might be included in future releases of Curl.
Applications at present are almost universally server-dependant, and the average client machine isn't using a fraction of its own processing power. While bandwidth may be increasing, we're also wasting it with unnecessary server requests. On the whole it would seem logical to reduce server load and increase client load since servers are in general overloaded and clients are underloaded. Client computers are getting cheaper and faster, but current internet architectures don't take advantage of this at all. Curl does, and this is makes it a good thing!
Yet as with all things, there is a downside. What about those of us with slow computers? Receiving purely HTML content is not a big deal, but the minimum requirements for installing the Curl plugin are somewhat high. This worries me. Without improvements in this respect, I do not think Curl will be a viable replacement for HTML, or even the current HTML + CSS + DHTML + Javascript model. Why? Because it's a bit too powerful, complicated, and requires a bit too much computing power for the simple things. Slightly dynamic, nicely laid-out documents should not require this kind of processing power. And this is too bad, because I like the idea of using one language with the capabilities of all four. (I especially want to get rid of Javascript, that hacked crap language that gives Java -- which I know and love -- a bad name.)
On the other hand, I can see Curl as a serious competitor to some of the "Flash"-ier sites, with its native 3D support and built-in 2D library. Flash development sucks ass. (Whoops, pardon my language.) Curl also has the advantage of integrated powerful layout capabilities. Text/graphic layout using HTML/CSS still has me smashing my head against the walls in frustration, especially when I get things JUST right in Netscape only to have it be a complete mess in IE. Frankly, it's too much of a pain to do simple layout with HTML+CSS and I've been itching for something better all these years, even if it means learning a new language.
Hopefully improvements will be made in reducing the requirements for the plugin. (And btw, I think the fact that it is a plugin and not a whole new browser is a good idea. That makes it more compatible with existing technologies, and means the company spends more time on making the Curl language work rather than making HTML/everything else work.) Curl is still a new language and we really have to give it time to develop. The underlying concepts are good though... utilizing client processing power, providing powerful graphics capabilities and much simplified layout functionalities. What the company aims to do -- address the shortcomings of current client-side web languages -- is very ambitious. I think the specification is pretty cool even if the implementation leaves some things to be desired.
I sincerely hope the company is working really hard to get the Mac/Linux plugins running as soon as possible, since that's a big selling point. And that it works as specified... no platform inconsistencies and real platform independence would be a real win. It would, of course, have to be faster than Java to REALLY sell though (JVM was a good idea for this but in the end, makes Java slower than I'd like).
I too would like Curl to rethink their marketing strategy. Although they initially only charge for commercial sites, the wording they use implies that they may start charging everyone. If they ever start charging noncommercial sites employing Curl content I will likely never support them, not while there are alternatives. Even for commercial sites, charging on an executionary basis is less than ideal; for example, what about those sites with high browse to buy ratios? The pricing scheme really sounds very bad to me. The solution? Make it open source and free. This is the one true path to enlightenment and eventual perfection.
I hope Curl survives long enough to work out their initial bugs (and work through the initial criticism of the largely uninformed public). I think it could be a really revolutionary thing for the internet community, but it needs support/acceptance and before that, more development and marketing work. I'd say that starting with educational facilities is definitely the way to go... the current generation of web programmers already knows alternative languages that are widely accepted and thus marketable. I also point out that Java will also always likely be easier to learn for those who already know C/C++, and the fact that it is THE hot language to know for internet application development gives Curl little leeway to break through in today's market without a carefully thought-out marketing strategy.
At the moment, I simply don't have the free time/resources to spend learning a new language that might conceivably turn out to be a waste (though I really hope not!) no matter how easy it is to learn and use, so I am not investing much energy into learning Curl. I already know enough about programming in general that I probably won't gain anything by learning yet another new language. However, students just starting to learn web programming might find it educational to begin with Curl as opposed to HTML (I never thought the HTML syntax was pretty anyway)... another reason why I think Curl should consider targetting the younger generation.
So in short, if Curl Surge is included as a plugin packaged in the basic install of Netscape and IE for every platform, free of charge, I think over 85% of Curl's problems would be solved.