SproutCore debuts new HTML5 web development tools - Page 2

ditto

Didn't Apple take over the SproutCore project and employ this guy? If he's an Apple employee then Apple is well within rights to mute him.

SVG is Adobe's alternative to Flash so as part of the HTML5 spec it is more than capable mixed with HTML5 and CSS3.

I'm still not sold on SproutCore, from what I understand apple has been doing more hindering the progress of SproutCore than anything. I'll stick with Cappuccino and Atlas.

I have read the last paragraph of the article several times, and I'm not sure what it means. Could someone rewrite it?

Last time I checked animated gif was quite able at producing self-contained animations. never mind, Wired Quicktime (around since 3.0) could get a shot in the arm by the time Adobe get its Flash 10.1 act together.

After fifteen years as a developer for the Web, I couldn't agree more. It hasn't improved. ditto...

Browsers have never followed standards completely and have often set new standards for better and worse. Content creation tools and browsers have tried to fill in the gap where the standards have failed. People want pixel precise placement and animation or video. The standards have always shot for the lowest common denominator and never led the way; as a result, we have plug-ins.

Hopefully coders and designers can come together to offer an alternative set of standards. We need new content creation tools that inspire the designers while writing good clean code and are rated according to how well they adhere to the standards by this new governing body. Imagine a content creation tool or a browser that gets 5 stars from a new W3 governing body. Hopefully this battle against plug-ins will develop into a movement for reform and a new direction for the Web.

WTF do you think the Android SDK is??? It is, for all intents and purposes, a way to run apps over the web, optimized for connections on the class of mobile devices it supports. And yes, I've used the SDK.

We can nitty-pick technical details and parse language on this all day, but the big picture is apps connected to the internet via the mobile device. The says web app framework without using those specific words.

Your post is self contradictory. The ditto is agreeing that SproutCore as another API is a waste of effort. Then you hope to find a tool that does all the things W3C wants.

What do you think will be inside that tool? Faeries and pixie dust?

Inside that tool will be a HTML5 compliant framework abstracting the lower level stuff the main set of web designers don't want to be bothered with. What is SproutCore trying to be, a HTML5 compliant JavaScript tool.

TraceMonkey, V8 and SquirrelFish are pretty damn fast for interpreted language engines. New CPU architectures will start to make them fast enough for whole new classes of apps that we wouldn't have considered 5 years ago. Now they need to be easier to write for rather than the current roll-everything-yourself model.

Do you want what you want? Or do you want to pop off "ditto" when it sounds like it might be cool to do so?

You never read the whole story did you. Yes that is a period, it wasn't a question. And now you tell the entire world you favor a half-assed fire-without-forgetting-what-you-never-read posting method.

In the iPhone OS 4.0 ToS it also said developers were welcome to use JavaScript as invoked within the WebKit browser. SproutCore is a framework to make in-WebKit apps easier to build so web designers without Objective-C experience can use their JavaScript experience and still do some damn fine work. And OBTW, those SproutCore apps will run fine wherever Chrome and Firefox are too.

Very true. In many ways, the more abstraction there is, the harder it is to find out why layouts go bad or functionality just breaks. Javascript is so bad for debugging as it is without relying on a codebase you haven't built to make it near impossible to find out what's wrong.

I checked out the demo of greenhouse and I had to install 11 dependencies to get the thing to run and it still doesn't work properly - maybe Safari can't quite run it properly.

Cappuccino looks good and has nice working demos like the following Powerpoint-style app:

http://280slides.com/

but the apps still don't feel like desktop apps, generally run very slowly and use loads of CPU. Also, the integration with other web elements is still lacking.

I just can't believe that after all these years someone still hasn't made an application like Flash that uses Javascript for the API and SVG for the graphics.

You just shouldn't have to layout web pages using code. A designer should have a WYSIWYG workspace and be able to drop text with fonts and layout objects like scroll boxes etc onto a page, save it and then pass it over to a developer to add code functionality then simply publish it. No having to check various browsers for layout issues.

