Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment: More Full Response (Score 4, Insightful) 157

I made a comment to a poster over on the original posting of this. I think it's worth expanding upon in case people are persuaded by the arguments in the paper.

First off, just as TFA predicts, I'm not going to try to conquer his mountain of facts and experts by presenting a mountain of citations. Instead, I'm going to point out where his conclusions are not supported by his facts and point out his straw man arguments and his attempt to convince us through overwhelming expert opinion.

The straw man: In the article, he presents two scenarios (photo editing and video streaming) and claims that you can't reasonably do those because of memory limitations (on the iPhone/iPad). He then concludes you can't produce useful apps because you can't do those two. I couldn't find any citations of people attempting to do this on mobile using JavaScript. Choose the right tool for the job here. I'll give him these two use cases (and several others: 3D Games, audio processing, etc), however to extrapolate from here that no useful apps can be produced (ever!) using JavaScript is a leap too far.

Next, he spends a lot of time diving into the particulars of garbage collection (GC). I'm going to grant him practically every point he made about GCs. They're true. And, it's true that mobile is a constrained environment and you must pay attention to this. But, this is largely known by developers who are trying to write high-performance JavaScript applications on mobile. Hell, -anyone- writing high-performance apps in any language need to be aware of this. If you allocate memory during your animation routines in a game you're asking for trouble, regardless of the language. So, to me, this part is just a call to pay attention to your memory usage in your apps. This is really useful advice and I will be paying even more attention to the new memory tools available in the latest Google Chrome dev tools.

One of the biggest problems in the rant is the comparison of pure computing performance and his claim that ARM will never be as fast as desktop. I'm going to again grant that this is true. However, this means crap-all for most apps. Tell me: How many apps do you have one your phone that are processor bound? None? One? Two? The vast majority of apps spend their time either waiting on the user or, possibly, waiting on the network. You can write a lot of really useful apps even given constrained processor and memory. Anyone remember the Palm Pre? The TouchPad? Most of those apps were JavaScript and they worked just fine.

This brings me to the point of all this, TFA's author focuses on performance. However, users focus on responsiveness. JavaScript is perfectly capable of producing responsive applications. Sometimes, it takes attention to detail. Nothing is ever 100% free and easy. JavaScript is not a magic solution and those of us who think that JavaScript has a future in mobile app development know this. This is why programmers get the big bucks. Writing mobile apps, you need to be aware of the effects of CSS, memory, processor, responsiveness and more.

Comment: Re:Easy (Score 1) 407

by El Royo (#44247317) Attached to: Why JavaScript On Mobile Is Slow
A flippant answer but it misses the point. As does the original article. It's true that writing performant mobile apps is hard. But it's always true that writing good code that has to perform in a constrained environment requires attention to performance and memory.

However, one thing that JavaScript libraries tuned for mobile provide is an optimized approach to common problems that are handled differently on different mobile browsers. The framework I use (and I wrote the book on it, literally) is Enyo. As a simple example, Enyo provides a number of scroll strategies that it choose from based upon the OS and even the version. Are you aware of all the bugs in the various versions of the Android browser? How about the bugs introduced in one version iOS and fixed in the next? Having a framework deal with the wildly different browser implementations so you can focus on actually, you know, writing an app is important.

The original article goes to great lengths to talk about GC and brings up the strawman of video streaming and image manipulation. If you want to do those on mobile today, go native. If you want JS as a front-end, use PhoneGap. Pick the right tool for the job. He then talks about pure programming performance. Tell me, how many apps do you have on your phone that are processor bound? I would guess almost all of them sit around and do nothing until you tap a button. Responsiveness is completely different from outright performance and it's completely possible to write rich, responsive apps in mobile using JavaScript.

Comment: Re:I am the Author (Score 2) 46

by El Royo (#42942093) Attached to: Book Review: Enyo: Up and Running
I'm sure there'll be some cross-pollination between ExtJS/Sencha and Enyo. We always say that Enyo was 'mobile first' instead of something that came from a desktop browser world and moved down. I'm not sure there's any animosity between Enyo and those guys. Right now, Enyo has taken a more lightweight approach and doesn't have the dataviews, stores and readers/proxies you mention (though I'm not familiar with ExtJS enough to know those features well enough to know if there are analogues). Our new MVC bindings based on Backbone are intended to address the more data-heavy requirements of enterprise apps. I hope to be able to do a talk about the way open source projects can leverage other open source projects someday.

Comment: Re:How unique! (Score 2) 46

by El Royo (#42939621) Attached to: Book Review: Enyo: Up and Running
1) There is no more ubiquitous platform for distributing apps than the browser these days. You can't deploy C,C++,C# into the browser cross-platform today. And even if you could, you'd still need a framework to handle the UI. Java, given the security problems lately, isn't even a good bet for distributing apps cross-platform and doesn't exist on many mobile devices (e.g. iOS). JavaScript performance is quite good these days. Using Enyo you can target desktop web, mobile web and mobile apps with the same codebase.
2) To me, an app is different from a web page in that it provides interactive content without the need for a page refresh/reload.
3) (Get off your lawn?) Frameworks (in any language) are important for getting work done. Yes, you can hand-code a CMS in PHP if you wanted to, but why would you? HTML (even in the latest incarnations) doesn't provide all the controls people expect from interactive applications. JavaScript has some warts and a framework can help. Mobile and desktop browsers have any number of bugs that must be worked around for high-performance and well behaved apps, Enyo helps with this.

