What kinda KoolAide have these folks been drinking that they think sites are going to pay them money based on transmission volumes. The monthly minimum is also a big joke. Have these people read a newspaper lately? Web shops aren't exactly swimming in cash. Okay end of rant. This thing is Dead on Arrival.
Well... those poor web dev shops seem to have enough to outfit everyone with Dreamweaver, Photoshop, and all sorts of other web applications.
If you want to them to save money, you'll have to convince them to switch back to Notepad and vi.:)
OK, from some of the reactions, you might think that the article read, "Uncle Tim Declares Web Over, Go Home." Let's start from the beginning.
I hope that people realize that the current paradigm of the WWW is workable but has flaws. HTML is in fact a very limiting paradigm that severely limits your range of expression. For many applications this is not only bearable but good. Limitations can be advantages, in terms of security, for example. You don't necessarily want you.doc to be a full executable... oops, did I mention that?:)
But frankly, the science-fiction vision should be more along the lines of easy loading of networked software that looks good, performs well, and has the power that I expect from a desktop application. Does HTML + JS fulfill that task? No, it doesn't. Reload is a silly paradigm for refreshing content. Does Java? Maybe, but it depends on who you ask.
The Curl language is an entrant into the field of client-side computing with some advantages and disadvantages. Let's visit a couple of points raised to date in this discussion:
1) Client-side computing. HTML is a form of client-side computing: the client has to render the markup, right? It's not really CSC, but it is a mark near the edge of the spectrum. All operations involving two+ computers involves interactions between them, and there are operations that are better suited for one or the other. E.g. databases on the server, graphics on the client. Curl language is a powerful client-side language, so better lets YOU, the developer, choose where any given operation should take place. Isn't that a plus?
2) Integration. They say you can use the Curl language with EMBED. You can create source code on the fly with server scripts in any language and pass them down normally. See the various.jsp comments. This leads into point 3.
3) Content and markup. There is nothing forcing you to mix the two, but you have to option to. This allows you to integrate with existing systems that assume markup. Or you can write a rendering system that pulls down pure XML. Your choice.
4) Editors. Note that they have an emacs mode in the Tools section of their Web site...
(Plus, anonymous procedures are the bomb.:-) Try them, you'll like them.)
In other words, we should be arguing about whether this new (though under development for years) client-side technology is a good realization of client-side technology, not dismissing it offhand because it is not HTML. HTML is HTML, and is not going away anytime soon... in any of its countless flavors/versions/acronymns. But maybe it's not the best for every task. I think there is also room in 'computing space' for an integrated language that does JS++--+-+ and friends one better. Legacy solutions are not always preferable just because they already work, albeit poorly.
Slashdot Mirror
Well... those poor web dev shops seem to have enough to outfit everyone with Dreamweaver, Photoshop, and all sorts of other web applications.
If you want to them to save money, you'll have to convince them to switch back to Notepad and vi. :)
I hope that people realize that the current paradigm of the WWW is workable but has flaws. HTML is in fact a very limiting paradigm that severely limits your range of expression. For many applications this is not only bearable but good. Limitations can be advantages, in terms of security, for example. You don't necessarily want you .doc to be a full executable... oops, did I mention that? :)
But frankly, the science-fiction vision should be more along the lines of easy loading of networked software that looks good, performs well, and has the power that I expect from a desktop application. Does HTML + JS fulfill that task? No, it doesn't. Reload is a silly paradigm for refreshing content. Does Java? Maybe, but it depends on who you ask.
The Curl language is an entrant into the field of client-side computing with some advantages and disadvantages. Let's visit a couple of points raised to date in this discussion:
1) Client-side computing. HTML is a form of client-side computing: the client has to render the markup, right? It's not really CSC, but it is a mark near the edge of the spectrum. All operations involving two+ computers involves interactions between them, and there are operations that are better suited for one or the other. E.g. databases on the server, graphics on the client. Curl language is a powerful client-side language, so better lets YOU, the developer, choose where any given operation should take place. Isn't that a plus?
2) Integration. They say you can use the Curl language with EMBED. You can create source code on the fly with server scripts in any language and pass them down normally. See the various .jsp comments. This leads into point 3.
3) Content and markup. There is nothing forcing you to mix the two, but you have to option to. This allows you to integrate with existing systems that assume markup. Or you can write a rendering system that pulls down pure XML. Your choice.
4) Editors. Note that they have an emacs mode in the Tools section of their Web site...
(Plus, anonymous procedures are the bomb. :-) Try them, you'll like them.)
In other words, we should be arguing about whether this new (though under development for years) client-side technology is a good realization of client-side technology, not dismissing it offhand because it is not HTML. HTML is HTML, and is not going away anytime soon... in any of its countless flavors/versions/acronymns. But maybe it's not the best for every task. I think there is also room in 'computing space' for an integrated language that does JS++--+-+ and friends one better. Legacy solutions are not always preferable just because they already work, albeit poorly.