Ironically, Adobe is the closest to this now with the copy/paste to Canvas but you have to develop in Actionscript so there's still an awkward disconnect between the API and the published format.

All good points and I agree completely. Having been in the design business since the early 80's I've been on the bleeding edge the whole time. I think about this GUI interface issue all the time. That is one of the things I like about Gordon by Tobias Schneider is that it is entirely possible to use Flash as a front end and parse the swf with Javascript. With CS5 or Opacity you can get some canvas code to cut and paste but to be really useful it needs to be dynamic. Like RGraph we need interactivity with canvas not just the ability to draw geometry.

I don't get this. What the hell have designers got to do with development? Shouldn't designers design the layouts and then let the codes develop the site within the constraints of the designs the designer made?

Maybe it's the engineer in me that makes me think designers trying to develop sites is nothing more than an ego trip and therefore their complaints are kind of invalid. Get the coders to develop the site - in which case this article is aimed more for them - and then anyone can enter the content.

Sorry if these comments sound heavy handed but I just can't get my head around this whole designers vs developers concept. It seems illogical and inefficient and fraught with many dangers to me.

I still prefer the roll-your-own method. With scores of different conflicting JS frameworks, I don't want to waste any more time on whatever is in vogue at the moment. Prototype I do like, simple and lightweight, Dojo not so much, too complicated and hard to override.

I usually have very limited time to complete projects, and unlike other people who don't seem to have any deadlines or commitments and spend countless hours fiddling with experimental code, I find writing my own code faster than frameworks. Trying out countless abstracted JS frameworks to see which one has the feature I need for a particular project is time consuming and is often a wasted effort because I end up writing my own solution in the end anyway.

The notion that web pages should behave like desktop applications is an overrated concept in my opinion. Desktop applications don't usually have a back/forward arrow or a refresh button. Since browsers use this model, I find it counterintuitive in many case to use Ajax which essentially disables the back button. With the ever increasing speed of networks and computers, the latency of a network request and page refresh is virtually disappearing. I think doing more on the server and less on the client are reversing roles in its advantages to the end user who currently never knows where the back button is going to take them.

You sound like the one with an ego trip issue. What exactly is wrong with putting the necessary tools in the hands of the people who are best qualified to create an end user focused solution? The whole reason for the existence of computers is to simplify tasks.

Maybe developers who specialize in a high level language should consult assembly language complier programmers for advice on building websites. After all, they clearly understand computers better than anyone right?

Just curious, you've made significant allegations in your posts here. I'd be curious to know more about the source of your "information". Because someone didn't speak, does not necessarily mean they were prevented from doing anything. Please demonstrate the nature of the conflict whereby Jolley was prohibited from speaking. Was Charles Jolley openly complaining about some sort of unfair treatment, or are your allegations simply suppositions on your part?

It's not an ego trip it's a valid comment.

My understanding of designer is that they DESIGN stuff. It's in the name. A developer DEVELOPS stuff.

To me it just makes sense that a designer designs the layouts and the developer develops according to the layouts provided by the designer.

I'm just trying to find out what exactly a designer does and you come back with a dick response. Tell me what a designer does and maybe I'll understand but currently as I don't know because no one's clarified I'm still thinking designers should simply design.

So don't be a dick and tell me nicely why my thinking is wrong it's all I ask.

Many web developers are a combination of programmer and graphic artist. Designers range in skill set form experts in psychology and marketing to visual human interface planners. The difference between your so called 'developer' and so called 'designer' by name alone amounts to stereotyping a guy with a calculator and a guy with a paint brush. But I'm probably the wrong person to ask because I've been creating websites, writing software and designing TV and magazine advertisements for many years both alone and on teams. I'm a photographer, musician, artist, have a degree in biology, work in medical imaging, and an entrepreneur. People can be more than one thing.

No it doesn't it defines what they do.

