Live data from Hacker News

First Look: Blossom - A SproutCore Spinoff Using Only HTML5 Canvas For Rendering

badassjs.com

21–25 of 25 posts

Re: First Look: Blossom - A SproutCore Spinoff Using Only HTML5 Canvas For Rendering

#21

Earlier quoted context omitted.

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 issue…

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 b…

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

Re: First Look: Blossom - A SproutCore Spinoff Using Only HTML5 Canvas For Rendering

#22

Earlier quoted context omitted.

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,…

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?

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

Re: First Look: Blossom - A SproutCore Spinoff Using Only HTML5 Canvas For Rendering

#23

Earlier quoted context omitted.

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 b…

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 eithe…

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.

Re: First Look: Blossom - A SproutCore Spinoff Using Only HTML5 Canvas For Rendering

#24
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

Re: First Look: Blossom - A SproutCore Spinoff Using Only HTML5 Canvas For Rendering

#25

Earlier quoted context omitted.

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 eithe…

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.

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.

Post reply on HN