11 ms·

There's no way yet another webapp framework, no matter how close it emulates the desktop, is going to gain lots of traction when it mandates users to use... O

There's no way yet another webapp framework, no matter how close it emulates the desktop, is going to gain lots of traction when it mandates users to use... Objective-J and JavaScript. Seriously: being on your high horses and all is fine and well but your article is an oversimplification as to how the web works and as to what devs need and want. For example lately I've been very interested in flapjax (FRP UI) and webfui (Clojure / ClojureScript with automated synchronization between the client and the server). Functional programming and FRP UI may be the way forward. I'm not saying it is but I'm saying it may. What does Cappunico have to offer from the standpoint of determinism and reproducibility? Seen from a sufficiently distant paradigm, any web framework is the old, broken, inneficient way of doing things. Even your beloved Cappunico which you wasted so many time on. Cappunico is a failure. It doesn't have to do with you being too intelligent and having figured out things earlier than others. It's just that there are many who devs do not want Objective-C / JavaScript and who want instead something really disruptive. As long as the one really disruptive thing doesn't come along, there shall be competition between lesser solutions (which Cappucino being one) Deal with it.

jonsterling 14y ago
This, so much. Randy's probably right about how silly all the tiny reinventions of UI frameworks are. And, though I'm generally unsympathetic to claims that a project is a failure because people don't want to learn the tools, I think it's safe to say here that asking people to use a language that's only marginally less horrible than JavaScript is not going to be a win from any perspective. But he fails to realize that doing UI in a Cocoa-like framework is totally fucked (to be clear, I do Cocoa touch for a living; I'm speaking from experience). I'd be making an understatement if I said I was unexcited about Cappuccino because it fails to even approach solving any of the truly important problems of UI work, which are (as you hinted) less about "can I make the table scroll quickly" and more about "can I decouple this monstrous mess of data, dependent requests, and presentation". As you note, FRP looks like a step in the right direction toward solving that problem. Traditional Cocoa-like approaches are a step backwards in that area, not forwards.
- johnbender 14y ago
  I read the post differently. I think he was simply pointing out the fact that we've stagnated at the same level of abstraction in the web space for a long time. Cappuccino is just the example he's using to point out where we were relative to where we are and in that light it's almost a regression. For the purposes of his larger argument, the way that Cappuccino delivered its abstractions (Objective-J) isn't as important as what it allowed you to do with the web.
  - npsimons 14y ago
    Second this; while I'm not a web dev, I do bump into it occasionally, and it pains me any time I see someone re-re-re-inventing the wheel, often badly. I don't know about Obj-J or Cappuccino, but just the OP's comments about modules had me nodding in agreement. Another related example, I recently learned of H2 (http://www.h2database.com/html/main.html http://www.h2database.com/html/main.html) and I honestly had to ask myself, why is this needed? If you want an embedded SQL DB why not just use SQLite? If you want a full featured enterprise SQL DB, why not just use PostgreSQL? And don't even get me started about Walyand/Mir as opposed to Xorg, or the whole debacle of disabling separate /usr because of rewriting things like init to use glib and other non-base system dependencies. The hubris, lack of knowledge of history, lack of foresight, and just plain lack of professionalism (to put it politely) are staggering.
    - pifflesnort 14y ago
      > Another related example, I recently learned of H2 (http://www.h2database.com/html/main.html http://www.h2database.com/html/main.html) and I honestly had to ask myself, why is this needed? If you want an embedded SQL DB why not just use SQLite? SQLite is native C, H2 is Java. There are significant deployment and potential stability advantages to not using native binaries in your Java software. There have been some neat hacks to get sqlite running under Java, including using a tool that translates MIPS binaries to run under the JVM, allowing the use of libsqlite as 'native Java' code: http://nestedvm.ibex.org/ http://nestedvm.ibex.org/ This is, however, not something you'd likely want to use unless you absolutely need to interoperate with sqlite's data format.
Trufa 14y ago
Seriously. Is he saying that a product failing is the fault of customers? That's simply ridiculous. No matter how you put it, one way or another it is ALWAYS you fault, I don't even know what it might be the problem, but it's your fault.
demian 14y ago
He can blame the technicians for being lazy or stupid, and he does it, but the fact remains, they didn't wanted to use his tech. Some front-end devs are technicians that need to generate value quickly, and most can't afford investing time in a new complex system that may disappear tomorrow. If there are no clear advantages on the business side that justifies the investment, then there is no pressure to the front-end devs to do it. Good engineering also means optimizing technical designs for the usage of the technology in order to reduce costs. That includes factoring in the skills of the technicians that are going to use the tech (and the cost of training them).
josteink 14y ago
There's no way yet another webapp framework, no matter how close it emulates the desktop, is going to gain lots of traction My objection is right here. No need to mix in the Objective-J at all. Microsoft's ASP.NET tried to do this thing, to a surprising amount of success. The context then ofcourse was "Web 1.0" pre-Digg internet and the only other "big thing" being PHP. Microsoft managed to take the whole "Draw a GUI in Visual Studio and it's a done app" thing and take it to the web, much like it originally defined Windows-programming with Visual Basic. It was an immense success and very cool. Then Web 2.0 (as much as I hate that term) came and changed the game. Then not working on the raw metal became an obstacle to making ASP.NET do all those cool things which everyone else was doing. It's killer feature (not having to know HTML) became it's Achilles Heel. It's abstractions became a hinderance to all the things you actually knew how to do once the framework got out of your way. I may be a tad pessimistic and cynical, but I doubt a framework whose main goal is to give you a non-webby workspace will be a long term success when you're actually working on the web. Microsoft learned that (too late?) and have tried to remedy the situation with ASP.NET MVC, but by the time that became useful, it seems lots of .NET developers went off to find cool stuff elsewhere. A new framework like that, right now, seems like an utterly dead end.
- georgemcbay 14y ago
  Every time I see someone talking about using JavaScript as working "on the raw metal" I die a little bit inside. I'm joining OP's web haters club, if he starts one.
  - criley 14y ago
    "I die a little bit inside." Every time I hear a programmer condescend towards other programmers for using a higher level language, I also die a little bit inside. How is javascript not the "metal" of the web? It's a core part of the modern web experience upon which many libraries and frameworks have been built. I don't understand why that analogy is bad and is worthy of your condescension. Are you just being condescending to the entire web paradigm in general?
    - 14y ago
JPKab 14y ago
He didn't even mention the Dojo Toolkit. Dojo has all of the challenges Cappucino faces, except that its all Javascript, as opposed to Objective J. Dojo has the awesome table grid, the widgets, all of that. I don't use it anymore, but it was pretty powerful on the project I uesed it on.
IheartApplesDix 14y ago
But... Google New Thing!
haddr 14y ago
although it seems to be "yet another web framework", be careful when you try to reject it only because of that. Web frameworks happen because people try to leverage their existing knowledge, skills or codebase in a web domain. i.e. GWT & Vaadin are web frameworks where you use java and there is literally no need to know JS/HTML/CSS to create some really nice web apps that perform well. I don't want to say that you don't need JS/HTML/CSS knowlede to build web app. But those frameworks allow people to be productive with almost no such skills.
- guard-of-terra 14y ago
  "you don't need JS/HTML/CSS knowlede" But what would you do when it breaks? Or when a change of behavior asked that is not supported by the framework out of box?
sshumaker 14y ago
If you actually bothered to read his post, he was actually using ember.js as his example, which is decidedly not written in Objective-J. It's plain javascript with handlebars templates.
deleted 14y ago
[deleted]

jonsterling 14y ago

This, so much. Randy's probably right about how silly all the tiny reinventions of UI frameworks are. And, though I'm generally unsympathetic to claims that a project is a failure because people don't want to learn the tools, I think it's safe to say here that asking people to use a language that's only marginally less horrible than JavaScript is not going to be a win from any perspective. But he fails to realize that doing UI in a Cocoa-like framework is totally fucked (to be clear, I do Cocoa touch for a living; I'm speaking from experience). I'd be making an understatement if I said I was unexcited about Cappuccino because it fails to even approach solving any of the truly important problems of UI work, which are (as you hinted) less about "can I make the table scroll quickly" and more about "can I decouple this monstrous mess of data, dependent requests, and presentation". As you note, FRP looks like a step in the right direction toward solving that problem. Traditional Cocoa-like approaches are a step backwards in that area, not forwards.

