5 ms·

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

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.
  - npsimons 14y ago
    I noticed that the fully native Java was a big selling point on H2. Admittedly, I'm not doing much Java these days (slight understatement), but I was under the impression that the Java interfaces to SQLite were fairly mature? Top two links in Google go to a very informative SO answer with lots of options and SQLJet. Bad sign though that "apt-cache search sqlite | grep -i java" gives no results on Debian stable. I'll grant that fully native Java is a compelling reason in some use cases ;) I'm now curious what they use for SQLite on Android, as I know fairly well that it's used all over the place there.
    - ebiester 14y ago
      H2, more than anything else, is great for testing. It can emulate oracle and DB2 syntax, among others, to allow us to reasonably approximate a running system on our own machines, then test against the big database (which is much slower) at a later stage. Fully native java and an in-memory implementation mean that we can very quickly implement it in our systems.
      - markokrajnc 14y ago
        I second this. We use H2 in our JUnit test cases a lot, because it is the fastest open-source in memory Java DB (tests are finished very fast).
zoul 14y ago
This is my feeling, too. I do iOS development for living and whenever I have to do some web programming, I feel like writing in assembly, having to micro-manage things I should not care about. It pains me that Cappuccino has received so little interest, for despite all its possible drawbacks it represents a very interesting path for future web programming.
- erikpukinskis 14y ago
  > whenever I have to do some web programming, I feel like writing in assembly, having to micro-manage things I should not care about. That applies in the opposite direction too. Native programming seems to involve jumping through insane hoops just to do simple things: Like "put some text on the screen, this part is bold". Or "open this web page". Or "put these things next to each other, with 10px in between, unless the screen is a little narrower, then put the second one below with no margins". Or "I want to play with the layout of this every day for the next month, have the new layout download every time someone uses this app". I can write complete, ready-to-distribute web apps that do those things in 1-3 lines of code. Doing so in iOS takes many layers of indirection. Look at something like Ember.js. The abstractions being put in place are fascinating. Or CSS. It's is an incredibly powerful abstraction on something that iOS just scratches the surface of. The truth is, both the web and iOS have evolved to deal with specific pain points. Some things that are easy on one are hard on the other. This idea that web programming is under-abstracted seems really narrow-minded to me.
laumars 14y ago
Have we stagnated? Or has the rise of lower powered web-enabled devices forced us to re-think the classic rule of programming (ie that applications can progressively increase their system requirements as PCs are progressively becoming more powerful to handle the load). Let's remember that even as recently as 2-3 years ago, top end phones and tablets were single core ARM processors clocked at ~1GHz. And devices of that spec are still in wide spread use even now. The point of the HTML is that it's an open standard which should work on any internet device regardless of platform, patents and what not. While I admire the ambition of the guys who push the envelope of what the web can do, they often forget that everyday sites also need to cater for low end devices used by everyday folk.
- frogpelt 14y ago
  This trend is likely to continue as the billion or so potential customers in emerging markets start getting their hands on affordable smartphones. The idea right now for telecoms and device manufacturers is more about getting their stuff in as many people's hands as possible, not about whether they can replace a screaming desktop with a handheld.
  - laumars 14y ago
    Totally. And this is the right attitude as well. Let make information available to everyone; then we can worry about making those sites fancier than a strippers underwear draw.
- lazyjones 14y ago
  We have stagnated because new APIs, frameworks, environments appear at a rate too high for anyone to build meaningful things on top of them before they become obsolete again. We also wait longer until we adopt these new technologies, therefore narrowing the time frame to actually use them even more. Low end devices are a good point, my main gripe with all these frameworks is that they make it very easy to break many conventions of the web (URLs no longer work as intended, extra efforts is needed to make the pages crawlable etc.).
Joeri 14y ago
We're stuck at the same level of abstraction because the platform forces us to. The base html/css controls are incredibly simplistic, to the point of being pretty much useless for building proper UI. Everyone is struggling with how to abstract their way around this fact. You have solutions like gwt, cappucino and extjs which build custom ui components that behave properly, ad the infrastructure to tie them together. This works, but only if you never step outside the framework, and only if you're willing to deal with bloat, which sucks. Then you have frameworks which just give you the infrastructure, not the custom ui components, like ember or backbone. That also works, but because html's core controls are horrible the only way to get a great ui out of that is to build really custom ui, essentially rebuilding what the complicated frameworks already provide out of the box, which sucks. And then you have one-shot solutions that try to bring just one or a few ui elements to the web, trying their best to fit into the raw platform. That also works, but because the raw platform is so painful to use, it doesn't scale. Really, the problem is that html/css/js is the wrong base for building abstractions on. I have great hopes for shadow dom and web components, but that's only the beginning of what we need. The platform itself needs to evolve a great deal to make building high-quality ui something that doesn't lock you into a vendor's toolset. Personally i chose extjs and am waiting it out until the platform matures underneath it. I'd like to see the extjs codebase evaporate as parts of it get replaced by native code, until it's nothing but syntactical sugar on top of a rich base platform. That's going to be a while though.
- ttrt 14y ago
  Thanks for a fascinating comment! Do you have any opinion on the parenscript project? http://common-lisp.net/project/parenscript/ http://common-lisp.net/project/parenscript/

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.
- npsimons 14y ago
  I noticed that the fully native Java was a big selling point on H2. Admittedly, I'm not doing much Java these days (slight understatement), but I was under the impression that the Java interfaces to SQLite were fairly mature? Top two links in Google go to a very informative SO answer with lots of options and SQLJet. Bad sign though that "apt-cache search sqlite | grep -i java" gives no results on Debian stable. I'll grant that fully native Java is a compelling reason in some use cases ;) I'm now curious what they use for SQLite on Android, as I know fairly well that it's used all over the place there.
  - ebiester 14y ago
    H2, more than anything else, is great for testing. It can emulate oracle and DB2 syntax, among others, to allow us to reasonably approximate a running system on our own machines, then test against the big database (which is much slower) at a later stage. Fully native java and an in-memory implementation mean that we can very quickly implement it in our systems.
    - markokrajnc 14y ago
      I second this. We use H2 in our JUnit test cases a lot, because it is the fastest open-source in memory Java DB (tests are finished very fast).

