Category Archives: javascript

javascript, tech

StackOverflow still delivers, fixes my Rollup.js problem

I hear plenty of complaints about StackOverflow, the developer Q&A site. Top of the list is unfriendliness and/or arguing about whether a question is well put rather than, well, answering the question.

For example, this Reddit post yesterday:

“It’s been three years since a question I posted to SO wasn’t closed within the first ten minutes of posting it and downvoted for good measure (that’ll teach me to use the site like it’s intended!).”

No doubt the complaints have some validity. StackOverflow is a kind of social media as well as a technology site and all social media sites have their problems.

Nevertheless, it remains a wonderful resource.

I am using the AWS Chime SDK for JavaScript in a project. I am using ASP.NET, it is not an SPA (Single Page Application), and it is not using React. The SDK though is primarily designed to be used with Node.js and a bundler like Webpack, fitting I guess with the majority of web applications being built today. The solution AWS provides for developers like myself is presented as a demo called singlejs.  This uses rollup.js to bundle the Chime SDK for JavaScript into a single file that can be used in any plain ordinary web page. A couple of weeks ago, someone got around to updating the demo to use version 3.x of the SDK.

I guess the committer checked that the demo worked and generated a JavaScript file, but did not actually check that it was usable. The way it is meant to work:

In a browser environment, window.ChimeSDK will be available. You can access Chime SDK components by component name. For example, you can create a meeting session and configure the meeting session using window.ChimeSDK.

Unfortunately the newly generated amazon-chime-sdk.min.js did not create this global variable, even though it is specified at the name property in rollup.config.js. I puzzled over this problem and tried to fix it in various ways, using different versions of rollup and the plugins it uses. I noted the problem in a GitHub issue on the relevant AWS repository but no response yet. Since it made it impossible for me to upgrade my project to the version 3.x of the SDK it was a significant problem.

I posted a question on StackOverflow. It did not attract many views, and at the time of writing it has only been viewed 31 times. I was not optimistic.

As so often with these kinds of problems, the fix is super simple. The source file in the singlejs demo, the one which Rollup bundles, has just one line of JavaScript:

export * from ‘amazon-chime-sdk-js’;

Someone popped up, 2 days after my post, and commented:

Update the src/index.js file with the following code and then rebuild the code with npm run bundle. Rollup recommends a default export if we have only single export.

export * as default from ‘amazon-chime-sdk-js’;

Indeed, that fixes it. So thank you to Vishnu S Krish, who for no reward has posted a solution that works, ahead of those busy AWS developers working on the project who have so far ignored it.

Thank you too to StackOverflow. It is imperfect; but it is not full of spam, it is a pleasant site to use and not afflicted by intrusive ads and popups, and it has a ton of good solutions.

development, javascript, mobile, software development, Web

Appcelerator plans to rethink Titanium architecture, standardise on WebKit JavaScript engine

3 Comments

Appcelerator CEO Jeff Haynie has posted about his plans for Titanium, the company’s cross-platform mobile development toolkit.

The plan is to completely rewrite the core engine, while maintaining a mostly-compatible API. Central to the plans is the idea of using one JavaScript engine on all platforms:

