
I’m done with the web - paulirish
http://randyluecke.tumblr.com/post/45915323813/im-done-with-the-web
======
jacquesm
> The community has tossed out everything we’ve learned from the last 30 years
> of building applications in favor of being able to put something together
> quickly with complete disregard for maintainability or extendability.

That's spot on. You can add in to that that all the lessons of the _process_
of developing software have also been discarded and are slowly being re-
learned.

It is as if with the birth of the web there was a complete reboot of the IT
industry which accidentally also re-formatted the drive that held our
knowledge about how you go about software development (which is different from
knowledge about what it is that you are building, and different still from the
technical details of your implementation).

On top of all that the web is incredibly messy.

~~~
corresation
_It is as if with the birth of the web there was a complete reboot of the IT
industry_

The web won. It fought a battle against many foes, and it came out on top.

Re-read that again and seriously think about it, because comments such as
yours don't accept that simple reality. Do you contest it? Do you argue that
the web somehow circumvented the competition?

For 15 years I've been promoting the web with groups that I've consulted with
or led. For 15 years competitors have arisen with various alternative
strategies, including MFC applications, Java Applets and then Web Start
solution, .NET Winforms and then .NET WPF applications, Flex and Flash
applications, Silverlight applications, and on and on.

And they all fell by the wayside. They lacked in features. They lacked in
agility.

The only competitor that has made serious inroads are native apps on mobile
devices, eking out an advantage due to the unique profile and unique input
techniques of those devices, and of course gaming given that the web had no
interest in gaming. The web is adapting.

If the advantages that you hold are true (in another post you argue that we
salivate over stuff that was trivial 20 years ago. Yet ignore that we do
things on the web that are just incredibly rich with but a few lines of markup
and some ancillary code), those apps should have long devastated the web,
teams making secure, easy to construct apps that run circles over those poor
web developers.

~~~
pifflesnort
> _The web won. It fought a battle against many foes, and it came out on top._

It won _what_ , exactly? The war against Gopher for presentation of hypertext
documents and information display? There's more to heaven and earth than data
presentation and consumption.

The examples of genuinely great web _applications_ are few and far between, if
not near non-existent. Are Google Apps _really_ the best the web has to offer?

Cappuccino provided one example of how to move the browser past the shackles
of the traditional HTML/JS/CSS and into a world where developers could work
with more accurate abstractions that actually represented the problem domains
of application development.

This lesson has essentially been ignored, tossing out 3+ decades of experience
our industry has in building _applications_.

~~~
corresation
_There's more to heaven and earth than data presentation and consumption._

I do my banking in a browser. I do my email in a browser. I manage photos in a
browser. I manage relationships in a browser. I do my taxes in a browser. I
order goods in a browser. I ship goods in a browser. I reserve items at the
library in a browser. I watch movies in a browser. I listen to music in a
browser. I push apps to my smartphone in a browser. I get directions in a
browser. I find phone numbers in a browser. I _phone people_ in a browser. I
video conference in a browser...

I can go on and on all day. If you really want to argue that the web is a
surrogate for Gopher, this conversation is futile.

~~~
pifflesnort
> _I do my banking in a browser. I do my email in a browser. I manage photos
> in a browser. I manage relationships in a browser. I do my taxes in a
> browser. I order goods in a browser. I ship goods in a browser. I reserve
> items at the library in a browser. I watch movies in a browser. I listen to
> music in a browser. I push apps to my smartphone in a browser. I get
> directions in a browser. I find phone numbers in a browser. I phone people
> in a browser. I video conference in a browser..._

I'd be interested to hear how those tools stack up against their native (or
cappuccino) counter-parts, because implicit in your argument is that all these
attempts to extend the web into the application space are better (and have
'won') over traditional approaches to application development, which I can't
say has been my experience, even for the 'best-in-breed' solutions such as
Google Apps.

Personally, I've found the surge of interest in native development via mobile
to be invigorating, since it has meant a resurgence in applications that put
user experience ahead of dogma (or even cost). I can hope that this continues
to carry over to the desktop and other spheres over the next 5 years.

~~~
sopooneo
The success of the web makes horrifyingly apparent how important ubiquity and
ease of deployment are. In they quest for users, they trump almost everything
else.

------
STRML
Personally, batteries-included frameworks like Cappuccino scare me off for a
few reasons:

1\. I have to learn Objective-J. I've been web programming for years and I've
become really good at Javascript. I even enjoy it. Other frameworks don't
require learning a new language.

2\. Time spent learning Cappuccino is only good for programming Cappuccino
apps. Time spent in micro frameworks generally translates to other frameworks.
Backbone is so bare-metal that it is very easy for Javascript programmer to
feel comfortable.

3\. Batteries-included frameworks often have "their" way of doing things that
are not extensible. This can lead to awkward situations where you need
behavior that is just not possible without monkey-patching the hell out of the
frameworks and getting yourself stuck on a particular version.

4\. I can't speak to Cappuccino, but a similar framework, ExtJS, has (for 4
major versions and nearly 10 years) lacked a build and minification system
that didn't suck. This means you must include all dependencies, leading to
1.2MB+(minified!) blobs of JS that can take upwards of 10 seconds or more to
load even on fast connections. For business-class apps running on B2B
contracts, that might be fine. For public-facing webapps, this is murder.

5\. People like micro frameworks because they can use every brand new & shiny
piece of JS that shows up on the web without worrying about compatibility. And
they can use {HTML5 feature} without worrying about compatibility. I'm sure
Cappuccino does a better job than most when it comes to this sort of thing,
but what happens when the devs lose interest? Years of "Objective-J"
experience go to waste.

~~~
randomdata
> _I have to learn Objective-J._

Objective-J is a Javascript superset, so everything you know about Javascript
is still available to you. It will take minutes to learn the additions. The
language is not really the problem.

Its the framework that will take quite some time to learn. There are a _ton_
of interfaces to work with. I suspect that is why you feel more comfortable
with something like Backbone, because it basically brings nothing to the
table, so there is very little to learn.

> _Time spent learning Cappuccino is only good for programming Cappuccino
> apps._

Not exactly. The API is nearly identical to Cocoa on the Mac, and very similar
to Cocoa Touch on iOS. If you know any of the three, you should be able to
transition between the frameworks without much trouble. You can even use
Apple's own Interface Builder to build your Cappuccino interfaces, to give you
some idea of how similar they really are. There is also GNUStep, but that's
probably not a big selling point, granted.

Perhaps the time spent is less valuable if you have no interaction with Apple
devices, but I suspect a lot of people interested in web development also have
an interest in mobile development where knowing how to develop for iOS does
have quite a bit of value.

~~~
STRML
You're right. I'm not an Apple dev so I don't see much of the utility but I'm
sure there are many who do. Certainly, if I were a native iOS programmer
looking to do a rich web app, Cappuccino would be my first choice.