zoul 14y ago

This is my feeling, too. I do iOS development for living and whenever I have to do some web programming, I feel like writing in assembly, having to micro-manage things I should not care about. It pains me that Cappuccino has received so little interest, for despite all its possible drawbacks it represents a very interesting path for future web programming.

erikpukinskis 14y ago
> whenever I have to do some web programming, I feel like writing in assembly, having to micro-manage things I should not care about. That applies in the opposite direction too. Native programming seems to involve jumping through insane hoops just to do simple things: Like "put some text on the screen, this part is bold". Or "open this web page". Or "put these things next to each other, with 10px in between, unless the screen is a little narrower, then put the second one below with no margins". Or "I want to play with the layout of this every day for the next month, have the new layout download every time someone uses this app". I can write complete, ready-to-distribute web apps that do those things in 1-3 lines of code. Doing so in iOS takes many layers of indirection. Look at something like Ember.js. The abstractions being put in place are fascinating. Or CSS. It's is an incredibly powerful abstraction on something that iOS just scratches the surface of. The truth is, both the web and iOS have evolved to deal with specific pain points. Some things that are easy on one are hard on the other. This idea that web programming is under-abstracted seems really narrow-minded to me.

laumars 14y ago

Have we stagnated? Or has the rise of lower powered web-enabled devices forced us to re-think the classic rule of programming (ie that applications can progressively increase their system requirements as PCs are progressively becoming more powerful to handle the load). Let's remember that even as recently as 2-3 years ago, top end phones and tablets were single core ARM processors clocked at ~1GHz. And devices of that spec are still in wide spread use even now. The point of the HTML is that it's an open standard which should work on any internet device regardless of platform, patents and what not. While I admire the ambition of the guys who push the envelope of what the web can do, they often forget that everyday sites also need to cater for low end devices used by everyday folk.

frogpelt 14y ago
This trend is likely to continue as the billion or so potential customers in emerging markets start getting their hands on affordable smartphones. The idea right now for telecoms and device manufacturers is more about getting their stuff in as many people's hands as possible, not about whether they can replace a screaming desktop with a handheld.
- laumars 14y ago
  Totally. And this is the right attitude as well. Let make information available to everyone; then we can worry about making those sites fancier than a strippers underwear draw.
lazyjones 14y ago
We have stagnated because new APIs, frameworks, environments appear at a rate too high for anyone to build meaningful things on top of them before they become obsolete again. We also wait longer until we adopt these new technologies, therefore narrowing the time frame to actually use them even more. Low end devices are a good point, my main gripe with all these frameworks is that they make it very easy to break many conventions of the web (URLs no longer work as intended, extra efforts is needed to make the pages crawlable etc.).

Joeri 14y ago

We're stuck at the same level of abstraction because the platform forces us to. The base html/css controls are incredibly simplistic, to the point of being pretty much useless for building proper UI. Everyone is struggling with how to abstract their way around this fact. You have solutions like gwt, cappucino and extjs which build custom ui components that behave properly, ad the infrastructure to tie them together. This works, but only if you never step outside the framework, and only if you're willing to deal with bloat, which sucks. Then you have frameworks which just give you the infrastructure, not the custom ui components, like ember or backbone. That also works, but because html's core controls are horrible the only way to get a great ui out of that is to build really custom ui, essentially rebuilding what the complicated frameworks already provide out of the box, which sucks. And then you have one-shot solutions that try to bring just one or a few ui elements to the web, trying their best to fit into the raw platform. That also works, but because the raw platform is so painful to use, it doesn't scale. Really, the problem is that html/css/js is the wrong base for building abstractions on. I have great hopes for shadow dom and web components, but that's only the beginning of what we need. The platform itself needs to evolve a great deal to make building high-quality ui something that doesn't lock you into a vendor's toolset. Personally i chose extjs and am waiting it out until the platform matures underneath it. I'd like to see the extjs codebase evaporate as parts of it get replaced by native code, until it's nothing but syntactical sugar on top of a rich base platform. That's going to be a while though.

ttrt 14y ago
Thanks for a fascinating comment! Do you have any opinion on the parenscript project? http://common-lisp.net/project/parenscript/ http://common-lisp.net/project/parenscript/