

First Look: Blossom - A SproutCore Spinoff Using Only HTML5 Canvas For Rendering - devongovett
http://badassjs.com/post/18610722419/first-look-blossom-a-sproutcore-spinoff-using-only

======
Me1000
Until people try building a desktop class application using te DOM, I think
it's probably best for them to reserve judgement. Cappuccino and Sproutcore
are the only ones who did it well (maybe Ext, but I don't know the API well
enough), unfortunately it always lead to a leaky abstraction (I say that as
core team member for Cappuccino). Then web developers come in and want to use
their jQuery widgets, and are confused why it's terrible. The canvas approach
is an almost pure abstraction, and should be explored thoroughly.

~~~
devongovett
Right. I'm not saying it's perfect, just that it's an option worth exploring.
HTML and CSS simply weren't designed for applications. They're great for
documents, but it turns out that using them for this style of application ends
up causing a lot of trouble later on as the applications get more complex.
Abstractions can help with this, and once it is abstracted, it shouldn't
really matter what the rendering backend is. Could be DOM or canvas in the
browser, and as this project is showing, various native backends as well. I
think that's really powerful.

~~~
zachstronaut
When we identify places that HTML/CSS are falling short for making desktop
quality applications, and we bring those issues to the standards community,
and we make HTML/CSS better, then we lift up everybody's applications. We make
the whole web better. Together.

If we can get missing UI features into the browser, those UI features will
have native implementations and APIs, and that will give all of us free
functionality and better performance.

~~~
devongovett
Yup, and canvas is just a part of that. It gives control back to the web
developers and allows us to create anything we want without waiting for
browser implementations. IMO, HTML and CSS are fundamentally not designed for
building this kind of app, which isn't really a solvable problem without
inventing something new anyway. Either that or we abstract them to make
working with them easier.

~~~
zachstronaut
Can you give an example of how Google Documents is falling short of being
desktop class with their HTML/CSS based UI?

~~~
devongovett
Seriously? Google Docs is nothing compared to any native word processor. Just
look at Apple Pages or Microsoft Word. The kinds of layouts and power you get
from those tools is way beyond what anyone has ever been able to do in the
browser.

Secondly, yes Google Docs uses HTML for their UI, but it's seriously
abstracted I believe as Google Closure though I may be wrong. My point is that
HTML and CSS can still be used, but they need abstractions for this type of
app. Canvas is just another approach to the same problem.

~~~
zachstronaut
Do you have links so I can check out some web based word processors that
deliver more of a desktop class experience than Google Docs does? Especially
one where the UI is done entirely with Canvas?

~~~
Me1000
CappCon had couple awesome demos using all canvas. Example is here:
<https://github.com/austinsarner/Frappuccino> unfortunately it's pretty buggy
since it was never finished (due to a lack of funding) I believe a video of it
being used was shown in the single video of the talk we released, it can be
found on the Cappuccino blog.

Edit: here's a link to a video from very early on in development.
<http://db.tt/2YX8gpYx>

------
erichocean
I wrote Blossom, and also was on the core team for SproutCore 1.0, so I fully
understand the "do it in HTML/CSS" side of the equation.

@zachstronaut I'm 100% in favor of interactive HTML documents with JavaScript,
HTML, and CSS. What nearly 5 years of experience developing desktop-class
applications in web browsers has soured me on is using a language and API for
writing documents (HTML and CSS) to write views in apps. I can do it well, but
most developers can't and it's a constant source of bugs in SproutCore today.

Today, GWT, SproutCore, and Cappuccino all treat the browser as a runtime for
apps, but only one of the three (SproutCore) really embraced HTML/CSS in doing
so. I think it's fair after 4+ years of doing that to assess the situation
with SproutCore and realize that the HTML/CSS experiment for views just didn't
work out all that well for SproutCore developers, and it made running
SproutCore apps well on Android and iOS really, really hard.

Blossom treats HTML 5 like a runtime. And more: HTML 5 is the _baseline_ for
what is expected from any runtime, in the browser, the desktop, or on mobile.
From my perspective, that puts Blossom far ahead of GWT and Cappuccino in
terms of "embracing the web" when it comes to apps, and if Blossom is to
evolve in the future, the web will too. That benefits everyone, including the
people writing interactive documents with HTML, CSS, and JavaScript.

Best, Erich

------
webcowboy
Does this scare anyone else, at least just a little bit?