If you don't need to create cross-platform apps then you don't need to check out Enyo. If you already know HTML/JavaScript/CSS and need to get into Apps, then Enyo just might be for you.

Comment: I am the Author (Score 3, Informative) 46

by El Royo (#42939501) Attached to: Book Review: Enyo: Up and Running
It's worthwhile noting that all the jsFiddle samples have been fixed. I can assure you they did work at the time the book was published.

I do intend for the book to continue to grow as Enyo does (there will be a chapter soon on the forthcoming Enyo MVC addition, for example) and I will definitely fix the (very few) typos so the electronic versions are updated.

Now, having dispensed with those, I need to point out that Enyo: Up and Running was intended as an introductory text, not a reference book. The Enyo Web site (which is very good) should always serve as the reference. This book, I think, does exactly what it was intended to: Introduce the key features of Enyo and explain how the fit into the broader context of the framework. The first chapter of the book is intended to give the reader a flavor for the development process with Enyo and how certain concepts are applied. I think moving it later into the book would diminish the value in it.

Finally, some responses to specific comments: Regarding the unused parameter, this is an interesting question I struggled with a bit. JavaScript doesn't care if you provide the appropriate number of parameters and it doesn't care if you use them or not. As a teaching text, the book shows all possible parameters whether used or not so that the reader knows they are available. I could easily have left them out of the samples, but at the risk of hiding their availability. Regarding the uses of CSS, I decided to save styling using CSS until the chapter on styling so as to not confuse the issue. Break tags fit within the flow of the sample and show off how to use the 'tag' property. I don't see that they are 'wrong' in any way.

Enyo is a relatively new framework (in its open source form) but has a strong legacy from the webOS days, as others point out. I find it very useful and I think it neatly addresses the many shortcomings of producing cross-platform apps. JavaScript is ubiquitous and the deployment options mean you're not beholden to Apple, Google or any other provider. I urge you to check out Enyo, even if you're not interested in the book. There's a lot to like there.

Comment: I am the author (Score 1) 1

by El Royo (#42925883) Attached to: Enyo: Up and Running
I was very stunned to find out the jsFiddle samples stopped working. I have updated the gists to remove the bad character and everything should be working fine on the gists. I will submit an update to the electronic versions that fix the typos tomorrow. I welcome the feedback and will see what I can incorporate into volume 2.
Book Reviews

+ - Enyo: Up and Running 1

Submitted by
Michael Ross
Michael Ross writes "Upon hearing the name "Enyo," one may wonder if the speaker is referring to the Greek war goddess, or if it is the name of some Celtic New Age music with a Latin twist. In the world of front-end software development, Enyo is a cross-platform open-source JavaScript framework that can be used to build HTML5 web applications for the desktop and for mobile devices, including those powered by iOS and Android. The project website bills it as "an object-oriented JavaScript application framework emphasizing modularity and encapsulation." Any programmer interested in learning Enyo — or at least exploring what it is capable of — can consult the online documentation and the forums, but a more time-efficient approach might be to read a book focusing on the topic, such as Enyo: Up and Running, written by Roy Sutton, a contributor to the project.

The book was published by O'Reilly Media on 6 February 2013, under the ISBN 978-1449343125. (My thanks to O'Reilly for providing a review copy.) On the publisher's page, visitors can find limited information about the book and its author, some reader reviews, links to purchase the electronic and print versions, and a page for errata (of which there are none, as of this writing). At 74 pages in length, this title comprises seven chapters, plus an appendix explaining how to set up a local development environment for working with Enyo, with a few options to choose from. Thus, the appendix is where most readers should and likely will start. In the preface, the author notes that the book assumes "some familiarity with HTML, CSS, or JavaScript"; that "or" should be an "and," since all three technologies are foundational to Enyo.

The first chapter introduces Enyo by examining a fairly simple web app — one that displays a traffic light on the web page. Naturally, in a black-and-white book such as this, the red/yellow/green colors are all in grayscale. Much more importantly, of the seven jsFiddle-hosted code examples provided in the chapter, the first five do not work (as of this writing), apparently because in each case there exists in the code some sort of control character, displayed as a red dot. (In the third example, the dot character is in the JavaScript and not the HTML.) Readers should delete that character and click the "Run" button, to see the intended results. The last two examples work only because the dot character comes after the closing </script> tag. It is baffling how these flaws could have gone undetected by the production staff and technical reviewers.

The material seems to raise as many questions as it answers. Assuming that the code printed in the book works (no downloadable code archive is offered), readers will probably be left pondering questions such as: Is create: function() some sort of constructor? Why isn't a new color passed through the call this.colorChanged()? Why is oldValue apparently not used? Where is setColor() defined? While it is a good idea to entice the reader to try a new technology by showing its capabilities, if that reader is expected to understand the example code presented, then it should be fully explained; otherwise, it should not be presented. As an alternative, the author could have limited the discussion to what functionality Enyo provides to the programmer, without listing source code in print or on jsFiddle. This would have provided the reader with greater motivation to invest the time and effort in learning what can be a challenging subject.

As a result of these early problems, this first chapter does not get the book off to a promising start. The second chapter, "Core Concepts," is perhaps the one that should have begun the book, because it describes many of the core ideas critical to Enyo: kinds, encapsulation, published properties, events, signals, inheritance, constructors, and statics. However, the pace is too fast for beginners, and more examples are needed to explain the concepts, step-by-step. By the bottom of page 11, countless readers will likely be bewildered with the terse discussion of getter and setter functions, "changed" functions, construction, and passed values (which are properties or not). Also, readers will again encounter the aforesaid problem of the red dot character breaking the example code on jsFiddle. (Further instances in the book will not be documented here.) The third chapter continues the discussion, focusing on components, menu and form controls, and functions, as well as some components for animation and making web requests. All of the information looks correct. The only puzzling aspect is why break tags are used (on page 22) instead of a CSS display: block; declaration.

User interface is addressed in the next two chapters, the first of which presents layout components commonly needed for Enyo apps — scrollers, repeaters, fittables, lists, and panels. The second one explores CSS styling of an Enyo app, performance considerations of apps on handheld devices, debugging, common mistakes, jsFiddle, internationalization, and localization. With these chapters, the narrative in the book becomes noticeably more comprehensible.

The penultimate chapter — essentially comprising two pages — delineates some options that the Enyo developer has for deploying a newly-built app to any one of the supported platforms. This chapter, like all the earlier ones, ends with a summary that is so brief, and applicable to so few pages, that each one seems pointless. Why do publishers feel obligated to include these useless chapter summaries in almost every technical book? The final chapter is a one-page conclusion, in which the author encourages readers to learn more and become involved in the Enyo community.

This book is more of an introduction, although no reason is provided as to why it was not instead made a more extensive treatment of the subject. Upon completing the book, the average reader will probably conclude that she did not absorb enough knowledge of the Enyo core to begin immediately developing apps using this framework, and the best course of action might be to start over again on page 1, or perhaps seek out a second source, before optionally returning to this one for a second run-through. The material could have been structured so all information is presented sequentially — so the reader does not encounter concepts yet unseen — with more step-by-step explanations.

Rather than presenting the reader with code snippets that have no relation to one another, it would have been much more interesting and motivating if the author had devised and explained code that incrementally builds into a nontrivial app. Furthermore, the example source code should have been made available on the publisher's website, so readers could avoid typing it from the text or extracting it from jsFiddle if they wished to try it in their local development environments.

In terms of typography, the font size of this book is a bit too small, especially for extended reading, and for people with subpar vision. This is even more true for the code snippets, which are in an even smaller font. In many of the lines of prose, the words are too close to one another — a problem exhibited in a few other recent O'Reilly titles. Did the production team feel it necessary to further compress a 74-page book?! In fact, proper names, such as those of components, are oftentimes broken between two lines in the text — sometimes nonsensically, e.g., "FittableR" followed by "owsLayout" (page 32). The book contains several errata: "This is [not] to say" (page viii), "such as [a] local installation" (viii), "url" (27), "we might modify add" (34), "woud" (35), "one [of] the most" (35), and "allow you [to] easily debug" (56). For such a slender volume, the production quality seems to have received less attention than it deserved.

Overall, this offering does not reach O'Reilly's usual high standards. It's a shame, because it seems like such a promising topic — one that could be more thoroughly explored in a larger volume. Perhaps this feedback, and that of other readers, could be folded into a second edition. This is a real possibility, given that the author notes in his conclusion that he considers the book an active project, and intends to keep it up-to-date with the changes to Enyo itself. In the meantime, this is a promising start that can give readers a taste of Enyo's potential for building modern web apps for desktop and mobile platforms.

Michael Ross is a freelance web developer and writer."

Comment: An education wouldn't hurt (Score 0) 433

by El Royo (#42420115) Attached to: Ask Slashdot: CS Degree While Working Full Time?
If you do want advancement it might be a good idea to take some courses in English grammar. Since you're specifically talking about eligibility for hiring (and presumably advancement) then I feel justified pointing out your grammar could use some work. I don't know whether the 'editors' have even fixed up some of the more egregious problems in the post but your e-mails and resume convey a lot to people who read them. As someone who has hired programmers, I tend to get a negative impression of people who are sloppy with their writing.

Comment: Freefall (Score 1) 321

by El Royo (#42400613) Attached to: Ask Slashdot: What Was Your Favorite Web Comic of 2012?
Surprised to not see anyone recommend Freefall (http://freefall.purrsia.com). For art, I am really taken with A Redtail's Dream (http://minnasundberg.fi/) and The Bean (http://www.beanleafpress.com/). Aw, hell, and The Abominable Charles Shaw (http://www.abominable.cc/). Too many good ones for me to choose just one. My list just keeps growing so I'll stop.

"The way of the world is to praise dead saints and prosecute live ones." -- Nathaniel Howe

Working...