All of these frameworks fulfill a need (otherwise they wouldn't exist). I
think the author expected that, because Cappuccino filled his needs so well,
that it would fill everyone else's. He is now venting his frustration that
this is not true.

~~~
randomdata
My takeaway from it was not him venting about nobody using Cappuccino, it was
that developers wouldn't spend even a small amount of time to evaluate it in
the first place.

"if it's going to take me at least a day or two before I begin to understand,
how long is it going to take the rest of my team?"
(<https://news.ycombinator.com/item?id=5411474>)

If you have not spent that day or two to understand, how can you know it does
not fill your needs?

I actually do not think Cappuccino is a good fit for a lot of the places
Backbone and the like are being used. The unfortunate part comes when people
will still use Backbone where Cappuccino is the right tool just because
Objective-J "looks scary", or some other non-technical reason of emotion.

------
rolleiflex
>Ember is very close to the “micro” side of things, but at a “whopping” 49KB
(less than a second download on a dial-up internet connection

Chances are that you probably never had a dial-up connection. 49KB on dial-up
generally takes around 10 seconds.

Besides this point, the accusatory tone towards front-end developers and 'the
rest of the world' that did not understand you isn't helping to get your point
across. You were in the wrong place in wrong time. It happens. Move on. There
are better things to do, and bitterness only hurts yourself.

~~~
Cushman
Perhaps someone forgot to multiply by 8.

~~~
masklinn
And didn't take delays in account, half a second used to be _my ping_ on dial-
up.

------
fusiongyro
While I agree with the main thrust of the article, in my opinion what killed
Cappuccino was that it was big, weird, and rather opaque. Did it ever occur to
you that maybe it was just too much? One thing I liked about jQuery was that
my webpages didn't have to become applications, they could just be webpages
with behavior. It worked within the paradigm, you might say, and that's what I
wanted and it's what my clients wanted too. SproutCore didn't see heavy
adoption either. GWT probably had more than both, but it wasn't the #1 or #2
Java framework.

I wanted to love Cappuccino, but I didn't know Cocoa or Objective-C. Your team
was spread so thin I remember wondering--how much time are they putting into
Objective-J, how much into Cappuccino, how much into 280 Slides? When 280
Slides shut down, it looked to me (as an outsider) as the beginning of the
inevitable cascade of plug-pulling that happens when a small team realizes
they bit off more than they can chew. Imagine what it would have done to Rails
adoption if Basecamp had been shut down. It was the flagship product.

It's hard to imagine jQuery being shut down, but suppose it did. With Zepto
and everything else, it wouldn't be the end of the world for me--my investment
in it is safe. Imagine if I had written tens of thousands of lines of
Objective-J. Does this blog post make me feel like I made a safe investment?
We like light libraries over massive frameworks because light libraries really
can't take our applications down with them. You may have brought an impressive
engineering mindset to this problem, and this is a problem that deserves it,
but we're still talking about 4 years from start to finish. If you want me to
go "all in" on something that could take years of my work down in a ball of
flame, forgive me if I'm distrustful of three kids doing a startup and trying
to reinvent the world.

~~~
anonfunction
This was the comment I wanted to write.

------
Peroni
A couple of years ago a London based start-up came to me asking for help
finding a Cappuccino/Objective J developer. I pride myself at being able to
find needles in haystacks but finding a dedicated Cappuccino dev in London was
proving impossible. During a moment of desperation I fired a very simple email
to Randy asking for suggestions and I got a reply within 24 hours with a few
names suggested from the Cappuccino community who were UK based and a couple
of suggestions on what sort of developer would find the transition to
Objective J easier than others.

Randy's passion for Cappuccino was blatant and his excitement at seeing the
framework expand in the UK was admirable. The fact that someone so passionate
has become so frustrated is a shame.

Best of luck at Google Randy and thanks for taking time out to help a
stranger.

~~~
danielweber
The fact that the employer needed someone with prior Cappuccino experience is
the bigger problem.

There are a huge number of frameworks out there. Pick one, and then hire
people and have them spend a few days learning it.

Adding more and more frameworks leads to, well, relevant XKCD:
<http://xkcd.com/927/>

------
chao-
Many of the author's complaints read similar to this one:

 _Now, people compare Backbone to Cappuccino, or Ember to Rails. Cappuccino,
Backbone, and Rails all serve completely different purposes, and saying you
don’t need one because you have another is just asinine._

Three questions:

1\. Who are these people that compare those three frameworks?

2\. Why do you let them get under your skin?

3\. What does that have you do with you "being done with the web" (or web
community)?

I don't understand any of these. So some morons want to compare apples and
oranges? This has nothing to do with "the web" and crops up in all industries
and spheres of life. Welcome to humanity, enjoy your stay.

As best I can tell, my lack of empathy must come from a different definition
of "web community". When the author complains about how _The community has
tossed out everything we’ve learned from the last 30 years of building
applications in favor of being able to put something together quickly with
complete disregard for maintainability or extendability._ part of me wants to
agree with him, flip a table, and join the melee [1].

But at the same time, I was listening to the Ruby Rogues episode with Sandi
Metz last night [2]. There is a 20-minute discussion about utility of does-it-
all frameworks, their use in a project, the types of projects you use them
for, and the point at which _all projects will necessarily need to have
designed a better solution_ , or massively adapted the framework, to better
fit their problem. It's all very clear-eyed and up front about this exact
tradeoff (that is, complaint by the author). That is but one example, and I
won't belabor the thread with more.

At the end of the day, either the author is simply frustrated that it was hard
to convince people to use his project/product, or we must live in very
different "web communities".

[1]
[http://www.youtube.com/watch?feature=player_embedded&v=W...](http://www.youtube.com/watch?feature=player_embedded&v=WpkDN78P884&t=33m0s)

[2] [http://rubyrogues.com/087-rr-book-clubpractical-object-
orien...](http://rubyrogues.com/087-rr-book-clubpractical-object-oriented-
design-in-ruby-with-sandi-metz/)

------
laumars
_> The hilarious obsession with file size is the start of my frustrations with
the web community._

It's not so hilarious if you're the one paying for bandwidth when hundreds of
thousands of users are accessing your SSL site each day. Or if you're
desperately trying to pull one page up quickly while on your smart phone in a
region with sketchy (at best) mobile reception.

I'm one of those people who are obsessed with keeping file sizes to a minimum
and, quite frankly, I find it "hilarious" when developers create sites with
both a heavy bandwidth footprint and heavy CPU footprint rendering the bloody
thing just because they insist users should experience a full desktop
experience inside a web page. Those are different paradigms with different
limitations and bottlenecks. Trying to shoehorn in a desktop paradigm
(regardless of how elegant the OP might have considered Cappuccino's code) for
the web simply didn't make sense back then; and that is why his project
failed.

I also want to stress that I'm not against interactive sites. Obviously there
is a happy medium between minimal design and the OP's vision of the web.
However there have been studies that have proven that even a fraction of a
second longer page load time can drive business away from your site. And given
this and my former points, it makes considerable more sense to use more
compact libraries to begin with.

Lastly, his point about many developers being unwilling to spend a little time
learning web frameworks is something that I haven't personally encountered.
But I can agree with his frustration on that specific remark if it is true.

~~~
d4nt
Yes, the relationship between page load speed and bounce rate is well proven:
<http://blog.kissmetrics.com/loading-time/?wide=1>

------
csomar
So here is my humble opinion: I discovered Capuccino two years ago. My first
reaction was "This is amazing!". I need to learn another language, framework
and stuff. But I thought that's the price I pay. There were three things that
pulled me off, though.

1\. It's buggy (or was buggy). I don't remember the details, but I couldn't
setup few things because of bugs and the community was not there to help.

2\. It's SLOW. Unless things changed now, I tried a few examples and I can't
see how it can work. This was a huge turn-off.

3\. I'll massively depend on it. jQuery is broke? Replace it with another
library. This xxx.js library sucks? We can use another one. When using
Capuccino you are locked to their framework. Is there a bug pulling you off
from shipping? You are now screwed.

So my humble opinion is that Capuccino was not successful, at least by the
time I tried it. The founder leaving the project is another reason why no one
should have used it.

~~~
bunkat
It was number 2 that just turned me off right now. Went to look at some of
their demo apps and was met with a loading screen for 10 seconds before
anything happened. Not sure about everyone else, but I know my users are not
going to stick around long enough to even see the app.

~~~
pooriaazimi
I have a slow machine for now (2009 MBP), and Cappuccino is dog slow on it.
I'd try it again in a heartbeat once I get a faster machine, but for now, it's
literally (and I'm using that word right) unusable. A 30+ second delay after I
save a simple interface in Xcode and the changes compiling. It's just
frustrating. But if the turnaround time was less than a second, I think I
would _love_ to use something as "well-thought-out" as Cappuccino.

------
biznickman
This has to be one of the most bitter and condescending posts ever. Rather
than sucking up the fact that a project he has been putting his heart and soul
for some reason isn't gaining traction (and trying to adjust so that it can),
he blames "the web community" for all his issues. The community doesn't have a
centralized decision making system, instead, people support things that make
sense. In this case, they didn't support Cappuccino, because it didn't make
sense to them. Rather than blaming themselves though, they blame the masses.
The conclusion "screw you all, I'm joining Google" is really abrasive and
arrogant. It would have been much better if this post was phrased as: for some
reason our platform didn't work, here's what we learned.

------
cromwellian
As one of the people who worked on GWT, and have used other more structured
frameworks (Dart, Closure), I have a strong affinity for systems with good
tooling support, a consistent package management and module system, etc

However, I think what's missing is a recognition that there are different
kinds of web apps. There are "application" oriented apps, primarily single
page, large, and not content driven (gmail, docs, games, etc), and then there
are page-oriented apps, like forums, content management systems, blogs,
database backed forms/reports, etc.

The former lend them selves really well to the structured approach. You trade
off simplicity and iteration speed for more of a "on rails" experience, but it
helps for larger teams to collaborate on larger projects to have some
restrictions on freedom and some mutually agreed upon consistent behaviors.

However, the latter page-oriented apps fit in a lot better with these
microframeworks. And page oriented apps fit in with the original vision of the
Web, they are documents, they have URL addressable, RESTful, hopefully,
durable content, indexable by search engines, and linkable by anyone.

I think there is room for both and a sweet spot for different approaches. I
often use several languages for specially suited purposes, like sed/awk/Perl
for text processing, JS for small page oriented stuff or mocks, GWT for larger
apps. I would not advocate GWT for people for building progressively enhanced
page-oriented apps, even though I'm the author of GwtQuery and AngularGWT.

Using the right tool for the job often depends on context and personal
preference. A lone hacker or small team can get by with doing a large app in
hand coded JS with hand rolled build tools and module systems, but frustrate
other people coming onto the project.

There is too much, IMHO, "one above all" thinking when it comes to
development, and often, the original goals -- what the app is supposed to do
for the end user, get lost in the zeal to build a cool framework or
infrastructure for it.

------
Confusion

      This reaction to Ember just baffles me. Your day job is to 
      build a piece of web software and you can’t take a few 
      days to learn the ins and outs?
    

What compelling reason can you give me to take a few days to learn Ember and
not _insert one of a dozen alternatives_? Or should I take a few days for each
of the dozens of newfangled alternatives that pop up every year? Are a few
days even enough when you want to truly experience whether some framework is
worth it?

Get off my lawn.

------
cromwellian
The biggest problem with Web Development today, IMHO, and the biggest reason
why people desire Widget frameworks in the first place, is that the modern
browser rendering pipeline is too complex for most people to understand.

If you want to create an app which can consistently animate or scroll at
60fps, avoid jank, and random hiccups, and do cross-platform between WebKit,
Firefox, and IE9/10, you will find it enormously painful. And often, a
solution for one particular UI design won't compose cleanly with others.

How many developers use the Chrome DevTools timeline, and minimize the time
spend computing layout and the amount of repaints? How many of them arrange
for optimal use of the Compositor?

This is one of the challenges in Web developer vs iOS or Android, where the UI
performance is more predictable with fewer surprises. Hence, the desire for a
Web framework with Widgets that is "idiot proof" when it comes to high
performance. This rubs some people the wrong way because you lose flexibility
to control the look and feel in many cases and must settle for building with
out-of-the-box stuff, but the productivity benefits are undeniable.

~~~
zoul
_The biggest problem with Web Development today, IMHO, and the biggest reason
why people desire Widget frameworks in the first place, is that the modern
browser rendering pipeline is too complex for most people to understand._

It’s a huge mistake to consider Cappuccino a “widget framework”. Cappuccino’s
main point is providing the whole “web development stack”. You don’t have to
care about browser differences, about DOM trees, about HTML. You just write
against a sane, modern, high-level API, just as you would on a modern desktop
platform. The number of things to keep in your head dramatically decreases.
That’s the point.

~~~
cromwellian
I understand how Cappuccino works (I am one of the GWT authors, and I often
have to tell people the same about GWT, is it not a "widget framework"), but
what I'm saying is, from what I observe, people often spend more time
debugging CSS and HTML than they do code.

There are lots of reasons why JS needs fixing, I'm onboard with that. But
honestly, you could fix it 100%, and it would still be easier to develop
native apps on iOS/Android. 280 North's Slides for example as a great example
of what you could do, but let's not kid ourselves, it was also pretty slow.

If you look at the herculean efforts the Google Docs team went through to get
that running fast, and it's still not fast enough, I'd say there's there a lot
more work do be done on the Web-as-app-UI-renderer model side.

If it weren't for all of the other things you'd have to reinvent, and what
you'd lose from indexability and transparency, I'd almost say built a
framework on using WebGL rendering.

~~~
cromwellian
I think different people have different concepts of what smooth and buttery
feels like. Native apps have taught people to expect a mostly constant fixed
30fps or 60fps. As smooth as you think Slides was, I doubt it achieved this,
because the tooling neccessary to monitor repaint regions and framerates, not
to mention GPU compositing, wasn't available in 2008.

DOM programming is still a minefield. GPU compositing tricks is not only not
fully portable between browser rendering engines, they aren't even fully
portable across GPUs, as differing GPU restrictions like maximum texture size,
texture memory, et al, impose different limitations on the maximize size of
composited regions, how many can animate or update at once, etc.

------
lolcraft
You know, it would be cool if the text in your webpage took more than an
awkward 30% width. And putting it in a bigger font size would be the shit,
most definitely. Just saying :)

That said, this being butt-hurt about lack of adoption for your pet framework
is just fucking overreacting. Yeah, I know, it's your shit, you made it,
you're very proud, now it's personal. Bluntly: emulating a recognizable
desktop interface in the browser is a shit idea. _Your_ Mac OS emulation on a
web browser over _my_ Windows is the web equivalent of James Bond in pajamas.
Not to mention that it completely destroys brand identification, and makes
legal departments cry.

You wrote some cool stuff, it got you some fame and a job at Google. Stop
whining.

------
danielweber
_Your day job is to build a piece of web software and you can’t take a few
days to learn the ins and outs?_

Do you know how many frameworks people are pushing out there? It's a mountain.
And everyone thinks the secret to success is to be behind the latest greatest
framework. Which the world doesn't need.

I know why they do it: because being behind a framework is an excellent point
on the resume and will help you find employment, and so many employers really
suck at evaluating people. But in the wake are a whole bunch of frameworks
that some other employer is going to say "oh, you don't know
CaffeineInjecterrr? Sorry, we need someone with 2 years of experience with
it."

One reason founders complain that older people don't seem to know about the
latest framework is that we've seen dozens of these things come and go like
flashes in the pan.

I'm sorry if this comes off as a rant against this guy's framework.

------
clintjhill

      Your day job is to build a piece of web software and you can’t take a few days to learn the ins and outs? 
    

This is the opinion I had when all of the previous Ember flare ups happened.
My thoughts were exactly this. It would behoove so many of us to simply spend
more time with new technology and ideas before we simply throw our hands up
and say "it confuses me".

~~~
delinka
"Confusion" is not the word I would use.

Metaphorical "you" alert, not directed at parent:

You have a new-fangled thing for everyone to use. Scratch that, everyone who's
been in _your_ shoes, with _your_ particular pains. Great, you solved a
problem. Take some time to explain on your blog or in your GitHub README.md
the context of your solution. "Because I can!" is a fine reason, but I don't
spend time exploring something that was built because it was possible to build
it.

So your new-fangled thing looks like it's a solution to a problem I'm having.
I start to implement it and ... oh dear $DEITY, it's a mess. I don't mean it's
ugly, I mean it's completely inextensible. It's a _specific_ solution where a
generic one would suffice. Or worse, you didn't think outside your little box
to discover that this "fix" will debilitate 95% of the web servers on the
planet if they were to try this solution.

My advice: if you build it, A) explain why, B) learn to build it well.

~~~
clintjhill
Fair. I'm only suggesting that before we collectively steam roll an open
source project and its volunteers with "I don't get it, so it sucks" mobs,
that maybe we spend a weekend with it. Maybe over that weekend we learn "oh
dear $DEITY". And maybe, just maybe we contribute back to it in an effort to
"help".

------
darxius
> This reaction to Ember just baffles me. Your day job is to build a piece of
> web software and you can’t take a few days to learn the ins and outs?

Couldn't agree more. While I do think that new technology should be intuitive
and easy to use, you have to take the time to explore, learn and familiarize
yourself with it. I think peoples' attention spans are way too short these
days.

~~~
k3n
Time is money, and the larger your team is the more that the costs of learning
a new tech are amplified.

Using his off-the-cuff, totally subjective "a few days" estimate, and
assigning 'few' at a conservative 2 days, that would mean my team would spend
roughly 50 days doing nothing but learning this one very specific technology.
That's 50 days of _not_ producing revenue or otherwise addressing client
concerns.

Now, I'm not saying that we shouldn't be able to take time to do things like
this (learn and embed new tech), but to dismissively say "a few days" like
it's trivial is severely underestimating the impact of dropping everything
during that time to do nothing but learn about a tech that will most likely be
obsolete or superseded in only a few years time.

------
felxh
Web apps != desktop apps, at least not for now. When I looked Cappuccino a
while back, I was impressed by what it could do inside a browser in terms of
GUIs. However, when I researched a bit how I could use Cappuccino to solve the
problems I was having at the time, I quickly got stuck.

A common use case for web apps is to allow for collaboration and/or sharing
(e.g. Basecamp, Github....). When you look at the tutorials for Cappuccino you
can quickly find out how to make an image editing app, but if you want to find
out how to do even basic stuff (for web apps) like saving data to a backend,
you have to search really hard.

In addition to that, Cappuccino always looked somewhat immature - even now the
home page is somewhat broken. You don't want to bet on a new framework AND a
completely new language when it looks immature.

------
moron4hire
This is a big part of why I left Web dev, too. I'm just sick of working with
amateurs. When I'm at work, I have things I want to get done. This isn't the
classroom, my teammates' lack of comprehension of even things as simple as
dependency injection and MVC is their fault, not mine. My productivity and
coding power shouldn't have to be hampered just because I'm working with a
bunch of code-until-it-works-sorta hacks.

~~~
marknutter
I'm so relieved to hear that there are no amateur native developers. Gives me
a warm, fuzzy feeling inside.

~~~
freehunter
The point seems to be that the web is cool and hip, which attracts people
without computer science backgrounds. Without a solid footing in software
design fundamentals, "hack it until it works" seems like a perfectly valid way
to run a development cycle.

The desktop is not cool or hip, so the people doing it tend to be people who
really want to be there, not chasing trends. It's a vast oversimplification of
the situation, sure.

~~~
gfodor
I don't know about anyone else, but I learned almost nothing about software
design when getting my computer science degree.

~~~
straws
CS degrees are not a catch-all. Most teach data structures, algorithms, a
little AI and database theory. Few teach how to structure programs.

I'm pretty sick of the "I work with people without CS degrees" excuse. Good
software design really comes down to experience, persistence, and taste.

~~~
moron4hire
Necessary but not sufficient. I've worked with a lot of very experienced, very
persistent people, and I'm sure they even had good taste, but they were shitty
coders. In fact, their persistence was a requirement for them to be able to
get their jobs done at all, given how bad they were.

------
wooptoo
Nobody uses Cappuccino because it is written in such an obscure language
making the entry barrier too high.

While frameworks like AngularJS won because they tried to embrace web
technologies instead of replacing them.

------
ajkjk
"This reaction to Ember just baffles me. Your day job is to build a piece of
web software and you can’t take a few days to learn the ins and outs?
Presumably you’re in a large team because this project is important and will
take some time to complete. "

What the hell is this!?

Your day job is to write software, perhaps, but you're going to come across
Ember/X new web framework/whatever in your free time first. You're going to
try it because you've seen the name floating around and it sounded cool. And -
discover that it's impenetrable. That it acts like it wasn't designed _for_
people to learn. That it starts frustrating and stays that way, when you were
looking for a fun new project that moves fast and get results. Why would you
keep going? Why would you give it time and then force your teammates to do the
same thing, when the developer couldn't be bothered to make their software
accessible? Why is it worth your time, as a human, to waste effort because
someone who wants you to use their software couldn't be troubled to really
_try_?

I don't understand what people are thinking when they create a brilliant,
complex piece of software, and don't dedicate _concerted effort_ to making it
_the easiest thing to learn ever_. So - you want people to use your product,
but only if the have to suffer? Or - you and your team have talked and decided
you want _some_ users, but, you know, definitely not too many, so you make it
take a high activation energy to get started.

Software lives and dies by its barrier to entry and documentation. And far too
many projects have far too little of both these days.

*I understand Ember is improving, especially after that post. Good! I haven't actually used it; I'm just going off what I read the other day.

------
aidos
To me this feels a little bit of a stab at the community for not adopting
cappuccino but I remember what happened. Several years ago you showed us what
it could do. We were impressed, we wanted to play with it but no, we weren't
allowed. Instead of opening it up to the community it was kept locked away. By
the time it was released (if ever?) we'd moved on. Now we don't care, we have
frameworks that are good to work with (like angular). File size has nothing to
do with it.

------
Me1000
Author here:

First off, thank you all for the comments! Also, thank you Paul for posting
this and helping me articulate my thoughts while writing it! Finally, thank
you to everyone who has wished me success in my future endeavors.

Although I expected this post would step on some toes and anger several people
(although I tried my best not to), I'm happily surprised by the reaction in
general. HN tends towards the negative, by the Twitter feedback has sparked
some great discussion.

I can't respond to each thread, but I'd like to take a moment to address some
misunderstandings about the post. First off, I'm not trying to sell you on
Cappuccino. The project as just as strong as it has ever been and the people
doing the day to day work are very dedicated. I'm also not upset that
Cappuccino wasn't a massive success or that it didn't dominate the world. The
use of Cappuccino in my post was purely to illustrate my point of view. We
built some great software, and I'm really proud of that.

The post is more about the stagnation of the community as a whole.

It's very difficult to write this kind of post without sounding defensive or
like I'm bitter because my projects weren't massively successful. I tried my
best, but ultimately you read the result. The tone of the post should read
more as disappointment rather than anger. I'm disappointed in what hasn't been
accomplished in the last 3 years. Many of you saw how great 280 Slides was
when it was first introduced, and it's regrettable that it's not available
today.

I want my friends to be very successful and I have no animosity towards them.
The tools exist to build great things on the web and I hope this post inspires
someone to make use of them.

Many of you disagree with my assertions, and that's fine. But I'm not the only
person who feels this way. Paul Irish an avid web evangelist and Tom Dale of
the Ember project share my concerns. And while we might disagree on the role
of the web, I think many people agree that it should empower developers to
build great things.

I've seen a lot of really great developers move on to other things because
they share my frustrations and disappointments.

… and yes, the bits vs bytes line about dial up was my mistake. :) but I don't
think it really changes the point.

[edits for clarity and spelling]

~~~
Get404
You and all the really great developers are welcome back to the web anytime
you wish. Take a break. Enjoy your new job, and hopefully you'll gain new
insights and ideas -- and share them...maybe even in new web technology. It's
called burn out, and all great people experience it.

If you truly love the web, it has to be unconditional, just like real life.
280 slides is gone, just like Google Reader is gone, and somebody out there
will fill the gap if there is one.

Web technology may be somewhat stagnant (I say it's "hindered"), but look at
where the focus on technology has been since about...oh....2008. That also
means there's opportunity ahead...you just have to see it. Calm before the
storm, man. Now is the time to build and prepare. There won't be time to build
solid technology once the next "sprint" comes.

Right before the next wave, you will stop hearing people say "web and mobile."

P.S. I learned Objective-C because I needed to. It was essential to my goals.
Objective-J/Cappuccino never filled a need for me or my goals. It was as
simple as that...with no emotions attached.

~~~
Joeri
If there was no iOS, objective-c would be a niche language. People learn it
because they have to, not because they want to.

------
nhebb
I tried the Aristo showcase (<http://www.cappuccino-
project.org/aristo/showcase/>), and it took 20 seconds to load on high speed
internet connection w/ Chrome browser. I can understand developers' reluctance
to use such a framework. If you've marketing a web app developed with
Cappuccino, you're going to lose a lot of conversions with that kind of wait.

~~~
spyder
It loads in 5 seconds for me but the interface has many bugs and fails to
implement many behaviors of native elements: scrolling with mouse wheel
doesn't work, using the elements with keyboard is impossible because it seems
many of them doesn't even have a focused state. When trying to focus on
elements with the Tab key it's messing up the whole scrollview because after
that elements aren't working even with the mouse. Pressing the Enter key
redirects to another page. So it's a pretty bad showcase and the other demos
too have the same issues. (using Firefox on Windows)

------
bsimpson
And, I've officially been called out in a blog post.

When I was considering SproutCore/Ember, I was the most senior person on a
severely understaffed team at an ad company where turnaround time was measured
in days, not months. A couple of days of research was definitely considered
expensive, time-wise, in that environment.

I like the idea of continuously striving to better yourself, and I'll probably
try Ember on a personal project to that end. However, adopting a new
technology comes at a cost, and my team couldn't afford to spend what could
easily have amounted to man-months of time relearning how to do things on the
promise that we might be more productive in the future.

------
thiagoperes
I really liked Cappuccino. Great features and 280 Slides was/is awesome. I
follow its development for quite a long time.

Why didn't I use it? \- As a complete noob, I found it hard to start (despite
having good objc knowledge) \- I checked the objj github language page, and
didn't saw a lot of activity \- Last but not least, Atlas, a Cappuccino IDE
was supposed to be released.

I tried contacting Tolmasky about where the language & IDE were headed but
never got a response.

~~~
mjmsmith
"Never got s response" was pretty much the story of what happened to the (not
free) Atlas beta. I suspect a certain number of people were just turned off by
the way that was handled. (Yes, I realize that Cappuccino is a separate
project.)

~~~
boucher
Yeah, I'm sorry about the way it played out too. Unfortunately, a lot of that
was out of our hands.

~~~
thiagoperes
Just curious, what happened?

I still think Atlas is key to developing in Cappuccino, unless you find
another way to autocomplete ObjJ code efficiently.

Cocoa and ObjC only works because XCode does a lot of the heavy lifting for
you.

------
RutZap
_Done with the web_ , moving to Google to work on Google Now; an app that
relies heavily on web services to provide information to users...

I don't know why but I don't see that as being done with the web. I see it as
changing jobs/projects, but still within the _web community_.

And also I don't agree with: _Meanwhile, the web community will continue to
solve the same non-problems over and over again_.

The web community is larger than the people referred to within the article and
I don't think it's OK to generalize like that. In the last 5 years the web has
evolved massively and I don't agree with the fact that we are solving the same
non-problems. Progress and innovation is out there, on the web, within the
web... you just have to look from a different point of view (and occasionally
sift through the BS).

------
nkuttler
I had a quick look and cappuccino apps are not crawlable, at least the demos
aren't. Sorry, but it doesn't look like cappuccino gets what the web is about.

As somebody who uses text interfaces primarily I don't think desktop apps are
amazing anyway, even if I see that they are better for some tasks.

The web browser is the only graphical tool I use daily, I don't need things
inside to look like desktop apps. _shudder_

~~~
paranoiacblack
Yeah, this was my reaction as well. I'm kind of surprise someone has fondness
for Desktop Apps anymore, because I only have one and it's my web browser so I
do development and get other work done. Other than that it's terminal based
running non-gui applications. Desktop doesn't really have a place on the web
from where I'm sitting.

~~~
mikecsh
I don't think either of you are representative of the vast majority of
computer users.

------
Irregardless
> Google Now is one of the most exciting pieces of technology I’ve seen in a
> long time. It’s solving problems that couldn’t be solved four years ago.

Showing people sports scores and traffic reports before they ask for them?
Well, at least that gives us an accurate picture of your perspective (or lack
thereof). The Galaxy Nexus is the best phone I've ever used or owned, but I
couldn't possibly care less about Now. It's usually known as _"that annoying
thing that keeps popping up in my notification bar"_.

Everyone in the IT industry understands the frustration of trying to help
people who are unwilling to change and insist on repeating history. Most of us
don't give up quite as easily though...

~~~
wting
Your (lack of) use of Google Now is unrelated to the difficulty of the
problem.

Predictive analytics is an interesting engineering challenge, and is probably
what appeals to the author. On the other hand, re-solving the same web
problems repeatedly is not.

------
peterhunt
Amen brother. A lot of the problems stem from the cargo culting of various
technologies and patterns (I'm looking at you, inflexible templating
languages).

Also a lot of these issues come from looking at each piece in the development
cycle separately rather than holistically. Frameworks like meteor are starting
to address this, but we still have a lot of work to do.

------
peterwwillis
I'm done with people making a big deal about new technology when old
technology does the job better. People like this guy are _spending their
lives_ trying to figure out how to replace perfectly good native applications
with ones that live inside web browsers. It's depressing.

------
DonnyV
It never even reached version 1.0.0
<https://github.com/cappuccino/cappuccino/commits/v0.9.6>

------
commanda
I'm not a web developer, so maybe I just don't understand, but why is it so
important to the author that there be wide adoption of Cappuccino? Why does it
matter to him that the majority of the web dev community is favoring "micro
JS"? Why does he care that other web devs don't want to take a day to learn
ObjJ? Why would he leave a path he's so passionate about just because other
devs aren't being good software engineers?

------
artagnon
Objective-J and this insane Cocoa worship? Are you serious?

Try to understand that the desktop and web are two completely different
things. I would not want a UI that's designed ground-up for the desktop on my
web browser. It's just wrong. I haven't seen Cappuccino myself (I mean, who
has?), but stuff like GWT is just broken. HTML/ CSS/ JS exist for a reason:
they're simple, elegant, and products of many years of evolution. Sure, there
are cross-browser problems, but we're getting tools to deal with them.

Evolution doesn't happen by throwing away existing implementations out of the
window, and starting with a fresh slate. Tiny incremental changes that
preserve (atleast partially) backward compatibility always win. That is how
software engineering (and engineering, in general) works.

Sure, there are a lot of incompetent programmers with the span of a housefly
in the world, and a lot of "web people" are people- what does this "general
truth" have to do with anything? More importantly, why does it annoy you?

------
6ren

      > The community has tossed out everything we’ve learned from the last 30 years 
      > of building applications in favor of being able to put something together  
      > quickly with complete disregard for maintainability or extendability.
    

I wonder, heretically, if maintainability/extendability is less important
today... in the past, you'd build something, and then need to maintain it for
years or decades. But today, if the pace of change really has accelerated that
much, perhaps things change so much that it is easier to rebuild from scratch
each time (instead of maintaining/extending) - even if you did carefully
design it.

Is is just a small but prominent group doing web development (especially with
ruby on and back-end and a front-end focus)? Is it just that we're still
seeing industries adopt to the web, and old approaches slowly dying (i.e. in
the midst of revolutionary times)? Or is this a permenant acceleration, that
will only increase?

------
xsace
The web is the only future of software development. It's open, free,
innovative, and unpredictable. It didn't pick your Cappuccino, sorry for you,
but that's OK for the rest of us.

~~~
protomyth
Something will come along and replace it when we finally pile too much on
something that wasn't designed to do UI in the first place. The questions are
"what" and "when" not "if".

~~~
marknutter
Computers weren't originally designed to play music, video, or games. Yet,
here we are.

~~~
rlpb
That's a false analogy. The original assertion was about the underlying
technology being used, not about what they deliver.

------
ahoge
> Ember [being 49kB in size is] still far too big for many. Yet we
> conveniently forget that loading just a few images will quickly surpass that
> 49K of code.

50kB of compressed and minified JS aren't the same as a 50kB JPEG. The JS must
be parsed and compiled which is a far heavier operation than decoding an
image.

The last time I looked, it took about 100msec to parse and compile 100kB of
minified and gzipped JavaScript on a desktop. However, after all of this you
still won't get the full speed. It needs to run for a bit and then the hot
parts of the code will be replaced with more optimized code. Again, this takes
some precious resources.

An image, on the other hand, is decoded within a few msecs and that's the end
of that.

Size is just one metric. It won't tell you the whole story.

------
SeenItAllBefore
Extremely good points in the article.

The front end "developer" community is awash with _web designers_ who know
enough jQuery (not Javascript, jQuery) to sprinkle some woo-woo on "websites",
but who have no software engineering skills to create genuine rich, immersive
applications.

And they're resentful because rich, immersive applications that require some
engineering power, and some necessarily complex APIs are the way things are
going.

And these people are noisy and influential.

But I think that's changing. We are going to have properly engineered, web
mediated rich UIs. Not a mess of cobbled together freeware.

------
bokglobule
I often wonder if the problem with programming (or software engineering, if
you prefer) is that we're still in the stage of where builders were in the
middle ages. We assume the model of a "master builder" that has to know every
aspect of every part of the process of building something new. Compare that to
today where trades people specialize in one part of construction and hone it
to a fine point. How many of us would hire an electrician to fix our plumbing,
or a roofer to hang drywall? Maybe in the future this will be what happens to
software development: you'll bring in a UI trade to implement the UI, a
database trade, a caching trade, etc. People who've taken years to fully
understand their niche of software construction very well.

The other issue we don't have to face is any governmental enforcement of
building codes (yet). When you install wiring in a building, you can't just
run it however might be "cool" or "new". There are a variety of rules, that
come from best practices developed over many years, that are followed. Imagine
if before a client or a customer would accept a finished app if it had to pass
inspection by a 3rd party for compliance with these "codes". I think we'd see
a lot of the current state of development fall away pretty quickly. The
newbies who won't take time to learn their craft, or quickly jump from new toy
to new toy without learning any very well would be under pressure to change or
leave the field.

------
jentulman
It's a shame to see someone who has been so passionate for a product reach
this level of frustration but it feels like there's a lot of blaming
'everything that's wrong with the industry' for lack of uptake. If no-one is
taking up on your offering, no matter how cool it is, then you need to look at
what you can do to entice people in that you aren't already.

I've been back to look at cappuccino since the 280-slides first went up, and
the get people hooked documentation has always been severely lacking (which is
the case with a lot of projects, but it makes some of the complaints about
peoples efforts to learn stick out Their docs have long had, to my mind, a
tone of "it's just like objective-c, which is easy, so learn some of that and
you'll be fine" [1] It does have pretty complete API docs, but they're not a
lot of use without much deeper examples given than the few they have on the
site.

When it comes to having thrown out years of software engineering know-how I
think there's possibly something to that, and it is currently being picked up
on in more recent frameworks but perhaps, as is being highlighted by things
like backbone and angular, trying to shoe-horn dogmatic desktop software
patterns like MVC into building apps for a relatively young platform like the
browser is only a organisational stop-gap on the way to better, more suitable
patterns that are still to come.

[1] <http://www.cappuccino-project.org/learn/objective-j.html>

------
namuol
So because I didn't embrace your framework due to its use of an unproven,
unfamiliar language, you're going to hold your talents ransom from me? Maybe I
made the right choice in not depending on Cappuccino in the first place...

Who ever said the web is the forefront of game-changing technology these days?
It's just a platform that's fast to iterate on; that's why I like it, anyway.

Don't pigeonhole every web developer out there into some shitty imaginary
stereotype you have just because most of us didn't use your framework.

------
mgkimsal
"Almost every decent developer I know has no problem spending a weekend
learning some new and cool tool, but sadly, this spirit seems to be absent
from the web culture."

Hrm... the majority of web developers I know are constantly trying new tech,
but they aren't just limited to front-end js. They're learning JS frameworks -
trying out knockout, angular, yuk, dojo, jquery, ember, handlebars, mootools,
extjs, gwt, qooxdoo, zk, and more. Plus they're learning about and using
server-side caching, security, performance, server admin, graphic design,
version control, search technologies, mobile development, database work, in
addition to any language-specific stuff they're dealing with on a day to day
basis.

I'm sort of sick of this attitude of "if you can't spend 2 days learning X,
you're not a real developer". Or, more precisely, "web developers" don't do
this stuff. I'll tell you what - if I spent 2 days on your latest framework,
then asked questions about 'how do I do XYZ?', I'm more likely to get told off
by self-appointed kingmakers that I'm not worthy of using your framework
because I don't have the capacity to think at your level, or I'm not willing
to commit enough time to learn it, or whatever.

So..., as they say in England, get stuffed.

------
kyledrake
He's going to work on Google Now, which is (more or less) the same thing I was
working on with my previous employer. I could complain about how they are
making a worse version of what we did, but I'm not going to do that. I'm just
glad people are starting to see the usefulness of location-based development.

You may want to consider it from that perspective. People are getting
interested in client-side frameworks. You laid important groundwork for that.
Why not be happy about that?

There will always be a cycle of change in software development. Trust me, you
will not find that this pattern changes switching from front-end JS work to
backend "native" programming work. The only constant in this world is constant
change. If I was not satisfied with that, I would be into something like
architectural engineering. When you build a bridge over a river, it lasts for
hundreds of years.

That said, I like a lot of the points in the article. I too have noted the
absurdity of people complaining about how a 49kb file is "too large". I share
the profound confusion of the hyper-simplicity movement, where we trade ~30kb
of code for our ability to maintain software, which is a much bigger problem
than performance in our industry today.

------
thomas_h
I think you have to make a few distinctions that recognize both different
developer backgrounds and developer aspirations. It's like one of those "magic
quadrants" that analysts love:

On the horizontal axis you'd have developer background: HTML/CSS/JS - OO
Programmer On the vertical axis you'd have target application: Web Page - GUI-
like App

Web pages are about text, color, images, layouts and maybe animations - in
short "appearance". Page breaks are ok. GUI apps are about controls/forms,
lists, tables, trees, to interact with a backend - in short, they're about
"functionality". Page breaks in a GUI app are disruptive and are therefore
avoided.

HTML guys hate latency, they're used to the most direct effects. OO guys
usually don't mind to invest time before coming up with effects. HTML guys
often shy away from learning a new programming language; it's important that
they can apply the same skill set over and over again. OO guys don't mind to
learn a new language, but don't like to miss out on paradigms and patterns
they value.

Cappuccion would be in the upper right quadrant (OO Programmer / GUI App),
while e.g. jQuery would be in the lower left ( HTML/CSS/JS background / Web
Page). Probably, the crowd behind the HTML/CSS/JS profile is larger than the
OO programmer crowd. And the amount of effort spent on web pages with spiced-
up appearance is larger than that of carefully crafted rich internet clients.

But probably both have their relevance, so why trash one in favor of the
other?! For someone advertising on the web a slick appearance is prime, while
a vendor of set top-boxes values reliability of their web-based configuration
GUI. The real problem arises, and that is probably Randy's pain, when the
wrong technology and skill set is applied to a given problem.

------
tixocloud
This feels like a classic case of great product but poor marketing. The
learning curve is a critical piece to adoption rates. When developers shun the
framework, it's probably because it does not provide sufficient visible
benefit for them to warrant going through the troubles of learning the
framework. Once everyone gets onboard with jQuery, it's going to be hard to
get people to switch over no matter how great Cappuccino simply because those
people do not see the benefits outweighing the costs of switching.

It's also a chicken and egg problem. I'm going to go on a hunch and say there
are way more developers who know jQuery than ones who know Cappuccino.
Naturally, people would prefer using jQuery because it's easier to get someone
else on board for projects.

I really loved the look and feel of Cappuccino and kudos to you for a
tremendous effort! Unfortunately, I did not choose to use the framework
precisely because I had to learn something called Objective J and for that,
I'm sorry that I am part of the group of people who felt that the learning
curve was abit steep.

------
emackn
I feel that the web culture in general is exciting, and often, moving almost
too quickly for it's own good. To me, the service companies contribute greatly
to the distaste people have for working with the web. Most are churn and burn
outfits solely focused on the bottom line, which drive developers away from
the web in search of a better fit both career and life wise.

------
Kiro
_Yet we conveniently forget that loading just a few images will quickly
surpass that 49K of code._

It's not about loading time, it's about bloat.

 _This reaction to Ember just baffles me. Your day job is to build a piece of
web software and you can’t take a few days to learn the ins and outs?_

Sure but when there are alternatives which you can jump into right away with
the same good results, why waste two days?

~~~
STRML
Exactly. The web is a very agile place. We don't all sit in cubicles and have
weekly meetings. Some people just want to get things done, quickly.

------
lucidquiet
Similarly, I've personally been seeing this a lot lately... the idea that
"Done is Better than Perfect." And although I know it will never be perfect,
the problem isn't perfection it's that this idea, fails to mention where the
bar is set, or that it is set very low.

"Among his various possible beings each man always finds one which is his
genuine and authentic being. The voice which calls him to that authentic being
is what we call 'vocation.' But the majority of men devote themselves to
silencing that voice of the vocation and refusing to hear it. They manage to
make a noise within themselves...to distract their own attention in order not
to hear it; they defraud themselves by substituting for their genuine selves a
false course of life." -- Jose Ortega Y Gasset

The web is a very viscous place with all kinds of competition. Philosophically
speaking, that form of competition can rob one of a chance at true mastery.

------
protomyth
I remember a comment by a Smalltalker that pointed out many VMs are actually
smaller than some images used on the web.

------
at-fates-hands
It seems like the author has been out of the workforce for several years, came
back and realized this wasn't how things were when he left and now he's
pissed.

The rate at which technology moves, you can't have any kind of framework that
requires huge overhead, no matter how good it is. If people can't pick up and
start building stuff with it right away, it's not going to gain traction. Add
in decision makers don't allow you to just take a week to learn a framework
you think will be awesome for a project you might be working on soon. Time is
still money and nobody has the time or patience to learn something which has a
high overhead. While I agree this sucks, it's just the way the industry works
these days.

I do believe there will be a cost to this somewhere down the road, and the
collective pendulum will swing back to how the author prefers it.

------
Zelphyr
If the goal of "micro JS" truly is file size then yes, that's focusing on the
wrong problem. To me the idea behind it is to have a bunch of little tools
that do one thing really well. When those tools are combined you have
something very powerful, flexible, testable, and reasonably decoupled. Not
perfect. Nothing ever is. But better than having to use a massive framework
and do everything the framework way in which case you're just working for the
framework rather than it working for you. In my experience that is ALWAYS the
case with a framework.

Put another way, Unix has been so popular for so long in part because it
prefers the "a set of tools that do only one thing but do it really well"
philosophy over a framework.

------
jacquesc
I share his frustration with the JS community. There is a rampant wave of a
sort of "Ludditism" where people fight tooth and nail against innovations
trying to make things better. The argument always comes down to "what we have
is good enough, and OMG file size!!!".

I'm a bit more optimistic though. Randy and the Cappucino team blazed a new
trail, and although he burnt out there are others who are continuing on and
reinventing client side dev. Backbone was just a start. Ember, Angular,
CoffeeScript, tons of other great tools/libraries are advancing things at a
now exponential pace. Thankfully there are plenty of other early adopters
willing to wade through the early buggy code to build projects on top of them.

------
justinph
Perhaps we've reached the point of too many layers of abstraction.

The _web_ is designed for simple hyperlinked documents with some media
elements. We've done a pretty good job of adding more stuff to it than that,
but that doesn't mean it has proven wise or elegant.

------
norswap
My on topic, but only slightly, comment is that there is too much of an
emphasis on framework these days. Why not libraries I can call at my
discretion? It is me who is master of the code, and not the reverse.

------
perlgeek
tl;dr: Cappuccino is great, but the big crowd of frontend developers doesn't
appreciate it, and insists on reinventing the wheels badly. That's why Randy
is done with the web.

Randy, if you happen to read this: ignore the nay-sayers. There will never
been a universal agreement on what the best technology is to get a job done.
And there will always be people who try to troll your approach. That doesn't
devalue your approach. Just build cool stuff with it, and be happy.

------
porker
I'm with the OP on the 100's of badly implemented, slightly-sucky UI
components. Cappucino did this brilliantly... but it was a too big paradigm
shift.

Give me a beautiful UI library written with elegant and performant JS behind
the scenes, but let me implement stuff in a non-desktop way using standard web
technologies.

I like the concept of GWT, but Cappucino fell into the ExtJS/Sencha category
for me - trying to reinvent the web using web technology.

------
scotty79
All this careful superior engineering and all the sophisticated desktop UX
libs and I can't name one desktop app that is nice to use (except SketchUp but
that's thanks to innovative 3D tools not the UX which is ugly).

While many webapps written with crap tech thats only advantage is fairly flat
learning curve look marvelous, responsive and are perfect in what they do.

------
kmfrk
Something else I wonder about is what this increasing focus on JS is doing to
accessibility. Many sites won't even render with JS turned off; the no-JS
version of them are only optimized for search robots - not human beings who
rely on accessibility tools!

Is it just me, or is this so-called development moving us farther away from
good accessibility instead of closer?

~~~
adamnemecek
<http://en.wikipedia.org/wiki/WAI-ARIA> I'd lie if I said that I'm in a
position to evaluate it's merits but it's there.

------
undoware
The mistake made here is the assumption that we know what the web is evolving
towards: (ostensibly) something like the desktop. Hence the eagerness to do it
all again but on the web this time. (Isn't that the essence of Cappuccino?) It
would be absurd even if mobile _hadn't_ happened. So why are we clinging to
the same default assumptions?

Think again.

------
easymovet
I see a lot of negative comments, many of them are from people far smarter
than me and may be right, don't let them get to you. Their opinions are
exactly that, opinions. You worked hard on something and it didn't work out
the way you wanted it to, you have a right to be disgruntled. Congrats on the
new Google gig!

------
shaunxcode
I fail to see how the initiative to create decoupled components is a failure
to grok "real" programming. If anything has come close to the code sharing
vision of smalltalk (mentioned because objective-j is the strange cousin of
objective-c, which is the step brother of smalltalk) it is the component
approach.

------
grooper
you are done with the web community because its developers cant take the time
to learn something difficult:

the web has produced as gateway to see programming work with little code. This
will produce creators that do not have very much in depth experience/desire
for hard problems. It also allows projects to ramp up and see results really
fast. This is the trade off of the web ... deal with it or get out. You can be
a teacher to these noobs or a nah sayer ... seems you picked the latter.

It sounds like you are surrounding yourself with poor programmers.

Google Now is not a framework its a product. Im sure youll be working with
some web guys soon that will be implementing the web version of the product.
Dont be surprised if they dont use the best tool ... things need to get done
... the most precious resource is time ... other things can be wasted before
we let that one go.

------
jtchang
Are you seriously telling web developers they don't deal with learning a new
tool almost every day?!

How many damn Javascript libraries do we constantly integrate and learn? New
css like languages (scss,less). Server side languages?

I'm sick and tired of people saying web developers are somehow 2nd class
programmers who only understand HTML.

------
marizmelo
I remember to look at Cappuccino and say - WOW, this will change everything
(again). But then suddenly nothing happened. No articles, no tutorials on
peers, no visible discussions, etc. Things became worst when Motorola bought
280north. That was a deal breaker for me. Uncertainty about the library
future.

------
asciimo
This is not a good first impression for someone who had never heard of
Cappuccino before. It reads like a verbose rage quit. It would have been more
respectful to his colleagues and their (small?) community of users to explain
his career decision while also remaining optimistic about the project.

------
kevincennis
Kind of surprised to see that this was posted by Paul Irish, considering he's
such a huge web evangelist.

There are definitely some valid points in the article, but at the end of the
day, it's hard for me to accept that The Right Way™ to do web development is
to completely abstract away HTML, CSS, and JavaScript.

~~~
paulirish
Certainly I live and breathe the web and do everything I can to advocate for
its success.

I helped out Randy with this post because I think this perspective is both
legit and underheard. Plenty of folks that work tirelessly to improve the web
platform share frustration that many developers for the platform don't take it
seriously as an application development platform, don't learn from past
mistakes, and don't adopt the lessons learned from other platforms.

So honestly I think this painful truth needs to be heard if we expect the web
to meet its potential.

~~~
kevincennis
Thanks for the reply. I was hoping you'd weigh in.

------
hpguy
Why would I prefer to plug and play (and toss away) micro, modular
libraries/frameworks designed to interop or to be independently used instead
of using a monolithic technology that pushes to my throat ObjJ, Cocoa and a
other contraints that follow (like IE8+ only)? That needs an explanation?

~~~
wilmoore
Awww, bless his heart. He forgot to add the #notsohumblebrag tag to his post.

------
porker
Earlier today I was talking to another dev, and we were both wishing for a
system like Delphi 7 for the web, with vcl and a vibrant ecosystem of 3rd
party components (we were discussing how much SaaS leads to reinventing the
wheel).

After 12 years in web dev, I feel his pain.

------
NikolaTesla
I feel as though everyone is leaving out a huge part of why the web has won.
For the most part it's free. The world developed muscle memory that
'installed' cost money and web access was free. Not the only reason it won but
a big one.

------
edman
I think that this guy does not really understand how the web works. I mean,
emulating desktop on the web has been tried many times and failed each time.
He's right about some things (like people considering 49KB to be a lot)
though.

------
leephillips
I wrote this a little over a year ago:

<http://lee-phillips.org/cappuccino/>

Maybe not very kind, but just maybe people didn't rush to use this thing
because they didn't inspire much confidence.

------
deepuj
The end objective of web development is to bring desktop like experience? I
wouldn't blame the failure of Cappuccino on the emergence of micro libraries.
Cappuccino simply does not sound like what the web needs.

------
saiprashanth93
I am not a developer.Can anyone tell me why so many frameworks are being
created?There seems to be five or six frameworks in each language,new
languages being adopted to create frameworks.Why all this work?

------
bhurlow
Lets think about this from the opposite direction: Which projects on the web
are the MOST successful? Facebook? Twitter? Gmail? Github?

Do ANY of those giants use big, all-encompassing super libraries? NOPE

~~~
lucian1900
At least Gmail does, perhaps Facebook as well by now.

------
michaelwolfe
Any time you argue that everyone is crazy except for you, one of two things is
possible:

1 - you are in the wrong and have some biases that led you there. 2 - everyone
is crazy except for you

Usually it is 1)

------
haydenj0nes
god DAMN, this is just about the most pretentious thing I've ever read. My
face is making involuntary expressions of disbelief as I read more and more.

------
ebryn
I just want to point out that Randy is advocating for the use of Cappuccino.
Many people seem to be thinking that is the point. It's not.

------
orasis
So the author failed and isn't good at empathizing with people...

------
phpnode
math0ne: your account has been dead for very nearly 5 years, this must be some
kind of record.

~~~
YuriNiyazov
The record might be that he was hellbanned for his very first comment.

------
martinced
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.

~~~
josteink
_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
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
" _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?

~~~
buzzWerdzGalore
PFFFT!

A language interpreted at runtime, by an application that runs inside an
operating system (which may or may not be virtualized) that boots into
protected mode. Let me get this straight, you're ostensibly describing this as
being "bare metal"?

Have you ever heard the terms "kernel mode" or "ring zero"?

Oh wait, you qualified it as "the 'metal' of the web"... so it's an "analogy".
Sorry to be pedantic, but when people say "bare metal" in the context of
platform virtualiztion, "bare metal" literally means just that. The executable
code is compiled into binary that directly correlates to the copper wires (and
etched semi-conductors, or perhaps even vacuum tubes) of the specific, real,
tangible machine intended to execute the code. JavaScript is nothing like
this.

Maybe the packets and datagrams of transmission protocols are the "bare metal
of the web", but JavaScript most certainly is not.

Check out the Communication Systems OSI Model.

<http://en.wikipedia.org/wiki/OSI_model>

I'd contend that nothing above Layer 4 could be considered analogous to "bare
metal".

~~~
dbenhur
> The executable code is compiled into binary that directly correlates to the
> copper wires (and etched semi-conductors, or perhaps even vacuum tubes) of
> the specific, real, tangible machine intended to execute the code.

You do realize it's been a while time since the ostensible instruction set and
corresponding assembly language of most modern CPUs translated directly to the
bare metal execution model of the machine.
<http://en.wikipedia.org/wiki/X86#Current_implementations> Even on RISCier
architectures, virtual memory, deep instruction pipelining, super-scaler
dispatch, branch prediction, multi-layer caching, inter-core cache coherency,
etc. introduce a huge amount of abstraction between the instruction you write
and the actual execution on "bare metal".

On current chips, x86 machine code is as much a virtual machine as java byte-
code. It's abstractions all the way down, you just pick different levels for
different classes of work and "bare metal" is now just a label for one below
where you landed.

~~~
IheartApplesDix
>On current chips, x86 machine code is as much a virtual machine as java byte-
code.

I understand what you're trying to say, but this is way off base. x86
instructions may not align exactly a processor's primitive operations, but
that doesn't mean abstraction makes x86 similar to the JVM, at least not
anymore than it is similar to a Bible printed on papyrus. But nobody cares if
ancient Hebrew is just as much a virtual machine as Java, so stfu.

~~~
nkassis
You should leave out the stfu next time. You comment stand on it's own without
it.

------
dave_sid
see you later

------
martinced
I'm sorry about the harsh tone of my other comment (most upvoted comment so
far) but the tone of the author is aggressive so...

Now on Cappucino's website I read this:

 _"Cappuccino is an open source application framework for developing
applications that look and feel like the desktop software users are familiar
with."_

and I can't help but think this is all wrong. There are many (most ?) users
who are now familiar with webapps, not desktop apps. And what they want is
definitely _not_ a webapp looking like an old, outdated, Windows or Java /
Swing app (which is exactly how Cappucino looks like).

What many user wants is webapps that look like webapps and if they are
"forced" to use a desktop app, then they want a desktop app looking like a
webapp (I'm thinking about the client-side desktop apps embedding a browser +
JavaScript engine).

I'm also pretty sure that devs who have done both advanced HTML + CSS to
"customize" the UI of their app do much prefer that over, say, the total and
utter madness that Swing is (I'm speaking of what I know).

Yes, HTML and CSS have their warts... But you'd have to a masochist to want to
create a desktop app using Swing.

Users I'm sure they don't want apps that looks like desktop apps: they now
have browsers, iPad, Android tablets, etc. They hardly remember what an old
Windows desktop app was like.

Devs I don't know: I've done my fair share of Swing and the last thing I want
is go back doing that.

I kinda like this "simple / straight to the point" webapp worlds that we have
right now.

~~~
mixmastamyk
Out of curiosity I just looked at the Cappucino website... the controls look
modern to me, not like "old, outdated, Windows.. Swing" apps.

------
recoiledsnake
>Ember is very close to the “micro” side of things, but at a “whopping” 49KB
(less than a second download on a dial-up internet connection)it’s still far
too big for many.

Erm, isn't dial up at 56kilobits per second? It will take much longer than a
second to download 49KB.

------
workbench
Wonder where it all went wrong?

> Objective-J

oh yeah

------
camus
Objective-J is not the problem itself , the problem is that Cappucino is very
hard to debug in the browser itself. I went through the tutorial , had an
error , and there was no way i could know where it came from.

I dont have a mac right now so i cant use the builder , but i dont think that
Cappucino failed because it is bloated. I use Haxe which is even more bloated
than Cappucino. Yet Haxe allows me to debug a JS app directly in the browser
with source maps , Haxe has a very smart and powerfull compiler.

Maybe it is matter of timing. But i think it is just a matter of tools. Again
Obj-J is not horrible to work with. And Capp apps are definetly neat.

------
sc0rb
The disclaimer at the bottom of the page says it all:

"(Obviously these opinions are my own and of course do not represent the
opinions of my future employer)"

He has no real world experience doing anything that matters so just chats
about what he's witnessed from within his bubble.

~~~
sc0rb
In the interest of not being a coward and deleting what I previously said...

I just read his 'about me' section and feel a tiny bit humbled..... not
massively though.