A mechanic doesn't work on computers they work on vehicles. A painter doesn't build houses they paint them. A policeman doesn't make the laws he just upholds them hence the term POLICE. A developer doesn't necessarily design webpages or applications they build them so you can see how I couldn't work out why designers were "ego tripping" so to speak.

I'm a computer engineer by trade I don't build bridges despite the fact I'm an engineer. It doesn't mean that I don't know how it simply means that building bridges isn't in my job description which is implied in the name of my role. I know how to build webpages but it doesn't necessarily mean I know how to design them.

To me it seems more efficient for a designer to stick to their namesake role and work with the developer who will be more clued in with the technologies than the designer. Sure they might each know how to do both in which case I would change the name from solely "designer" or "developer" to "designer and developer" so that people can get a fair idea of the role they play. From what I'm reading designers are having a whinge because there's no tools that allow them to easily design websites but a developer has all the tools in just something like Coda because they know how to code. In essence it seems a designer is a jack of all trades master of none.

If you were selling your services to someone and they heard you were a "website designer" then they might not purchase your services based on the assumption you can only design a page. If you marketed yourself as a "website designer and developer" people would realise "Hey this guy can design my site and develop it as well". Personally I would actually hire a designer solely for design and a developer solely for development just because I prefer the right tool for the job because it makes sense as an engineer. You could use a hammer to drive in a screw and take that screw out but it doesn't make a nice job and it isn't very efficient.

I think the true power of the web and web apps will be in not touching that forward/back button, as in the button not even being there, (I agree disabling it is a mistake). The app won't be in a browser, it will be the browser, just customized for the task at hand. Embedded WebKit is just a first small step in this direction.

As for roll your own vs frameworks. I won't argue with your experience, it's obviously right on. The future though should be able to fix that, with the good frameworks becoming prevalent because they make sense, reduce development time for good coders and have excellent tool support for both coders and designers. We aren't there yet, but I think the ideas of SproutCore are definitely in the right direction. Will it be TheOne? Don't know, but it has a big, highly-interested sugar daddy who is driving the project where it wants the project to go by throwing code wrangling employees at it, whether or not others think that's the case.

The ditto was for the fact that web development still sucks after all these years. Sorry if that wasn't clear. As for faeries and pixie dust - I think you should have thought before you hit submit reply - that goes beyond contradiction.

My point is that web design is still stuck in a rut between coding and designing. My hope is that someone puts together a tool that lets enables designers to write clean code and create inspired designs. Trust me I've done my share of clean up of code. I've worked on teams where there are budgets for coders, designs, interface developers and marketers but not every job has that kind of budget. I have often found myself designing and coding. I know next to nothing about Sproutcore and my post may be of topic for this thread, but my hope for a tool that crosses the divide is shared by many in web design/development, if not by you.

Then support Flux.

http://www.theescapers.co.uk

It's coming along very very nicely, is heaps cheaper than DreamWeaver and is rapidly moving towards supporting HTML5. The more people we get supporting this one man project the better.

Admittedly I might be biased because I really love this application but with support for PHP, Ruby, and now basic support for Concrete as well as being able to develop with Prototype, JQuery, MooTools etc it's a brilliant app. It's standards based (currently slanted towards XHTML as opposed to HTML5) and has graphical editor as well as code editor.

There are still a lot of niggles because it's still in beta but it gets updated at least once a week. The more people we get checking this app out the more beta testing the developer can get and the more it can become better.

Cheers! I'll check it out...

I don't think there's an argument here, that's the goal achieved by what mstone said.

Currently, a designer creates layouts and the developer builds code but there's an awkward middle step whereby the layout is converted into HTML/CSS code and if it's animated, requires Javascript like Prototype and the designer should determine how that would look and work.

So who does the middle step?

With current tools, you either have the designer slicing up the layout and building up the page in code/CSS to make sure it looks exactly like the design or you have the developer slicing up designs and laying them out, which wastes a lot of time that the designer ought to do as design work takes less time typically. In short, the designer is either doing some coding or the developer is doing some layout.

