It's interesting, but not very deep in terms of functionality.
The main exhibits here are the split panel view and the table view. Both are OK, but these problems have already been solved many times by ExtJS, Dojo, and various jQuery plugins, most of which implement many more difficult features like sorting, searching, editing, and saving state.
All else to be seen here is the meticulously reproduced skin with CSS and background images.
Things I would have been excited to see, because they are not yet well-solved amongst JS frameworks: tokenizable editable text fields, like the real Mail.app's To: field, attachments using HTML5 D&D, a quickly-searchable inbox and a drag & drop sortable treelist view for the mailboxes.
I actually think it shows a lot of promise. Though it is reasonably limited, a lot of what it does do it does well. For example, it doesn't have the extremely common problem of every piece of text being selectable, and often that selection fundamentally breaking other interactions like drag and drop.
Disabling text selection is actually really simple. All you need to do is apply user-select: none (currently available as -webkit-user-select and -moz-user-select) to the element.
Side Note: One of the major draws for me to learn Objective-J (coming from a Ruby/JavaScript background) was that I simultaneously learned a lot about Objective-C and Cocoa, which is key for iPhone/iPad apps.
I felt like I was double dipping courses in college again.
I want to apologize in advance for being so brash. I find that these demonstrations are very misleading. We all ohh and ahh, but not because of the technical accomplishment, but because of the beauty of Mac interfaces. First, sure the app is fast, it's loading the entire application from JavaScript, yet another fat client app.
Second, the capabilities that this provides seems no different than the basics of YUI, or other JavaScript widget collections with unified syntax.
Third, it's misleading to suggest that this is Mac Mail when in fact I can't search. I guess that's not a part of the Mail.app.
Fourth, 15 hours to do a main screen and a new message form, really? I'm sure that we or the guys at Cappuccino & Sproutcore could throw a similarly functioning demo together quicker.
The hard part of this example is getting the image resources, not the implementation. This implementation could've been done just as well in straight JavaScript or any other JavaScript framework just as nicely.
'This implementation could've been done just as well in straight JavaScript or any other JavaScript framework just as nicely.'
I disagree, as I've actually I've tried it in jQuery for an app built on the Titanium platform. It wasn't half as featured as this (drag and drop, multiple item selection with num of items selected display, etc) and it took much more time. Also, the speed wasn't half as fast, but that could be differences between titanium and firfox.
I'll know what the speed difference is when I try it in Ti.
I'm sure if I spent a little more time I could easily get you a list of 10 more. Again, I'm not saying that the framework isn't nice, I'm saying we shouldn't be ooh and ahhing.
This is the same thing that happened with that other framework announced here a few months ago (can't remember the name, but its in the HN archives). The fundamental problem with demos is precisely that there's a good chance someone else has done it already and its hard to tell exactly how well the framework scales up to a real app. Until you start seeing full blown apps with something, its kind of up in the air. This is why we originally did the opposite approach: we launched 280 Slides months before we made Cappuccino public, a real app with users actually creating things.
The unfortunate thing is that the "small demo" strategy really does a disservice to the framework itself: usually what happens is that competing frameworks shrug it off because they already have a demo that does the same thing (and thus don't learn from the new innovations being demonstrated), and oftentimes the "general audience" devolves into meaningless discussions about exactly how many lines of code or hours of time more or less it would have taken in some other technology.
I offer this as launch advice to anyone (as I did to the other guys here on HN):
1. Make something truly unique
2. The more "real" the better
3. Most importantly show us how you did it: I would love it if new frameworks coming out had little tutorials of these apps or better yet a video showing how the app was made as opposed to saying "it took us X hours and heres the code". You wrote this framework, for all I know you designed this framework specifically for this demo. Show me how you made this and why it was so much easier for you. For example, what we do with Cappuccino is show that you can make a similar interface with Interface Builder and nib2cib in 10 minutes, not 10 hours. If you believe that your selling point is your meta programming or whatever, then show me how it made things better in the process.
Again, I honestly haven't looked deeply enough into this to make a reasoned opinion on whether this framework is good or bad, but I see these responses a lot and I think doing the above helps avoid them and to better demonstrate what makes you "special".
The only videos I found were the screencasts on the bottom. While fine, these only demonstrate basic features, features that again are available pretty much across the board. What I want to see is them putting together this Mail app from scratch, lets have a real start and a real goal. Now, I know many frameworks don't do this, but thats precisely why it would be a huge win to have. Even we don't do this as well as we should.
Now, if the reply to this is "but the video would take 10 hours!", then unless your counting time to make the art in photoshop, there's a serious problem. If I were to do a screencast of making that Mail.app interface in Cocoa, it would literally be 10-20 minutes max. Its honestly just drag and dropping the components in in Interface Builder, then setting up the bindings and data sources.
For the most part, open source makes the irrelevant. Not that we are going anywhere, but if we dropped off the face of the planet tomorrow, Cappuccino would go on. We already have a thriving community of contributors and users who rely on Cappuccino for their own businesses, many of whom are more than capable of continuing the frameworks development.
I don't think open source makes that consideration irrelevant. It is an important factor when choosing a framework. I would bet that most of the users and probably a good portion of the contributors are using a framework precisely because it saves them from spending the time to develop/maintain those features on their own.
Cappuccino would go on, but one must acknowledge that it could certainly flounder without the solid direction, organization, and vision that brought it into the world in the first place.
I tried dragging & dropping messages in all of those samples and all I got was some highlighted text. I know they're just samples and that is "just one thing", but it's a pretty big difference.
If you don't like Uki for some reason that's fine, but you should just say it. Personally I think it looks fairly promising.
I visited your site noloh and couldn't help but notice that you're using your own tool for making that, so the main site is an web app instead of an html page.
How do you deal with the lack of content being indexed by google?
We don't, our content IS indexed by search engines. We have different rendering engines for different end users. Search Engines, Mobile Devices, JavaScript Enabled Browsers, and Non-JS enabled browsers.
I have strong doubts that your "Search-Engine-Friendly" feature can actually work in practice, at least for Google.
Google can't possibly compare your generated "crawlable" content to the actual content the user sees because of Javascript, therefore it can't detect whether the cloaking you're doing is ethical or not and it must assume the worst. What would prevent someone unethical to do exactly the same thing as you do except have the javascript display malicious content?
Second, you can't reliably detect search engines. Google is known to crawl pages with undetectable user-agents (ex: a regular-looking firefox user-agent) to make sure the content seen by Googlebot is the same as that seen by regular users. You can't just sniff crawlers reliably by their user-agent.
Sorry but I don't think this can possibly work in practice.
I understand your doubts but as you see we explain it thoroughly here http://dev.noloh.com/#/articles/Search-Engine-Friendly/. It does work, we've had this feature since 2008 and have numerous sites and users using it. If you Google for NOLOH you'll see that we show up with our content and links.
Nothing is stopping someone from doing this within their own platform maliciously and then Google will act accordingly but NOLOH as a platform doesn't allow you to and doesn't violate any rules.
tomalsky has a retort about time below: http://news.ycombinator.com/item?id=1250479. I meant us and other frameworks developing as an individual, not a team. Sorry for the confusion.
Cappuccino & Sproutcore are in fact free & Open Source. If your edit is in reference to NOLOH not being open source and free, it is in fact free for developers to develop, Open Source Projects, Educational institutions and Non-Profits as you can see here http://www.noloh.com/#/products/.
We also offer completely free hosted sandboxes to develop in. This includes free storage, bandwidth and hosting.
However, if you're a business that plans to make money with your work and NOLOH can aid you in that then we believe that we too should be paid for our work. We and many others believe that NOLOH easily pays for itself in a short period of time. Furthermore, paid licenses also come with a significant amount of support.
I really see no reason for being an ass like this. The guy made something, embrace it or leave it. Constructive criticism is valuable, but telling "…I can do it better" serves no other purpose than being negative.
I think the point is, the title "Mail.app implemented on the web using ukijs" is wrong.
It's pretty easy to clone a UI so something looks like something else. It's easy enough to then add a bit of data so it sort of feels like it as well. But building a real world fully functioning app takes a bit more work.
Asher, awhile ago you told me you could clone 280 Slides using NOLOH relatively quickly, and now this. Do you have any examples of similarly rich and polished applications built using NOLOH? I'm genuinely curious, because the only NOLOH application I've seen is your website.
I did, unfortunately, other things crept to the top of our list and it didn't make sense to invest any resources into that effort. We also realized that it would mostly piss you guys off.
Unfortunately many advanced applications are not public as their user generated and many are intranet or still in stealth mode. While we encourage all our users to post to our website, not all do. We'll finally be launching a demos section in the coming month where you should be able to see a plethora of examples and advanced applications.
...other things crept to the top of our list and it didn't make sense to invest any resources into that effort. We also realized that it would mostly piss you guys off.
Wait, really? You didn't build something as a demo of your platform because it might piss off your competition and because you don't have time to build something on your platform? How are you getting customers? How are you building a community? Honestly, it comes off that you're blowing smoke.
I'm sure replying is futile since there appears to be a dedicated anti-asnyder block here voting me down to oblivion.
Yes, really. Believe it or not we run into the 280north guys from time to time and building an app just for apps sake without it being a part of any comprehensive strategy is a waste of resources. Within a small company time is very valuable and if we take the time to build the 280Clone as we initially called it it would take resources away from adding new features, documentation and other demos.
What tlrobinson doesn't mention was that our conversation regarding the clone took place 2+ years ago, in his post it sounds like it was a short while ago.
We're getting customers because our platform fulfills what it says it does as you can see from some of our users blogs, take Gary's for example, http://geester.tumblr.com/.
Clearly you don't like me as an individual, maybe I'm too brash for your taste, but it's important to remember that NOLOH isn't me, we're a company with other members, other employees.
Please don't discount our platform because you don't like me.
I don't know you so it's a bit presumptuous to say that I clearly don't like you. However, I definitely don't appreciate your blase attitude towards civil, straightforward questions, especially when they are asked by community members who give so much back to all of us (i.e. tlrobinson's Narwhal, Cappuccino, Jack, etc).
Also, I don't see how having 2+ years to build a 280Atlas clone tips the balance of the scales in your favor in this case. One would think that would be plenty of time.
Anyhow, don't worry, I won't discount your Not One Line Of HTML platform based on your comments. It's name alone is enough for me to know it's not my cup of tea. I'm quite happy and comfortable writing my own HTML as I please.
Your response is very odd to me. You value tlrobinson's contribution Cappuccino even though from your statements your perfectly happy writing your own HTML. So Cappuccino doesn't benefit you in the same way that NOLOH doesn't benefit you.
This may be that you too are in California and clearly me being an infrequent visitor to that community I'm an outsider and should be punished!
We too contribute to various open source projects. We even open source all our modules. As you can see from my profile I've been a member of this community a very long time. I'm simply frustrated by the excessive downvoting I received. tomalsky posted a comment suggesting they too could emulate the mail.app, he listed a time of 10 minutes, but noooo, don't downvote him, he's tomalsky.
The 2+ years was trying to emphasize that this was old news, and not a recent occurrence. We decided a long time ago to not move forward with that project.
"Fourth, 15 hours to do a main screen and a new message form, really? I'm sure that we or the guys at Cappuccino & Sproutcore could throw a similarly functioning demo together quicker."
It's been seven hours. How's your functioning demo coming along?
I think that building web apps that look/feel like desktop apps is a step in the wrong direction. Some of the best web apps around like Gmail, Maps, Facebook, Twitter, Wordpress etc represent a complete break from traditional desktop software and I actually like that.
You can almost think of the browser viewport as a blank canvas on which you can draw pretty much anything. Desktop apps feel much more constrained in terms of UI & appearance. I think web apps - if done right - look and feel much better than most desktop apps anyway.
Not to take way from what the OP accomplished.. That's some serious javascripting and I like his approach much better than Cappuccinos
47 comments
[ 3.5 ms ] story [ 109 ms ] threadIt seems pretty interesting.
The main exhibits here are the split panel view and the table view. Both are OK, but these problems have already been solved many times by ExtJS, Dojo, and various jQuery plugins, most of which implement many more difficult features like sorting, searching, editing, and saving state.
All else to be seen here is the meticulously reproduced skin with CSS and background images.
Things I would have been excited to see, because they are not yet well-solved amongst JS frameworks: tokenizable editable text fields, like the real Mail.app's To: field, attachments using HTML5 D&D, a quickly-searchable inbox and a drag & drop sortable treelist view for the mailboxes.
I think the biggest advantage to Cappucino is that, if you already know the Cocoa framework, there is less to learn.
I felt like I was double dipping courses in college again.
> "Models store, load and transform the data from the server."
But the ukijs.org states:
> "Uki doesn't want to be a Jack-of-all-trades. It only does layout but it does it well. You won't find any ajax or data storage layer code here."
Which one is it?! (I'd much prefer the former)
I want to apologize in advance for being so brash. I find that these demonstrations are very misleading. We all ohh and ahh, but not because of the technical accomplishment, but because of the beauty of Mac interfaces. First, sure the app is fast, it's loading the entire application from JavaScript, yet another fat client app.
Second, the capabilities that this provides seems no different than the basics of YUI, or other JavaScript widget collections with unified syntax.
Third, it's misleading to suggest that this is Mac Mail when in fact I can't search. I guess that's not a part of the Mail.app.
Fourth, 15 hours to do a main screen and a new message form, really? I'm sure that we or the guys at Cappuccino & Sproutcore could throw a similarly functioning demo together quicker.
The hard part of this example is getting the image resources, not the implementation. This implementation could've been done just as well in straight JavaScript or any other JavaScript framework just as nicely.
I disagree, as I've actually I've tried it in jQuery for an app built on the Titanium platform. It wasn't half as featured as this (drag and drop, multiple item selection with num of items selected display, etc) and it took much more time. Also, the speed wasn't half as fast, but that could be differences between titanium and firfox.
I'll know what the speed difference is when I try it in Ti.
http://demos.telerik.com/webmail/
http://gwt.google.com/samples/Mail/Mail.html
http://developer.yahoo.com/yui/examples/layout/adv_layout_so...
I'm sure if I spent a little more time I could easily get you a list of 10 more. Again, I'm not saying that the framework isn't nice, I'm saying we shouldn't be ooh and ahhing.
Thanks for the other handle on the jug, the devil's avocation and the report about the color of the vegitation other side of the fence.
The unfortunate thing is that the "small demo" strategy really does a disservice to the framework itself: usually what happens is that competing frameworks shrug it off because they already have a demo that does the same thing (and thus don't learn from the new innovations being demonstrated), and oftentimes the "general audience" devolves into meaningless discussions about exactly how many lines of code or hours of time more or less it would have taken in some other technology.
I offer this as launch advice to anyone (as I did to the other guys here on HN):
1. Make something truly unique
2. The more "real" the better
3. Most importantly show us how you did it: I would love it if new frameworks coming out had little tutorials of these apps or better yet a video showing how the app was made as opposed to saying "it took us X hours and heres the code". You wrote this framework, for all I know you designed this framework specifically for this demo. Show me how you made this and why it was so much easier for you. For example, what we do with Cappuccino is show that you can make a similar interface with Interface Builder and nib2cib in 10 minutes, not 10 hours. If you believe that your selling point is your meta programming or whatever, then show me how it made things better in the process.
Again, I honestly haven't looked deeply enough into this to make a reasoned opinion on whether this framework is good or bad, but I see these responses a lot and I think doing the above helps avoid them and to better demonstrate what makes you "special".
The biggest concern for me, a user considering frameworks is always: 'how long are these guys going to be around'
Now, if the reply to this is "but the video would take 10 hours!", then unless your counting time to make the art in photoshop, there's a serious problem. If I were to do a screencast of making that Mail.app interface in Cocoa, it would literally be 10-20 minutes max. Its honestly just drag and dropping the components in in Interface Builder, then setting up the bindings and data sources.
Cappuccino would go on, but one must acknowledge that it could certainly flounder without the solid direction, organization, and vision that brought it into the world in the first place.
If you don't like Uki for some reason that's fine, but you should just say it. Personally I think it looks fairly promising.
How do you deal with the lack of content being indexed by google?
Please see http://dev.noloh.com/#/articles/Search-Engine-Friendly/ for more information about our Search Engine rendering.
Google can't possibly compare your generated "crawlable" content to the actual content the user sees because of Javascript, therefore it can't detect whether the cloaking you're doing is ethical or not and it must assume the worst. What would prevent someone unethical to do exactly the same thing as you do except have the javascript display malicious content?
Second, you can't reliably detect search engines. Google is known to crawl pages with undetectable user-agents (ex: a regular-looking firefox user-agent) to make sure the content seen by Googlebot is the same as that seen by regular users. You can't just sniff crawlers reliably by their user-agent.
Sorry but I don't think this can possibly work in practice.
Nothing is stopping someone from doing this within their own platform maliciously and then Google will act accordingly but NOLOH as a platform doesn't allow you to and doesn't violate any rules.
I'm sure that we or the guys at Cappuccino & Sproutcore could throw a similarly functioning demo together quicker.
Well go ahead then. Still keep in mind that you're comparing the efforts of big teams with the efforts of ONE guy.
(edit: oh and his framework is also open source and free)
Cappuccino & Sproutcore are in fact free & Open Source. If your edit is in reference to NOLOH not being open source and free, it is in fact free for developers to develop, Open Source Projects, Educational institutions and Non-Profits as you can see here http://www.noloh.com/#/products/.
We also offer completely free hosted sandboxes to develop in. This includes free storage, bandwidth and hosting.
However, if you're a business that plans to make money with your work and NOLOH can aid you in that then we believe that we too should be paid for our work. We and many others believe that NOLOH easily pays for itself in a short period of time. Furthermore, paid licenses also come with a significant amount of support.
It's pretty easy to clone a UI so something looks like something else. It's easy enough to then add a bit of data so it sort of feels like it as well. But building a real world fully functioning app takes a bit more work.
There's a list of some of our users' websites at http://www.noloh.com/#/poweredby/, and there's also a video demonstration that we recently did at Confoo showcasing a few applications http://www.youtube.com/watch?v=qLFc-aF2fDI.
Unfortunately many advanced applications are not public as their user generated and many are intranet or still in stealth mode. While we encourage all our users to post to our website, not all do. We'll finally be launching a demos section in the coming month where you should be able to see a plethora of examples and advanced applications.
Wait, really? You didn't build something as a demo of your platform because it might piss off your competition and because you don't have time to build something on your platform? How are you getting customers? How are you building a community? Honestly, it comes off that you're blowing smoke.
Yes, really. Believe it or not we run into the 280north guys from time to time and building an app just for apps sake without it being a part of any comprehensive strategy is a waste of resources. Within a small company time is very valuable and if we take the time to build the 280Clone as we initially called it it would take resources away from adding new features, documentation and other demos.
What tlrobinson doesn't mention was that our conversation regarding the clone took place 2+ years ago, in his post it sounds like it was a short while ago.
We're getting customers because our platform fulfills what it says it does as you can see from some of our users blogs, take Gary's for example, http://geester.tumblr.com/.
Clearly you don't like me as an individual, maybe I'm too brash for your taste, but it's important to remember that NOLOH isn't me, we're a company with other members, other employees.
Please don't discount our platform because you don't like me.
Also, I don't see how having 2+ years to build a 280Atlas clone tips the balance of the scales in your favor in this case. One would think that would be plenty of time.
Anyhow, don't worry, I won't discount your Not One Line Of HTML platform based on your comments. It's name alone is enough for me to know it's not my cup of tea. I'm quite happy and comfortable writing my own HTML as I please.
Your response is very odd to me. You value tlrobinson's contribution Cappuccino even though from your statements your perfectly happy writing your own HTML. So Cappuccino doesn't benefit you in the same way that NOLOH doesn't benefit you.
This may be that you too are in California and clearly me being an infrequent visitor to that community I'm an outsider and should be punished!
We too contribute to various open source projects. We even open source all our modules. As you can see from my profile I've been a member of this community a very long time. I'm simply frustrated by the excessive downvoting I received. tomalsky posted a comment suggesting they too could emulate the mail.app, he listed a time of 10 minutes, but noooo, don't downvote him, he's tomalsky.
The 2+ years was trying to emphasize that this was old news, and not a recent occurrence. We decided a long time ago to not move forward with that project.
It's been seven hours. How's your functioning demo coming along?
You can almost think of the browser viewport as a blank canvas on which you can draw pretty much anything. Desktop apps feel much more constrained in terms of UI & appearance. I think web apps - if done right - look and feel much better than most desktop apps anyway.
Not to take way from what the OP accomplished.. That's some serious javascripting and I like his approach much better than Cappuccinos