It seems so odd to me that now Flash is being de-emphasized, we're picking it
up all over again. Yes, there are some performance benefits and cross-platform
problems you can jump over... but isn't this just a proprietary, non-standards
way to approach web design all over again?

~~~
zachstronaut
Yes. I share your concerns. This attitude that HTML and CSS and browser UI
somehow need to be replaced by a custom layer of JavaScript ultimately is a
slippery slope towards things like applets and swfs... towards a byte-code
compiled web. See also: Native SDK.

We've got all these mechanisms built up to deal with web UI that is
constructed with HTML and CSS in terms of accessibility, in terms of search
indexing, in terms of browser plugins and extensions, in terms of web services
and bookmarklets, in terms of UI debugging... Also, the web UI you get with
HTML and CSS inherits a bunch of standard behaviors and defaults that make for
more consistent experience from site to site. Consistency in UI mental models
is a great thing.

I can't think of a single argument FOR this idea of rendering UI entirely in
canvas that shouldn't instead be met with a response of "so lets make HTML and
CSS better!" Instead of improving the open standards of HTML/CSS, people are
pushing towards proprietary solutions.

Sometimes even the best intentions can go awry. I don't think this is malice
so much as ignorance.

~~~
devongovett
Sorry, but those things are totally different. Applets and flash are plugins -
proprietary additions to browsers that live in a black box. Canvas is a
standard, and is part of the browser itself. HTML and CSS don't need to be
replaced for most things, but this _is_ an interesting experiment to see
whether for a certain class of applications, canvas can outperform the DOM and
take care of some of the cross browser issues that CSS is plagued with. I
don't get why people are so attached to HTML and CSS.

~~~
zachstronaut
I'm attached to HTML and CSS because I remember UI programming before HTML and
CSS. I'm attached to HTML and CSS because of the debugging tools for HTML and
CSS UI. I'm attached to HTML and CSS because it allows for bookmarklets, and
screenscraping, and browser plugins/extensions. I'm attached to HTML and CSS
because it creates a beautiful separation between front end and back end code.
I'm attached to HTML and CSS because UI designers can skin software built by
JS programmers by tweaking a CSS file without having to know any JS. I'm
attached to HTML and CSS because the web is HTML and CSS.

~~~
andrewjl88
Just because things sucked before HTML and CSS doesn't mean that they're the
pinnacle. I personally find debugging HTML and CSS incredibly frustrating.
Uneven standards implementation across browsers doesn't help either.

And I am seeing first hand how UI designers find CSS (it's NOT intuitive at
all).

We build things with HTML, CSS, and JS that they were never designed to be
building blocks to. At some point we either have to accept that these are not
up to scratch or we can continue to see the web eroded in favor of native
platforms (most of which are even more closed).

Attitudes like this makes this quote ring true: "All truth passes through
three stages. First, it is ridiculed. Second, it is violently opposed. Third,
it is accepted as being self-evident."

~~~
zachstronaut
Let's not get all Gandhi here. You're not liberating a people from an
oppressive colonial power. You are programming.

The newness of an idea does not indicate its objective "truth."

I'm saying that HTML and CSS can and should be brought "up to scratch."

I also disagree with your assertion that HTML, CSS, and JS somehow have some
predefined subset of things that were intended to be built with them.

~~~
andrewjl88
Actually I do find the DOM oppressive, especially at 4am in the morning before
a deadline ;)

On a serious note, there is no historical precedent for standards committees
to competently steer the technical underpinnings of a platform as dynamic and
fast-changing as the web. Web development is unwieldy right now because of
this.

I never asserted "that HTML, CSS, and JS somehow have some predefined subset
of things that were intended to be built with them." At the end of the day,
software performance is based on architecture. The architecture of a platform
or a language or a framework is intertwined with it's intended purpose.
Anything otherwise is just bad engineering.

HTML and CSS are reasonably well engineered tools. They just rely on the web
from the 90's, a set of interconnected documents. Not the application and data
driven web. The architecture is not designed to handle these new paradigms.

And JS? JS was designed to do form validation. Nowadays it can run your entire
web stack, it was NEVER designed to do this. Can you build awesome web apps
with HTML, CSS, and JS? You bet. But don't kid yourself that it's easy. Tools
like Cappuccino, and Sproutcore, and Blossom are awesome and help sort of
solve this issue but they do so at huge performance costs.

Someday the web will be written using the tools and frameworks that don't
drive developers to frustration. How soon that day comes will have a lot to do
with how attached we are to the outdated architectures used by the web today.