The holy grail is to have no middle step. Flash already offers this as a designer can throw shapes and animations onto a canvas without knowing one line of Actionscript code. Then simply pass the file over to a developer to add the functional code. That's how it should be with the designer doing design and the developer doing the code as you said.

We just need this for HTML instead of Flash.


Flux looks pretty good but I'm starting to think that rather than have Canvas be another element inside the DOM, it needs to replace it so that all content is rendered in a Canvas context. Nobody (including developers) needs to see the markup for UI elements. Developers only need to click on an object and see the reference and properties.

The biggest problems arise from the flow of content and having to use floats, clears, absolute positioning etc. This should all be handled easily in a WYSIWYG fashion like it is when you position an image in Pages or Word and choose the layout type. Flux handles this ok but in apps like Flash there is no need to manually do anything about it.

Why would there be a middle step? If there's an issue the developer works with the designer directly so there is NO middleman at all. This is far more efficient as each have their specific role and work to the confines of that role. If the developer has an issue with the design he goes to the designer to clarify or try something else and if the designer has an issue with the code he goes directly to the developer.

A designer should never touch the code because it can cause flow on effects that the developer will have to find and workout what went wrong. The developer should never touch the design because that can have flow on effects for the designer.

The designer should only determine how something works in terms of the movement of the animation and NOT how it should work on a code level, leave that to the developer who will have a better idea of how the code should work.

Once again though all my comments are based on my engineering thinking so may not be the case in the "real" world which is an inefficient world.

Like the guy/gal who does HTML/CSS didn't piss me off enough already.
If there's one more step there, it'll be a double homicide.

The designer creates a layout in either Photoshop or Fireworks. That's their job done.
The developer uses a set of PHP code or similar to interact with the designed page.

The middle step is where the images from Photoshop/Fireworks need to be converted to HTML/CSS. Like I say, if the designer does this step, they are coding. If the developer does it, they are doing some level of designing as they have to ensure the layout matches the original design.

This step shouldn't exist at all and it doesn't in Flash but it does in HTML. Without the middle step, the designer and developer are perfectly divided into their respective roles and live in harmony.


That's the middle step I mean. In your scenario, it would seem the designer is taking the role of building the HTML/CSS. It's more time-effective for them to do it but they typically don't know how or use naming conventions that won't fit with yours.

Imagine a situation where there is an HTML 5 design program and a designer uses the pen tools and layers and can even create animated objects as named assets. They just save that file and send it to the developer. The developer can then look at all the assets and reference them from code. Neither designer nor developer have to see any CSS code. The developer doesn't have the tedious process of recreating the layout all over again, they can just use it. This would save about 1 weeks work per project.

You're kidding about Flux being a 1 man shop right?

I bought two copies (one for gf) months ago but I haven't jumped in yet.

I'm still waiting on iWeb Pro from Apple.

The open source SproutCore framework--which Apple invested in to create its suite of MobileMe apps--has been cross-pollinating with HTML5 features to develop in new directions, including a new interface builder, rich support for multitouch, and a packaging system for sharing JavaScript code between projects.

Apple didn't "silence a developer of SproutCore". Apple told one of it's employees to not make public statements on something he was being paid to do - that happened to be SproutCore. The employee working on the company dime part gives Apple every right to have a say in the message put out by an employee. Period.

hmmm... maybe you might take another look, if you're interested... That 280Slides demo is years old, and there are now vast improvements in all areas. Cappuccino is now moving towards 1.0, and Atlas is starting to not just look but be amazing. If you can spare the $20 for that, it's definitely worth it as well.

Seriously, anyone who thinks that web development hasn't changed in the last few years needs to go look at some of the tutorials and how easy it is to build something like 280Slides, without touching HTML or CSS.

Of course, the caveat is that all of the cappuccino stuff is strictly focused on web apps and none of it applies to traditional content-focuse web pages.

Are you kidding??? GET OFF THE FORUMS!