3 ms·

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

17 points by devongovett 15y ago

webcowboy 15y ago
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?
- devongovett 15y ago
  Except it's entirely standards based. Canvas is part of HTML5 and the apps are built entirely in JavaScript. And the whole framework is open source with no proprietary components. Not sure how you got to those conclusions.
  - webcowboy 15y ago
    I don't mean to overreact, but so were <object> and <embed>, which were what Flash used. If they're creating their own canvas-based way of rendering a UI, it's not really using HTML5... it's just that HTML5 happens to be the container. And just because it's open source, doesn't mean it's standards-based. I'll have to dig deeper, but things like "HTML and CSS independent" feel very proprietary to me. It just feels like you're losing out on the shared semantic value of HTML, etc.
    - devongovett 15y ago
      That doesn't make any sense. Canvas is a standard maintained as part of HTML5 by the W3C. How are they "not really using HTML5"? Just because they don't have some tags? That makes no sense. The web is not HTML and CSS. People need to get over that. As for semantics and stuff, this isn't designed for documents at all, which HTML is perfectly suited for. This is designed for native-style applications in the browser where semantics don't really mean anything anyway. And like I said in my article, accessibility is taken care of.
      - zachstronaut 15y ago
        The Web is HTML. HTTP is Hyper Text Transport Protocol. I think you're advocating for a JSTP that just cuts out HTML and CSS entirely. And at that point, why not just serve up compiled JS since it will be less bandwidth, right? Goodbye open web.
        duckinator 15y ago
        For compiling JS to be widely used, there has to be a decompiler or interpreter in most major browsers. It's no different than distributing binaries written in any compiled language. How does this damage the open web?
- zachstronaut 15y ago
  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 15y ago
    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 15y ago
      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.
Me1000 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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.
erichocean 15y ago
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

17 points by devongovett 15y ago

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?

devongovett 15y ago
Except it's entirely standards based. Canvas is part of HTML5 and the apps are built entirely in JavaScript. And the whole framework is open source with no proprietary components. Not sure how you got to those conclusions.
- webcowboy 15y ago
  I don't mean to overreact, but so were <object> and <embed>, which were what Flash used. If they're creating their own canvas-based way of rendering a UI, it's not really using HTML5... it's just that HTML5 happens to be the container. And just because it's open source, doesn't mean it's standards-based. I'll have to dig deeper, but things like "HTML and CSS independent" feel very proprietary to me. It just feels like you're losing out on the shared semantic value of HTML, etc.
  - devongovett 15y ago
    That doesn't make any sense. Canvas is a standard maintained as part of HTML5 by the W3C. How are they "not really using HTML5"? Just because they don't have some tags? That makes no sense. The web is not HTML and CSS. People need to get over that. As for semantics and stuff, this isn't designed for documents at all, which HTML is perfectly suited for. This is designed for native-style applications in the browser where semantics don't really mean anything anyway. And like I said in my article, accessibility is taken care of.
    - zachstronaut 15y ago
      The Web is HTML. HTTP is Hyper Text Transport Protocol. I think you're advocating for a JSTP that just cuts out HTML and CSS entirely. And at that point, why not just serve up compiled JS since it will be less bandwidth, right? Goodbye open web.
      - duckinator 15y ago
        For compiling JS to be widely used, there has to be a decompiler or interpreter in most major browsers. It's no different than distributing binaries written in any compiled language. How does this damage the open web?
zachstronaut 15y ago
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 15y ago
  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 15y ago
    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.

Me1000 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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.

erichocean 15y ago

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