With Ti.Next, we’ve created a small microkernel design that will allow us to have minimal bootstrap code in the native language (C, Java, C#, etc) that talks to a common set of compilers, tools and a single JavaScript Virtual Machine. We have found a way to make the WebKit KJS VM work on multiple platforms instead of using different VMs per platform. This means we can heavily optimize the microkernel (herein after called the “TiRuntime”) and maintenance, optimizations and profiling can be greatly simplified. We’re talking about ~5K LOC vs. 100K LOC per platform.

This will make it possible to share almost all the Titanium code itself across all platforms. The Titanium runtime itself will be shared code written in JavaScript.

Appcelerator says that Titanium code will be “faster than native code in most situations.”

No date for Ti.Next is given though according to this slidedeck the plan is to have the “first set of developer builds available soon to GitHub repo – possibly in the next 45-60 days”. It adds, “production builds are a ways away.”

Using a WebKit JavaScript engine on Windows Phone, for example, sounds interesting.

javascript, software development, web authoring

Twilio adds support for WebRTC: real time communications in JavaScript

Cloud telephony company Twilio has announced beta support for WebRTC at its conference in San Francisco.

WebRTC is a project supported by Google, Mozilla and Opera and lets you do real time communications, including access to camera and microphone, using a JavaScript API without a plug-in. There is also a W3C Working Group.

WebRTC support will be a feature of the Twilio client:

When Twilio Client apps are used with a WebRTC compatible browser, such as future versions of Google Chrome and Mozilla Firefox, Twilio Client will automatically take advantage of the improved audio performance of the WebRTC technology. If the browser doesn’t support it, Twilio Client will still work and fall back to existing browser technologies.

says Twilio.

Other new APIs announced at the conference include Test Credentials, which lets developers test code against the Twilio API without actually placing calls; Usage for retrieving Twilio usage logs and Usage Triggers which you can use to implement usage caps in order to limit cost.

.net, javascript, microsoft, professional

Here comes TypeScript: Microsoft’s superset of JavaScript

Microsoft’s Anders Hejlsberg has introduced TypeScript, a programming language which is a superset of JavaScript and which compiles to JavaScript code.

The thinking behind TypeScript is that JavaScript is unsuitable for large projects.

“JavaScript was never designed to be a programming language for big applications,” says Microsoft’s Anders Hejlsberg, inventor of C#. “It’s a scripting language.”

The ubiquity of JavaScript makes it remarkably useful though, with that now extending to the server thanks to projects like node.js. Microsoft is using node.js for its Azure Mobile Services.

TypeScript therefore lets you use features including type annotations, classes, modules and interfaces to make large projects more robust and maintainable.

Variable names are preserved when TypeScript is compiled. Further, since TypeScript is a superset, any JavaScript code can be pasted into a TypeScript project. The compiler is open source and you can download an early version here.

Microsoft is also trying to stay close to the specification for Ecmascript 6, the proposed next iteration of the official JavaScript standard, where relevant.

There is tooling for Visual Studio including a language service to provide code hinting, syntax highlighting and the like.

TypeScript differs from projects like Google Web Toolkit or Script#, both of which also emit JavaScript, in that it does not compile from one language into another; rather, it compiles into a reduced version of itself.

Why is Microsoft doing this? That is the interesting question. I would conjecture that it is partly self-interest. Microsoft itself has to write increasing amounts of JavaScript, for things like Office Web Apps (apparently written in Script#) and the new Azure portals. Azure Mobile Services uses JavaScript as mentioned above. JavaScript is also one of the options for coding apps for Windows 8. Better tools will help Microsoft itself to be more productive.

That said, the arrival of TypeScript will re-ignite the debate about whether Microsoft, while not anywhere close to abandoning .NET, is nevertheless drifting away from it, towards both native code in Windows and now JavaScript in the managed code space.

More information from Microsoft’s S Somasegar here.

javascript, software development, web authoring

Dropbox turns to CoffeeScript to beat JavaScript syntactic noise

2 Comments

Dropbox is a high-profile convert to CoffeeScript, a language that has the elegance of Ruby or Python but compiles into clean JavaScript in order to run in the browser. The Dropbox team says that CoffeeScript fixes many of JavaScript’s “syntactic problems.” In addition, a porting exercise reduced 23,437 lines of JavaScript to 18,417 lines of CoffeeScript, code, and this brevity was considered the “strongest argument” in favour – even though many of those eliminated lines were just curly braces and parentheses.

In order to port the code, the team used the Js2coffee tool; a bit of a brain-twist, a tool to convert JavaScript to a language that later compiles back to JavaScript.

The whole post is worth a read, and gives before and after examples.

Consider also the following:

Google’s Dart is an alternative web language that compiles to JavaScript, as is Google Web Toolkit

Microsoft’s Office Web Apps are written in C# compiled to JavaScript with a version of Script#. Microsoft’s Roslyn compiler as a service project lets you copy and paste VB code as C# and vice versa, and is already also being used to compile C# as JavaScript. Microsoft’s Anders Hejlsberg is rumoured to be working on a JavaScript project.

JavaScript seems to be becoming the new Common Language Runtime, not that Microsoft’s .NET CLR is going away, but rather that JavaScript now better fulfils the goal: pick whatever language you like and run it in the browser. 

PostScript:

I was intrigued to note that the Dropbox post does not render properly in Internet Explorer 10. For some reason that must appeal to geeky humour, it includes code spoken as audio, but the audio tags fail:

image

instead of

image

Possible reasons: the Dropbox page has a DOCTYPE of XHTML 1.0, and the files are in .wav format where IE is documented only to support MP3 or MP4. IE10 therefore refuses to play the audio, which works fine in Google Chrome and Mozilla Firefox.

The significance of this is not so much the technicalities, but rather what it implies about how many people now use IE in the community most likely to read this post.

.net, javascript, professional

Convert .NET Intermediate Language to JavaScript

3 Comments

Whomever called JavaScript the assembly language of the web was a true prophet.

Compiling .Net code to JavaScript is not new. I have heard that Microsoft’s Office Web Apps, browser-hosted editing of Office documents, are built with Script#.

The difference with JSIL is that it compiles .NET Intermediate Language (IL), and therefore works with any .NET language – though note that:

JSIL is still in development. You will hit bugs

The screenshot says it all

image

apple, development, facebook, google, internet, itunes, javascript, mobile, Web, web authoring

Financial Times thrives on HTML 5, paywall, and snubbing Apple iTunes

6 Comments

I spoke to Rob Grimshaw, Managing Director of FT.Com, shortly after Mobile World Congress in Barcelona, where the FT web app won an award for “Best Mobile Innovation for Publishing”.

image

I was interested in speaking to Grimshaw for two reasons.

First, the FT is a publication which has successfully managed the transition from print to online. The latest published results , for the first half of 2011, report that FT Group sales were up 7% and profits up 10%, “enhanced by digital subscriptions.”

Second, the FT took the initiative to bypass Apple’s app store with its onerous subscription terms by remaking its app as HTML5, as reported here .
The award “was the icing on the cake for the whole process,” Grimshaw told me. “When we abandoned the native app and stepped out of iTunes, it was a big commercial gamble, and it was a rueful moment as well because we’d created a beautiful native app and won an Apple design award.”

Was the FT move all about subscription fees, or were there other factors? “It was not all about Apple,” said Grimshaw. “Certainly their 30% tax on subscriptions didn’t make sense to us, because we already have our own platform so why pay somebody else to use their platform? Second, they would have owned the relationship with the customer. That’s important for various reasons, but for example it makes it difficult to manage churn, which is a crucial aspect of a subscription business.

“There were some other reasons. The mobile market would have been problematic if we had to keep developing all our applications for many different  operating systems. The overhead is enormous. It doesn’t stop once you’ve launched the app, you have to keep ugrading and changing.

“HTML 5 offers a way out of that headache by producing code that runs across multiple platforms.

“When you add all of that together, it seems to be smart to go the HTML 5 route even though it was technologically risky because at the time nobody else had done it.”

So what has been the impact of the web app versus the native app?

“A lot of people said, if we leave iTunes we’ll disappear from the world. We haven’t found that to be the case. In the four month period after we launched the web app, from June through to October 2011, our traffic on the iPad and the iPhone increased by over 50%. 1.7 million people have now visited the web application, more than ever downloaded our old iPhone and iPad app combined.

“We have many tools and techniques which help us to promote and build audience in the browser, and they work just as effectively for the web app as they do for our normal web sites.”

Is the success of the web app a reflection of the type of app, which is content-dominated, or will web apps dominate more generally in the mobile space?

“I think that HTML 5 will dominate. The buzz around HTML 5 at Mobile World Congress reinforced that view. It feels to me that there is an unstoppable momentum behind it,” said Grimshaw, mentioning PhoneGap-style native wrappers as well as pure web apps. “The counter argument is that for some of the new features of phones and tablets you have to use native code. However, I think 90% of applications don’t need that kind of support. We produce a very sophisticated app, and HTML 5 covers all the functions that we would ever need to use.”

“Once people discover what they can do within the browser they will start thinking why would you develop in native when it creates all of these headaches.”

As form factors become more varied, do you see a convergence between what you do for mobile and what you do for the wider internet?

“I can see them coming together. I can imagine a day where a single set of HTML 5 code can power our site across the full range of smartphones, tablets and desktop. The only obstacle is that so many browsers on the desktop don’t support HTML 5 fully.

“That doesn’t make all the contexting go away. Now with our mobile development we are dividing screen sizes into four buckets, and the thinking is that we will have to design for those four screen sizes. Device manufacturers are going to carry on producing a device to occupy every possible niche, and as publishers we have to cope with that.”

How important is cloud and mobile to your business, what new opportunities does it offer?

“Mobile is incredibly strategically important. I’m personally convinced that mobile will be the main distribution channel for news in the future. People’s lives don’t stop when they leave their desks or exit their houses. They want to carry on their friendships, their business, their reading. If you have a powerful mobile device that can deliver that, you’re going to gravitate to that device, and pretty soon it does become the main channel.

“We already see the audience migrating onto mobile. About 20% of our page views now come from mobile devices. That could be over half within three years. Figuring out how to present our content, sell our subscriptions, deliver our advertising on mobile devices is hugely important.

“It’s a shift on a tectonic scale. For publishers this is a bigger shift than the shift from print to desktop, and it’s happening faster.

“It does create new opportunities as well. We have a new sales channel, we’re now selling our subscriptions through mobile devices. 15 to 20% of our new digital subscriptions every week are sold directly through mobile devices.

“It gives us the potential to reach new audiences. We’ve seen some good evidence from the mobile operators to show that our audience from mobile is much younger that our audience on desktop or on print. Devices are helping us to reach younger audiences and recruit readers who might be with us for the rest of their lives.”

What about social media and the relationship with the big web portals, Google, Facebook, Twitter?

“I see social media as a parallel trend to mobile. Mobile is the desire of people to take content with them physically. Social media is about the desire of people to take content with them virtually, and equally powerful.

“On the advertising side I find social media a little alarming because of scale. Facebook has a trillion page views a month, which makes them 400 times bigger than the BBC and 1500 times bigger than the New York Times. It’s scale which is unimaginable for most publishers, and they have tremendous insight into their audience. That’s a potent cocktail. And every time someone shares an FT article on Facebook, an extra bit of data builds up on their side that tells them about our readers.

“On the subscription side though it is all positive and they can be powerful sales channels for us. We have big communities in social media, 300,000 odd on Facebook, 1.2 million Twitter followers, and these are to some extend self-selecting marketing audiences, people who stuck up their hand and said we’re interested in the FT.

“We also believe we can find ways to allow people to consume content in the social media environment if they are subscribers. We’re working on finding ways to do that.”

What do you think of paywalls versus free content for newspapers on the web? Does the paywall only work because the FT is a niche publication, albeit a large niche?

“We are very much on the paywall side and unashamedly so, we think our content has tremendous value and people do not object to paying for it. We now have 270,000 digital subscribers and that compares to our newspaper circulation which is around 330,000, so we’ve been successful in building up a paying audience in digital which is now pretty close in scale to our paying audience. It’s been an enormously success business venture for us.

“When you look at the publishers that are giving all their content away, the reason they are giving it all away is in order to build up a bigger audience for advertising. But the scale of the competition in the advertising market is so huge that actually it is a fruitless exercise, unless you can acquire a scale which will give you billions of page views a month. It’s very hard to see how you can build a decent business just from online advertising. The numbers don’t stack up.

“My message to other publishers is not necessarily that you have got to have a paywall, but is that you probably need other ways to make money, other than online advertising.”

internet, javascript, microsoft, professional, software development, Web, web authoring

Microsoft backs ECMAScript, dismisses Google Dart

2 Comments

Microsoft has posted an article on Evolving ECMAScript on its IE Blog. ECMAScript is the official standard for what we call JavaScript. The company is proposing some minor additions “to address gaps in Math, String and Number functionality as well as Globalization.” It has also taken the opportunity to take a shot at Google, which is proposing a new web language called Dart:

Some examples, like Dart, portend that JavaScript has fundamental flaws and to support these scenarios requires a “clean break” from JavaScript in both syntax and runtime. We disagree with this point of view. We believe that with committee participant focus, the standards runtime can be expanded and the syntactic features necessary to support JavaScript at scale can be built upon the existing JavaScript standard.

Dart will compile to JavaScript so there is a measure of compatibility, but if the language catches on then browsers without a native implementation will be disadvantaged.

development, internet, java, javascript, microsoft, open source, professional

Google offers the web a new language called Dart – but why?

4 Comments

Google has announced an early preview of Dart, a new language for web applications. The news is not a surprise, especially if you have been keeping track of the developer conference GOTO Aarhus, whose organisers had pre-announced that Google would be announcing its new language there, as indeed it did.

image

Dart is a curly-brace language like JavaScript, Java, C, C++ and C#. In Dart, as in C# and Java, a class can implement multiple interfaces, but only inherit from a single class. Dart supports both static and dynamic typing. Google says it can be executed by a Dart VM, or converted to JavaScript:

Dart code can be executed in two different ways: either on a native virtual machine or on top of a JavaScript engine by using a compiler that translates Dart code to JavaScript. This means you can write a web application in Dart and have it compiled and run on any modern browser. The Dart VM is not currently integrated in Chrome but we plan to explore this option.

Google also says that you will be able to “execute Dart code directly in a VM on the server side”, so you can infer that Google has Dart in mind as an alternative PHP as well as to JavaScript. The company is using the phrase “structured web programming” to describe Dart, and this phrase appears in the announcement and as the subtitle on the Dart site. The implication is that JavaScript code tends to be poorly structured and that Dart will promote more maintainable code.

In the preview Dart only runs in Chrome, Safari 5 and Firefox 4+ – spot the missing browser vendors.

At first glance, Dart looks like a promising language, though I find myself asking what it is really for, when it bears a strong family resemblance to existing languages, and bearing in mind that the Google Web Toolkit, which compiles Java to JavaScript, already enables structured programming for web applications. The list of problems which Dart solves in the technical overview is not all that compelling.

Google states that:

Developers have not been able to create homogeneous systems that encompass both client and server, except for a few cases such as Node.js and Google Web Toolkit (GWT).

This is or was one of the attractions of Microsoft Silverlight, presuming you use C# on both server and client, but Silverlight is a plug-in that was never going to run on an iPad and from which Microsoft itself is now retreating; though it is worth noting that Dart is not unlike C#, especially the latest version of C# with dynamic features.

I guess that Dart is a consequence of the failure of ECMAScript 4.0, which was a cooperative effort to create a more modern and advanced JavaScript. Google is now going it alone; the key question is whether it can win support from others such as Apple and Microsoft, or whether this will be a Google language for Google on the server and Chrome on the client, or an interesting experiment that never really catches on.

Do we need Dart? I would value hearing from others what you think of Google’s proposal.

adobe, internet, javascript, mobile, software development, web authoring

Adobe Flash Professional to get HTML authoring features

I have just attended a session on the future of Flash Professional, the designer-oriented authoring tool for Flash, here at Adobe MAX in Los Angeles.

One feature that caught my attention is that export to HTML is coming to Flash Professional. Adobe already has a research project called Project Wallaby which converts .fla files to HTML 5, though I have heard that it is not very good. This one looks more promising, and we saw how a simple animation can be published to HTML and JavaScript and look exactly the same. Some of the key features:

  • There will be a limited ActionScript 3 to JavaScript conversion included.
  • There will be “guardrails” in Flash Professional, so that if you choose to work for HTML then incompatible options will be greyed out.
  • The exported code will use the same libraries as Adobe Edge, a new animation tool for HTML, and you will be able to open it in Edge and do further work on it there. The Edge approach uses jQuery as well as its own format for storing animations.
  • I got the impression that this feature will be in the next version of Flash Professional, which we can call for the sake of argument Creative Suite 6

We also got a glimpse of a future version of Flash Professional which will be 64-bit and use the native Cocoa framework on the Mac – but this will NOT be in the next version.

This move strikes me as significant, in that it shows Adobe’s ability to repurpose its tools for HTML 5 alongside Flash.

Does it mean that Flash is dead? That makes a good headline, but it is not the case. In fact, I have picked up some anxiety here among developers and designers concerning the future of Flash. They like targeting Flash and do not want to return to puzzling out endless browser compatibility issues, and having to limit their designs to what will work in the lowest supported version. They will have been reassured to hear about energy going into Flash development; the session I attended on concurrency in the Flash runtime was packed.

Stage 3D, the new GPU-accelerated 3D API in Flash, enables fast graphics that bring console-quality games to the browser. It will be a while before this is achievable in HTML that works across all popular browsers.

Flash is not going away, but nevertheless Adobe is in transition, and I am hearing more about HTML 5 at MAX this year than has previously been the case.

I am also seeing more focus on Flash as a cross-platform runtime that you bundle into your mobile or desktop application, using either the iOS packager or the Captive Runtime, so users will not even know that they are running Flash and will not need to download it separately.