3 ms·

I was web JS dev for a long time, didn't really touch any other platforms for 2 years (except for small scripts and automation, nothing big). Then I started do

by fdsary 12y ago

I was web JS dev for a long time, didn't really touch any other platforms for 2 years (except for small scripts and automation, nothing big). Then I started doing CocoaTouch for a project with a friend. I can't view the source, and the tools suck ass (xcode, obj-c) but compared to Javascript and especially the frameworks for web apps, it's wonderful! The JS frameworks, all of them, make things a hundred times more complicated than they need to be. If web programming was like CocoaTouch, but with a dynamic language, it would be great. /rant

1stop 12y ago
The web, services more than 3 devices. There is added complexity when you do that. If you love cocoa so much you should checkout: http://www.cappuccino-project.org/ http://www.cappuccino-project.org/
- mattgreenrocks 12y ago
  But the complexity that emerges is not from supporting multiple devices! It comes from retrofitting everything atop a model originally designed for navigating a graph of linked documents. This is a severe deficiency in the original design, and no framework can patch it over. As developers, we're the ones left holding the pieces to an abortion of design day after day. This state of affairs is unacceptable. I remember when Swing was big. Everyone was gushing about it despite obvious flaws: non-native UI, poor startup time, horrible accessibility, and ridiculous memory consumption. Industry loves the idea of one platform-to-rule-them-all, no matter how far behind the uber-platform is. It would rather dump endless amounts of money and time into a patchwork of hacks than admit that it was wrong. We're way past due for a VM for webapps. I don't see why the VM couldn't be added as a dual to the current HTML/JS/CSS model. URIs beginning with app:// would use the new VM model. There's a shocking amount of defeatism, both by developers and institutions surrounding the tooling of webapps.
  - DougWebb 12y ago
    We've had VMs for webapps, more or less: Java Applets, Flash, Silverlight. They've all been deficient too, and Javascript on top of the DOM with HTML/CSS has won out. I don't think changing the url protocol would make a difference (and people will still want to embed apps in html pages, and interoperate with JS on those pages.) I don't know what the answer is, and I agree with you that a huge part of the problem is that trying to build web applications on a platform intended for web documents doesn't work very well. But it seems to work better than everything else we've tried.
untog 12y ago
But when you use CocoaTouch you can only deploy to Apple devices. When there's only one platform to target it's hardly surprising that it's easier to work with.
- tjohns 12y ago
  Java/Python are (arguably) easier for writing complex standalone apps, and neither of those are platform agnostic. The problem isn't that JS is cross platform and other languages aren't.
mattgreenrocks 12y ago
This is pretty much every UI system I've worked with contrasted against HTML/JS/CSS. I'll be the first to say: creating views in those systems is usually not as easy as HTML. But the coherence of the tooling makes up for it quickly. It appears the development ecosystem is optimizing itself around what lets you throw shit up as fast as possible, regardless of how coherent or painful it is to modify in the future. Time-to-market has always been a concern, but the notion of Internet-time has only accelerated things. This also explains why R&D has taken a backseat many times; we often confuse it with new products (that use the same tech).

by fdsary 12y ago

1stop 12y ago

The web, services more than 3 devices. There is added complexity when you do that. If you love cocoa so much you should checkout: http://www.cappuccino-project.org/ http://www.cappuccino-project.org/

mattgreenrocks 12y ago
But the complexity that emerges is not from supporting multiple devices! It comes from retrofitting everything atop a model originally designed for navigating a graph of linked documents. This is a severe deficiency in the original design, and no framework can patch it over. As developers, we're the ones left holding the pieces to an abortion of design day after day. This state of affairs is unacceptable. I remember when Swing was big. Everyone was gushing about it despite obvious flaws: non-native UI, poor startup time, horrible accessibility, and ridiculous memory consumption. Industry loves the idea of one platform-to-rule-them-all, no matter how far behind the uber-platform is. It would rather dump endless amounts of money and time into a patchwork of hacks than admit that it was wrong. We're way past due for a VM for webapps. I don't see why the VM couldn't be added as a dual to the current HTML/JS/CSS model. URIs beginning with app:// would use the new VM model. There's a shocking amount of defeatism, both by developers and institutions surrounding the tooling of webapps.
- DougWebb 12y ago
  We've had VMs for webapps, more or less: Java Applets, Flash, Silverlight. They've all been deficient too, and Javascript on top of the DOM with HTML/CSS has won out. I don't think changing the url protocol would make a difference (and people will still want to embed apps in html pages, and interoperate with JS on those pages.) I don't know what the answer is, and I agree with you that a huge part of the problem is that trying to build web applications on a platform intended for web documents doesn't work very well. But it seems to work better than everything else we've tried.

untog 12y ago

But when you use CocoaTouch you can only deploy to Apple devices. When there's only one platform to target it's hardly surprising that it's easier to work with.

tjohns 12y ago
Java/Python are (arguably) easier for writing complex standalone apps, and neither of those are platform agnostic. The problem isn't that JS is cross platform and other languages aren't.

mattgreenrocks 12y ago

This is pretty much every UI system I've worked with contrasted against HTML/JS/CSS. I'll be the first to say: creating views in those systems is usually not as easy as HTML. But the coherence of the tooling makes up for it quickly. It appears the development ecosystem is optimizing itself around what lets you throw shit up as fast as possible, regardless of how coherent or painful it is to modify in the future. Time-to-market has always been a concern, but the notion of Internet-time has only accelerated things. This also explains why R&D has taken a backseat many times; we often confuse it with new products (that use the same tech).