Contents of RSS feed for:

Dan Bricklin's Log
VisiCalc co-creator Dan Bricklin chronicles his life in the computer world with pictures, text, and commentary.
Essay about issues and techniques related to disconnected mobile apps
We're spending a lot of time at Alpha Software working on making it easier to create mobile business apps that support sometimes- or frequently-disconnected operation. As part of that work, I've learned a lot about how this issue is an impediment to widespread mobile app deployment in business and also about many of the areas that must be addressed in order to do it well. I've just posted an essay that covers a lot of what I've learned.

You can read "Dealing with Disconnected Operation in a Mobile Business Application: Issues and Techniques for Supporting Offline Usage" in the Writings section of my web site.

[Image in the original post on Dan Bricklin's Log with caption: The Offline Problem: Some common images of low connectivity]
Published: Tue, 15 Jul 2014 19:22:56 GMT
HTML5 First: Google innovators prototype in the browser
Two days ago, on Wednesday, I watched the Google I/O Keynote live stream. Early on in the two and a half hour mega-presentation they introduced their new "visual language" for UI design: Material Design. It has "materials" inspired by paper with shadows, bold colorful graphics, and "meaningful" motion/animation.

As a developer who makes heavy use of HTML5, what immediately struck me was this statement, made starting at about 20:20 into the video:

"Last year at I/O we announced Polymer, which is a powerful new UI library for the web.

Today, we're bringing you all of the Material Design capabilities to the web through Polymer. [Applause] As a web developer, you'll be able to build applications out of Material Design building blocks with all of the same surfaces, bold graphics, and smooth animations at 60 frames per second. [More applause, followed by the speaker smiling and ad-libbing: "That was good..."]

So, between the L preview and Polymer, you can bring the same, rich, fluid Material Design to every screen."

Wow, I thought, Google not only designed a mobile UI for their Java-driven devices, they went to the trouble of also then building it in HTML5 for web apps (mobile and desktop).

I was wrong. I did some looking at the documentation for Polymer, and in the FAQ I found this (emphasis added):

How is Polymer related to material design?

Polymer is the embodiment of material design for the web. The Polymer team works closely with the design teams behind material design. In fact, Polymer played a key role in material design's development: it was used to quickly prototype and iterate on design concepts. The material design components are still a work in progress, but will mature over the coming months.

So, the HTML5 version wasn't created after the native versions. It was the prototyping environment before the native code.

This is a great model to follow: Prototype, iterate, and even first ship, in HTML5. Once you know what you need, if necessary, take the time to do native code. This doesn't just apply to the old desktop (as it has for years). It also applies to today's polished, fluid mobile world.

As a developer who is closely connected to a system that produces HTML5, and that aids in rapid prototyping, I was delighted. Here are some of the leading-edge mobile developers, and they found that HTML5 has the power to do what they want, and do it quickly enough for the demands of the iterative design and testing that is so important in the mobile world. After hearing so many people claiming that "they hear" that HTML5 doesn't have the power for serious mobile applications, it was vindication to hear of people who actually build things choosing to go the HTML5 route, even when cost clearly wasn't the object, and succeeding.

To be fair, the Material Design developers did depend on the latest browser versions, which have built-in support for hardware-accelerated animation and compositing, and on a sophisticated JavaScript library to make coding easier. However, most mobile devices are now getting upgraded frequently to the latest browsers (Google announced better upgrading for Android in the same keynote and Apple brags about the large percentage of iOS users who run the latest version) and most mobile HTML5 developers and systems (the one I use included) make use of such libraries already.

I guess it's time for a new moble-related tag: #HTML5first.
Published: Fri, 27 Jun 2014 18:24:21 GMT
A new app from Dan and Alpha: AlphaRef Reader
For various reasons I decided that I needed an app tuned to reading reference material. I've released a new app that demonstrates addressing this need to the Apple App Store and the Google Play Store: AlphaRef King James Version of the Bible. This is the text of the Bible presented in a new reading environment that I created along with my daughter Adina, a UX and graphics designer. It is implemented using Alpha Anywhere and delivered as an HTML5 app in a PhoneGap wrapper.

To read the whole story, and to see a video of the app in action, read "AlphaRef Reader: Tablet-first design of an app for reading reference material" in the Writings section of my web site.
Published: Tue, 20 May 2014 16:29:54 GMT
BCS Mac Introduction Meeting video is now available -- how that came about
The January 30, 1984, video of the introduction of the Macintosh to the public at a Boston Computer Society General Meeting is now available online. Harry McCracken, an editor at large at TIME for personal technology, posted an exclusive look at the video early this morning, right after excerpts where shown at the Mac 30th event in California (an "official" event marking the 30th anniversary of the original Mac announcement at the same place where it occurred). The Computer History Museum will be posting material on its web site tomorrow, and will update the video when additional processing of it finishes.

See "Exclusive: Watch Steve Jobs’ First Demonstration of the Mac for the Public, Unseen Since 1984" on TIME.com.

Harry explains how there were other videos of prior deliveries of Steve Job's talk introducing the Mac, but that this one is special for several reasons, some of which I have touched upon in my blog post Friday about it, such as the Q&A with a general tech audience. He also explains a bit about how the release of the video came about. Let me fill in a bit more.

These were not fully "lost" videos. I have had my copy of the January 1984 VHS tape for years and let others know I had it, showing excepts sometimes when I gave talks. Given the use of Apple material, and the special nature of the video, I did not feel it was time to release it yet to the public as I was slowly doing with other videos I have (not BCS ones). I was in contact with the videographer, Glenn Koenig, who shot most of the BCS meetings on Software Arts' behalf over the years. He let me know that he had masters of many of them, though he hadn't cataloged them (and didn't search out the Jobs one until Harry asked, which yielded better versions of parts of the presentation). I let him know of the material that I had made sure made it to the Computer History Museum. I encouraged him to continue to maintain his tapes in good condition, which is what he has been doing all these years.

We always intended to complete the edits of this material, but there is a lot of it, and digitizing it properly and editing it takes a lot of time and money. We didn't have the funds to do that and it was unclear if others would chip in and how to bring that about. Doing the work prematurely with the wrong equipment could compromise the tapes. (Of course, waiting too long could cause them to deteriorate too much.)

When Harry, a BCS member going back to the VisiCalc days, contacted BCS founder Jonathan Rotenberg in the fall of 2012 to ask about video from BCS meetings, Jonathan got him in contact with Glenn. Glenn, Jonathan, and I brainstormed about ways to finally make the restoration and release happen. I contacted Ray Ozzie, who I knew was interested in historic videos and had worked with us at Software Arts in the early 1980's. He, like Harry, suggested the Computer History Museum as a means for funding instead of something like Kickstarter. I have been a long-time supporter of the Museum, and have been inducted as one of their "fellows" for my work on VisiCalc, and knew this was the right way to go.

Eventually, Jonathan, Glenn, and I started working with people at the Museum, cataloging which material we had between us, and worked up a budget and a plan for fundraising. Glenn pointed out the upcoming 30th anniversary of the Mac as a good "news hook" and that a hoped-for article by TIME could help publicize the entire set (thank-you, Harry, for coming through with a great one!). We met periodically on the phone (we all had other jobs to keep us very busy) and eventually crafted a "request" letter and a list of potential donors. Glenn produced a short trailer of excerpts from a few of the tapes using some refurbished equipment to show those people.

In September of last year we had the material ready for fundraising and I hand-signed (and in some cases added a little note to) a few dozen letters and mailed them out. Within a little while some money trickled in. Then, Brad Feld, a friend from the early Trellix days now living in Colorado, contacted me for more information. Within a few days he and his wife Amy became the major funders, ensuring that the project was well off the ground. He also helped us by reaching out to some of the people I had approached, too. We have since raised enough to do this project well, and hopefully even do additional tapes that are surfacing, though the Museum could always use additional funds for such things.

The people producing the video for the Mac 30th event, most importantly Gabreal Franklin, helped Glenn work out details and ensured that there would be quality video for their event, both from the January 1984 video and some other.

For many reasons, including the difficulty in getting the slides shown the way we need them, the current version of the Mac Introduction is just a "rough cut". There is more editing that will occur. In any case, Glenn did many late nights to make this happen on time.

Now that everything is set up, we will be processing other videos, too, and release them in batches. I'll write more about them when they are available. To me, some are of them are of the same historic value as this one, if not more.

The Mac Introduction video has served its purpose well. It has drawn attention to the Boston Computer Society and the other videos, and to the Museum. It has helped a new generation see what happened in the early days of the PC revolution, and an older generation remember their past, and helped chronicle the thinking of the time for posterity. It has also helped fill in the record of the life of a giant of our industry, capturing an interaction with the users of his works like no other.
Published: Sun, 26 Jan 2014 20:55:46 GMT
The Mac turns 30 and because we preserved the history you will be able to relive it
Today is 30 years since the Apple Macintosh was announced. That event occurred at a shareholders meeting in California. The following Monday, Steve Jobs and a crew of people from Apple traveled to Boston, Massachusetts, to redo that event for the public. It was at the Boston Computer Society General Meeting on January 30, 1984, at the John Hancock Hall in Boston.

In addition to Steve's speech and demonstration, he also brought many of the developers of the Mac software and hardware with him. After his presentation, they all sat on stage and answered questions from the audience and did further demos. For the over 1,000 people who attended, it was an amazing event. At the shareholders meeting there was the worry of how it would be received and if the demos would work. At the BCS meeting there was much less pressure and Steve was relaxed and confident and engaged the audience. The attendees were knowledgeable and savvy.

There is something else about the Boston event: My old company, Software Arts, at my suggestion as I recall, was paying to have video tapes made of many of the BCS General Meetings. (I was a board member of the BCS at various points). For this event, Apple provided additional cameras and made sure the lighting was good (it was not good in California, apparently).

We at Software Arts ended up with an edited VHS copy of the event that I have kept for these 30 years and sometimes show excerpts from when I talk to students to show them what it was like in the "old" days. I also would show it to my daughters to let them see how a real pro delivered a speech. At this point I know Steve's intonation on every syllable of the start of his presentation. (It's different than when he gave it in California.)

What happened last year is something wonderful: It turns out that many of the original BCS meeting tapes still exist. Some were donated to the Computer History Museum with my help. Many of the master tapes were still with the videographer, Glenn Koenig, including 3/4" tapes that are higher quality than the VHS copies. Together with Glenn and Jonathan Rotenberg (the founder and initial head of the BCS), we finally started a project with the Computer History Museum to restore the tapes and make the videos available to the public. This involves careful work on refurbished old equipment and careful editing remembering the events themselves to get the best possible video and sound. It will also include transcripts and other related museum-type treatments.

We have raised money to pay for this (there are over 20 meetings to process) and have started digitizing and editing the tapes. The Mac Introduction will be the first, but there are others of great interest with the leaders of many leading personal computing companies, from Microsoft to Radio Shack to Digital Research to Lotus and IBM.

A thank you to Brad Feld, who remembers the impact the BCS had on his interest in both technology and entrepreneurship from his days at MIT, and all of the others who came through with the money we needed!

The Mac video will be released soon (I'll post here when it's available) and others will follow over time.

[Photo of Steve Jobs about to insert disk into Mac in January 1984, from my VHS copy appears here in the original blog post on Dan Bricklin's Log]

For those of you who have only seen the young Steve Jobs portrayed by actors, seeing him and his team as they actually were should be a real treat. I get chills down my spine watching it.

It is such a joy to realize that a decision we made over 30 years ago at my old company, when the personal computing industry was a young oddity, will bring those days to life for a new generation and for generations to come and that they will care and appreciate it.

(This isn't the first time I've felt that way. Another recording we did, an internal one of a staff meeting as the IBM PC was being announced, ended up a key scene in the PBS documentary "Triumph of the Nerds" -- see "IBM PC Announcement" on my web site's Writings section. I've also posted a few other old videos I have: See "Video of Fall Comdex 1983" and "Video of Bob Frankston's tour of the WWW in 1994".)

I recorded a 20-minute podcast interview with Jonathan yesterday to get the back story on how he, a 20-year-old at the time, got Steve Jobs to debut in Boston. You can listen to the MP3 recording of our Skype conversation, "Jonathan Rotenberg about the 1984 BCS Mac event 2014-01-22" on my podcast channel.

In those days, the top companies in the industry would come to the BCS and other user groups to demonstrate their new innovations, sometimes as their first public showing. (The BCS was the most influential and probably biggest such group.) Local and national TV didn't show up to document the events (though the Wall Street Journal and other press often did). However, "personal" video taping helped preserve some of it. I know that other user groups did taping (I have some tape of me at a least one of those venues) and I hope that other material has been preserved and will be made available to the public and to historians through the Museum and other means.
Published: Fri, 24 Jan 2014 19:44:48 GMT
MassTLC unConference session on Responsive App Design
Just as it has for the three years before, this fall the Massachusetts Technology Leadership Council ran its "Innovation unConference". They have a web site, www.masstlcuncon.org, that explains it all, and I posted lots of photos to Flickr as I have in the past.

This time, I proposed and moderated a session on Responsive App Design. I started things off by showing my video on the topic to get everybody up to speed with what I meant by the term. (On this blog I had called the topic "Responsive App Layout", but I've since switched to the more common word "Design", use the URL [www.responsiveappdesign.org www.responsiveappdesign.org] for the companion web site, and redid the video to better show the example app.)

In the session, we had a lively, useful discussion, which one of the attendees kindly captured on a flip chart that the conference had provided in the room. There were things worth sharing, so I'm reproducing what was written with a little embellishment:

- Contexts / Break Point (what to take into account for different designs)
-- Width / Columns / Landscape / Portrait
-- Sighted / Blind / Color blind
-- Mouse / Touch
-- User standing / sitting / walking / computer mounted on a wall
-- Language orientation (e.g., left to right vs. right to left)
-- One-handed use vs. two-handed use
-- Google Glass, Voice controls, Wrist devices
-- The user's state of mind: Calm, stressed, etc.
-- Location: Inside, outside, driving, moving

- Examples of apps to learn from
-- Dark design
-- Inpath / Pathapp (for innovative controls)
-- Prezi
-- WGBH
-- Grid on iOS
-- Runkeeper
-- Messaging apps (Apple: context changing UX)
-- Tandem Seven (design firm HQ in Massachusetts)
-- UXArchive.com: Has lots of examples of UX of different apps organized by tasks (screenshots)

- Apps vs. Sites:
-- Sites have a Presentation Layer
-- Apps also have major Control Layers and Input Layers

- Don't forget different expectations in each OS for user interface stye
-- Android vs. iOS vs. ...?

- "Write Once, QA Many"

- UX control techniques
-- Ease of Discoverability vs. Learned / Taught

- Action Items
-- Design Guidelines (we're too soon for standards)
-- Need more good/successful examples of business apps

That's it. One of the attendees told us about how his company had worked quite hard on each variation of their native apps for each platform and the thinking that went into each input control and interaction. They are in an app category (messaging) that is quite competitive and where specifics of the UI is one of the distinguishing features of the product and what makes it worthwhile for users to choose their product instead of just using the built-in app. I hope I can get a podcast with him at some point to hear what they went through.
Published: Fri, 08 Nov 2013 20:04:01 GMT
Responsive App Layout
I've been writing a lot here about using HTML5 for business web apps, especially mobile apps. A benefit of HTML5 is that apps that run on multiple platforms are usually easier and less expensive to write than writing in native code for each platform. A challenge is having that one codebase adjust to the screen size and orientation differences of the different devices it runs on. This is more extensive than that usually needed by informational web sites traditionally targeted for Responsive Web Design. Developers need to take into account not just screen width but also screen height, as well as on- and off-screen controls.

I've produced a video, "Responsively Laying Out Web Apps", that explores this issue, embedded below. I've also written an essay about it, "Responsive Web App Design".

[Video on YouTube embedded on original blog post on danbricklin.com/log.]

Feedback that I've gotten is that this is an important issue that developers need to deal with. The video also shows how we have started to address it on the tools side by adding new capabilities to Alpha Anywhere.
Published: Thu, 17 Oct 2013 16:13:18 GMT
What Jeff Bezos and John Henry should read to prepare for their new ownership
In the last month, two major metropolitan newspapers were purchased by new owners: The Boston Globe by John Henry and the Washington Post by Jeff Bezos. Both new owners are individuals, not some investment entity looking for a purely financial return. You have to assume that they both view this as more than just a financial investment and that they realize that they are now in a different part of the news business than they were when they were just the subject of reporting.

There has been a lot of speculation about what each of them intends to do. What direction will they take the "papers"? How will they react when confronted with situations like those that have involved their predecessors? (For example, the Post had to decide what to do during the Watergate investigation and the Globe had to decide how much to invest in the early Boston.com web site.) How will they guide their acquisitions as technology evolves? (Jeff brought us Amazon.com and John put Moneyball into practice.)

They are both new to the news business.

I have a suggestion for them both: As part of your "homework" as you enter this field, please read Christopher Daly's history of journalism in the USA, "Covering America" (Here are Amazon links to the Kindle version and the Hardcover version).

I'm sure the $21.99 price of the Kindle version won't be a problem (Jeff probably gets a discount). The hardcover version is a little heavy to carry around (I just weighed my copy: a little over 2 1/2 pounds), but if either of them wants a physical copy signed by the author, let me know and I'll buy them one and get Chris to inscribe it for them.

Why this book? It's not just because Chris is my next door neighbor, or that he's a professor of journalism at Boston University, or that he used to be the New England correspondent for the Washington Post, or that the book is being used as a textbook by journalism students around the country. It's because the book covers the constant evolution of the world they are now joining and shows them what they, personally, are now a part.

"Covering America" is a book about the people that developed the many business models we now take for granted (or think of as quaint now that their time has come and gone). It is a book about the practitioners of the craft as it evolved, from Benjamin Franklin and Thomas Paine to Joseph Pulitzer, Nellie Bly, and William Randolph Hearst to Bill Paley and Ed Murrow to Ted Turner and Josh Marshall. The book brings dozens and dozens of people to life -- lives that will help Jeff and John chart their place in this ongoing sequence of very special individuals. It will give them background to inspire them to use their own special gifts (not just financial, but industry-changing) to help evolve a calling that is important enough to be in the Bill of Rights.

"Covering America" shows how journalism evolved, both in its practice and as a business. The changes we are seeing now are no more drastic than those brought about by the telegraph, the powered rotary press, or radio.

The book is not a boring recitation of facts. Chris spent time as a feature writer, and this book is written as an interesting narrative, weaving lively biographies with the historical context.

You can see Chris interviewed by the dean at the Columbia School of Journalism the spring of last year on CSPAN: "Book Discussion on Covering America: A Narrative History of a Nation's Journalism" (about an hour long -- note that the book is a lot more fun to read than watching an interview like this on stage at a university). Starting at about 28:00 there is discussion about who will be owning newspapers in today's world. (The hardcover came out in early 2012, but the Kindle version didn't come out until this year.)

Chris blogs at www.journalismprofessor.com and tweets as @ProfDaly.
Published: Tue, 20 Aug 2013 01:56:47 GMT
More about web app speed
It seems that there was a lot of discussion about the already hot topic of HTML5 vs. native that was sparked by Drew Crawford's article "Why mobile apps are slow." It's amazing how one good blog post can have a big effect, bringing the author into a worldwide conversation with authority that stems from their careful writing.

As a result of my comments, I've had some interesting emails back and forth with Drew which has helped me understand some of the feelings people have with respect to this issue. There is a desire that many developers have to craft something new and make it as close to their vision as possible. The goal is the instantiation of the vision, crafted as best as possible. In this case, it is not uncommon that you would need to drop into lower-level tools to implement something that had not been envisioned when the higher-level tools were built. For example, in the old Visual Basic days, it was not uncommon for someone to need to handcraft a control in C or C++ code to implement a behavior that was not already built-in. (Since most VB developers were probably not up to doing this, or didn't have the time, a nice market for those new controls emerged.) The same is still true. For example, in the iOS world, many of us "roll our own" custom controls to get exactly the user experience and functionality that a product needs. (My Note Taker HD app is filled with such controls. I often fall into this "craft the new vision" camp.)

However, for a wide range of applications, especially those "bread and butter" ones that every business needs, with customizations tuned to the particular needs of the business, but generally of the same genre, the times when you need to create new controls are few and far between. The innovation that comes with creating those apps is in the data design, the flow of control, the organization of displays, the integration with (and choice of) external data and services, and the close fit with the needs of the user. In those cases, development systems that anticipate the appropriate generic set and variations of controls and optimize for their assembly into a working app are often "the right tools for the job". A good choice of the controls in the set and the built-in variations can give the developer a comfortable space in which to concentrate on the other aspects of the app that may be requirements for success. Getting the extra polish of some new UI tweak available only to native code, in these cases, often doesn't outweigh productivity benefits of systems that may be built on HTML5 and other technologies. (This also relates to my discussion about "How HTML wins" and "Why Alpha Anywhere matters" -- Alpha Anywhere is a development system that targets HTML5 with a set of controls and variations tuned to business applications. It also relates to the value of the JavaScript language in a programming sense, as I discussed in my previous post.)

In business, there is often another factor. As I pointed out in the podcast interview I did with Scott Hanselman a few weeks ago, sometimes it's more important to just get an application out the door so it can be used before the short-term reason for its existence has passed. (I talk about that at 18:14, but the whole podcast has been getting good reviews.)

I also realized that there's another reason for web apps vs. native: Browsers have always had to deal with content (e.g., web pages) authored in the past and not updated for the latest release of the browser. Backwards compatibility has been a major design requirement for the people who create the browsers. This is why you can still read this web site which is authored using a tool (Trellix Web) last modified in the year 2000 and which creates HTML targeted for the browsers popular at the time (that is, even older). You can even read it on devices running the most recent version of iOS and Android.

The ability in the HTML/CSS/JavaScript world to have old "code" that runs correctly each time you use it for many years, and to choose the time to upgrade which browser features you take advantage of, is a real help to the developer. Any developer who has been forced to revisit old code just to continue running on the latest version of an operating system knows how helpful this ability can be. In the business world, stung by the costs of Y2K and other "flag day" upgrades, this is an important consideration. Also, the open nature of web technologies means that different parties can keep backward compatibility working, lessening the dependence on a single provider.
Published: Fri, 26 Jul 2013 21:59:41 GMT
Are mobile web apps really slow?
My co-worker Bob Moore (@remoorejr) pointed out an essay written by iOS developer Drew Crawford titled "Why mobile apps are slow". Drew goes to great lengths to give us lots of data about speed differences between various "native" code execution and JavaScript. This data, together with some architectural discussions about the overhead of garbage collection in a memory-constrained environment, helps show why for all sorts of computing and/or memory intensive tasks JavaScript executes much slower than native, let's say at least five times slower. On ARM CPU-powered mobile devices, which are much slower than desktop x86 devices, where you need every bit of speed possible in many cases, this can be a deal breaker he feels.

But is that really the whole story? I don't believe that this presents the whole story. While it is true that for doing general computation of mathematical operations native code should be able to run circles around JavaScript (and compute those circles while doing it) that ignores what type of operations are performed in many apps and where JavaScript-based apps often equal or beat native code.

First, a bit about my background: I've been coding for well over 45 years. I've written in FORTRAN, assembler for numerous computers, C, C++, Objective-C, JavaScript, Perl, Visual Basic, and many more languages, shipping products on all of them to real users. I have built an entire, feature-full spreadsheet in JavaScript that runs even on IE 6 and the One Laptop Per Child's XO (two very challenging environments for JavaScript). I have successful, complex native-code apps in the Apple App Store. This means I at least have some perspective from the real world.

For most of what we are talking about, JavaScript does not execute in a vacuum. It runs in a browser. That browser environment brings a lot to the table. The applications you are coding are often ones that lend themselves to what a browser is good for: Presenting information.

The browser development community has been laser-focused on speed of many common operations. Those browser developers have also been pushed by web developers to expand the visual flexibility of what a browser can render directly. So, from the first, browsers did simple rich text rending, with simple but useful dynamic layout capabilities. Even the really early browsers had basic text editing built-in. (See "Video of Bob Frankston's tour of the WWW in 1994".) Today's browsers, with CSS3, have amazing capabilities, including animation and transforms accelerated by GPU hardware, and flexible font control. These are things that are really hard to program yourself, especially if you want them to render quickly. Really hard. (I helped lead a company in the 1990's where we had to implement our own complete text layout engine in C++. That is not something to do lightly or in "just a few months".) For many applications, advanced text layout is a requirement, so using a browser component to do that part speeds development and, because development time is a real factor in almost all projects, can result in a better product. How many iOS apps don't use rich text or complex dynamic layouts because it has been so hard to do those things in native code?

So, one argument in favor of web apps is that many of the common, tough-to-program operations are carefully coded by top programmers who are devoting their careers to fine-tuning that operation. Browsers are constantly being upgraded more and more of this important functionality built-in, including rich-text editing and 3D graphics rendering. If your application's performance is gated by those operations, a web app you could figure out how to write yourself may outperform what you could write yourself in native code.

Another benefit of JavaScript is that many of the common operations needed for many types of applications, such as text processing, are built into the language with a natural syntax. Slowly but surely common operations like lookups and string handling have been added natively to traditional languages. Only slowly has Objective-C been seeing strings and hash-tables becoming more than libraries accessed like other objects. This means that handling of modern cases (e.g., characters taking up more than one byte) happens naturally, efficiently, and hopefully more bug-free. Easy to write string handling is why languages like Perl became so popular when string handling became more important than number handling.

It has been a long-known lesson in programming that different languages for the same algorithm give you factors of a few in improvement (let's say 5-10x here), but that improved algorithms give you orders of magnitude improvement (10-100x). That is, if you can approach a problem in a different way, or rethink it after you've coded it and have seen what's really needed, you can often get enormous performance gains vs. just running the same operations somewhat faster. Using JavaScript, in a browser with CSS3, can often make it easier to get those types of improvements. Of course, if the things that a browser and JavaScript provide are not appropriate for your task, then they may push you the other way, so developers can't just blindly say JavaScript is always best.

There is the question of whether adding special subsets of JavaScript (e.g., asm.js) for speed is just showing that JavaScript isn't fast enough. I've used the "lower level" C-style coding in my Objective-C apps when performance dictated it, and assembly code in my C programs for the time-critical inner loops. I see no problem, and only advantages, with the ability to take the most time-critical sections of computation and "hand coding" them in a language or style more appropriate for that particular task. I don't see that as mandating writing the whole app that way or tainting the main language that is best suited to the rest of the application.

There are many situations where the benefits of an HTML/JavaScript/CSS implementation outweigh the performance hits in other areas. As with all development, it is the job of a good developer to use the right tool for the job when possible. There is no one "best" tool that works for everything. Any programmer ignoring JavaScript is doing themselves a disservice.
Published: Thu, 11 Jul 2013 16:35:20 GMT
Updated: Tue, 15 Jul 2014 19:23:07 GMT
The URL to provide to an RSS aggregator when subscribing to this feed: http://danbricklin.com/log_rss.xml
(For more information about RSS see: What is RSS?.)