johnbender 14y ago
I read the post differently. I think he was simply pointing out the fact that we've stagnated at the same level of abstraction in the web space for a long time. Cappuccino is just the example he's using to point out where we were relative to where we are and in that light it's almost a regression. For the purposes of his larger argument, the way that Cappuccino delivered its abstractions (Objective-J) isn't as important as what it allowed you to do with the web.
- npsimons 14y ago
  Second this; while I'm not a web dev, I do bump into it occasionally, and it pains me any time I see someone re-re-re-inventing the wheel, often badly. I don't know about Obj-J or Cappuccino, but just the OP's comments about modules had me nodding in agreement. Another related example, I recently learned of H2 (http://www.h2database.com/html/main.html http://www.h2database.com/html/main.html) and I honestly had to ask myself, why is this needed? If you want an embedded SQL DB why not just use SQLite? If you want a full featured enterprise SQL DB, why not just use PostgreSQL? And don't even get me started about Walyand/Mir as opposed to Xorg, or the whole debacle of disabling separate /usr because of rewriting things like init to use glib and other non-base system dependencies. The hubris, lack of knowledge of history, lack of foresight, and just plain lack of professionalism (to put it politely) are staggering.
  - pifflesnort 14y ago
    > Another related example, I recently learned of H2 (http://www.h2database.com/html/main.html http://www.h2database.com/html/main.html) and I honestly had to ask myself, why is this needed? If you want an embedded SQL DB why not just use SQLite? SQLite is native C, H2 is Java. There are significant deployment and potential stability advantages to not using native binaries in your Java software. There have been some neat hacks to get sqlite running under Java, including using a tool that translates MIPS binaries to run under the JVM, allowing the use of libsqlite as 'native Java' code: http://nestedvm.ibex.org/ http://nestedvm.ibex.org/ This is, however, not something you'd likely want to use unless you absolutely need to interoperate with sqlite's data format.

Trufa 14y ago

Seriously. Is he saying that a product failing is the fault of customers? That's simply ridiculous. No matter how you put it, one way or another it is ALWAYS you fault, I don't even know what it might be the problem, but it's your fault.

demian 14y ago

He can blame the technicians for being lazy or stupid, and he does it, but the fact remains, they didn't wanted to use his tech. Some front-end devs are technicians that need to generate value quickly, and most can't afford investing time in a new complex system that may disappear tomorrow. If there are no clear advantages on the business side that justifies the investment, then there is no pressure to the front-end devs to do it. Good engineering also means optimizing technical designs for the usage of the technology in order to reduce costs. That includes factoring in the skills of the technicians that are going to use the tech (and the cost of training them).

josteink 14y ago

There's no way yet another webapp framework, no matter how close it emulates the desktop, is going to gain lots of traction My objection is right here. No need to mix in the Objective-J at all. Microsoft's ASP.NET tried to do this thing, to a surprising amount of success. The context then ofcourse was "Web 1.0" pre-Digg internet and the only other "big thing" being PHP. Microsoft managed to take the whole "Draw a GUI in Visual Studio and it's a done app" thing and take it to the web, much like it originally defined Windows-programming with Visual Basic. It was an immense success and very cool. Then Web 2.0 (as much as I hate that term) came and changed the game. Then not working on the raw metal became an obstacle to making ASP.NET do all those cool things which everyone else was doing. It's killer feature (not having to know HTML) became it's Achilles Heel. It's abstractions became a hinderance to all the things you actually knew how to do once the framework got out of your way. I may be a tad pessimistic and cynical, but I doubt a framework whose main goal is to give you a non-webby workspace will be a long term success when you're actually working on the web. Microsoft learned that (too late?) and have tried to remedy the situation with ASP.NET MVC, but by the time that became useful, it seems lots of .NET developers went off to find cool stuff elsewhere. A new framework like that, right now, seems like an utterly dead end.

georgemcbay 14y ago
Every time I see someone talking about using JavaScript as working "on the raw metal" I die a little bit inside. I'm joining OP's web haters club, if he starts one.
- criley 14y ago
  "I die a little bit inside." Every time I hear a programmer condescend towards other programmers for using a higher level language, I also die a little bit inside. How is javascript not the "metal" of the web? It's a core part of the modern web experience upon which many libraries and frameworks have been built. I don't understand why that analogy is bad and is worthy of your condescension. Are you just being condescending to the entire web paradigm in general?
  - 14y ago

JPKab 14y ago

He didn't even mention the Dojo Toolkit. Dojo has all of the challenges Cappucino faces, except that its all Javascript, as opposed to Objective J. Dojo has the awesome table grid, the widgets, all of that. I don't use it anymore, but it was pretty powerful on the project I uesed it on.

IheartApplesDix 14y ago

But... Google New Thing!

haddr 14y ago

although it seems to be "yet another web framework", be careful when you try to reject it only because of that. Web frameworks happen because people try to leverage their existing knowledge, skills or codebase in a web domain. i.e. GWT & Vaadin are web frameworks where you use java and there is literally no need to know JS/HTML/CSS to create some really nice web apps that perform well. I don't want to say that you don't need JS/HTML/CSS knowlede to build web app. But those frameworks allow people to be productive with almost no such skills.

guard-of-terra 14y ago
"you don't need JS/HTML/CSS knowlede" But what would you do when it breaks? Or when a change of behavior asked that is not supported by the framework out of box?

sshumaker 14y ago

If you actually bothered to read his post, he was actually using ember.js as his example, which is decidedly not written in Objective-J. It's plain javascript with handlebars templates.

deleted 14y ago

[deleted]