ENTRIES TAGGED "javascript"
From BASIC to HyperTalk to JavaScript to Rails to Erlang
Every programming experience teaches
I’ve never formally trained to be a programmer, outside of occasional conference workshops and a week of XSL tutorials. In some ways, that’s terrible, because it’s taken me about thirty years to learn what some friends of mine appear to have learned in four. I’ve written some code that goes way beyond spaghetti, though on the bright side the worst of it was probably when I was 15.
On the bright side, when I look past my many mistakes, I can see what I learned from a large number of various different experiences, and the pieces they helped me see. It’s a little easier to tell this story through the parts than it might be through a formal curriculum.
- My parents’ FORTRAN books
- I was reading computer books—dry ones—before I even got to play. I have vague memories about program structure, but mostly I learned that knowledge sticks better if it includes hands-on work, and not just a book.
- Sinclair ZX81
- 1K of memory! The sheer thrill of seeing my creations on screen was amazing. I had just enough logic to get things done, and leave myself puzzled. The Sinclair community seemed focused on making great small things. I learned simple logic in BASIC and that sometimes it takes a hack to get things done.
- Applesoft BASIC
- After Sinclair BASIC, Applesoft seemed vast. Much of what I did was transfer what I’d done on the Sinclair (itself a lesson in platform-shifting). As I settled, I started writing larger and larger programs, eventually forcing myself to restructure everything into subroutines…with global variables, of course.
- 6502 Assembler
- I knew there was more than BASIC. My early adventures with assembler were mostly about graphics, and didn’t work all that well, but I picked up two key things: recursion and the importance of registers.
- Logo
- I’m not sure which Logo it was, but it was a tiny language and still capable of doing fun things. That in itself was enough of a lesson.
- Typewriter
- My spaghetti code frustrated me with endless debugging. I put the computer away for a couple of years and bought a typewriter. Apart from patience, I learned that my brain felt different when I stopped programming. The “Return” key at the end of every thought disappeared, and I was able to step back a little from formal logic. Knowing that my brain felt different ‘on programming’ has helped me deal better with programmers and non-programmers ever since.
- HyperTalk
- I returned to programming with HyperTalk: an object of derision or worship, depending on who you talk with. For me, it was proof that a friendly object manipulation language can do great things, until you hit the wall where your logic is more important than the provided objects.
- Pascal
- This was a brief excursion, but gave me a path into the inside of the Mac, a view of how these crazy graphical interfaces fit together, and a chance to shift from GOSUB with global variables to much neater method calls.
- HTML and CSS and XML
- Everything I learned about program structure, even in HyperTalk, went out the door. They aren’t programming languages, but they support a common set of structures I use everywhere. It turned out that decorating trees and handling events would be at the heart of my work for decades…
- Perl
- Perl taught me the power and terror of regular expressions. It definitely reinforced my impatience, laziness, and hubris. CGI had its flaws, but it gave me first contact with building a server system that could interact with clients.
- Java
- Java seemed like the right answer to all my object-oriented dreams, and was also the place many of my fellow XML developers had chosen. Somehow, though, text processing in Java taught me that programming against the grain of a language is difficult, and that it makes sense to choose a language based on the tasks I want to perform.
- JavaScript
- At first I mistook JavaScript for HyperTalk with a heavy C accent: an object manipulation language. Over time, though, I’ve realized that JavaScript takes everything I’ve learned from the other languages (except Erlang’s processes!) and puts it in one place.
- Ruby on Rails
- Ruby offers even more flexibility and style options than JavaScript. (See Understanding Computation if you want a sense of how far you can push it!) It was kind of the opposite of Logo, a chance to try everything. Rails taught me about the magic of metaprogramming, but also that trusting magic can be difficult.
Using XSLT 2.0 as a Web Scripting Language
Stunning JavaScript implementation suggests more is possible
A language built to support event handling, not strictly a functional programming language but fitting that mold. A deep understanding of markup structures. A home in the browser.
That’s JavaScript, all right—but now, thanks to JavaScript, it is also XSLT. After all the discussion I heard about templates and JavaScript at Fluent and OSCON, starting with a language built on templates seems like a better and better option.
Thursday afternoon at Balisage, O’Neil Delpratt and Michael Kay discussed Interactive XSLT [2.0] in the browser, showing not just the usual transformations but a working engine for a graphical interface. Their earlier XML Prague paper also tells the story and shows more code detail, including a chess game.
Read more…
Toward Responsive Web Programming
Creating flexible expectations
“Expect the unexpected” has long been a maxim of web development. New browsers and devices arrive, technologies change, and things break. The lore of web development isn’t just the technology: it addresses the many challenges of dealing with customers who want to lock everything down.
Matt Griffin (and a lot of others) reminded me of these difficulties at Artifact, and his Client Relationships and the Multi-Device Web brings it home for designers.
Is there room for programmers to tell a similar story?
I don’t mean agile. Agile development is difficult enough to explain to clients, but applications that adapt to their circumstances are a separate set of complications. Iterating on adaptable behaviors may be more difficult than iterating on adaptable designs, but it opens new possibilities both for applications and for the evolution of the Web.
Responsive Web Design is (slowly) becoming the new baseline, giving designers a set of tools for building pages that (usually) provide the same functionality while adapting to different circumstances. Programmers sometimes provide different functionality to different users, but it’s more often about cases where users have different privileges than about different devices and contexts.
Adjusting how content displays is complex enough, but modifying application behavior to respond to different circumstances is more unusual. The goal of most web development has been to provide a single experience across a variety of devices, filling in gaps whenever possible to support uniformity. The history of “this page best viewed on my preferred browser” is mostly ugly. Polyfills, which I think have a bright future, emerged to create uniformity where browsers didn’t.
Browsers, though, now provide a huge shared context. Variations exist, of course, and cause headaches, but many HTML5 APIs and CSS3 features can work nicely as supplements to a broader site. Yes, you could build a web app around WebRTC and Media Capture and Streams, and it would only run on Firefox and Chrome right now. But you could also use WebRTC to help users talk about content that’s visible across browsers, and only the users on Firefox and Chrome would have the extra video option. The Web Audio API is also a good candidate for this, as might be some graphics features.
This is harder, of course, with things like WebSockets that provide basic functionality. For those cases, polyfills seem like a better option. Something that seems as complicated and foundational as IndexedDB could be made optional, though, by switching whether data is stored locally or remotely (or both).
HTML5 and CSS3 have re-awakened Web development. I’m hoping that we can develop new practices that let us take advantage of these tools without having to wait for them to work everywhere. In the long run, I hope that will create a more active testing and development process to give browser vendors feedback earlier—but getting there will require changing the expectations of our users and customers as well.
Securing User Content in the JavaScriptable Web
OSCON 2013 Speaker Series
Recent work by a W3 Working Group plans to expose many powerful cryptographic operations for web applications. Although the planned API adds much needed functionality to JavaScript, it doesn’t address the JavaScript runtime’s terrible security properties. For instance, any script running in the web application has the power to hijack the web app’s content and UX. Just last February a mistake in Facebook’s “like” button brought down millions of web sites. Further, if you are an online service provider wanting to support higher privacy use cases like encrypted chat or web-based PGP email, the trust model is fundamentally broken since you can’t serve cryptographic JavaScript code without making the server a potential attack point.
The security challenges faced by JavaScript are mitigated by Privly, also labeled “the Web Privacy Stack,” by addressing two issues: (1) scoping code to the data, and (2) pre-distributing the code to the clients when possible.
Scoping Code to the Data
Every website has its own navigation structure, layout, and audience, but when you strip away these unique attributes of websites, you are left with data– chats, emails, photos– that can be treated uniformly across all websites. Operations on these data like encryption and signing, can be performed with indifference to their context and their contents.
Privly uses data indifference to create the notion of “Injectable Applications,” which are full web applications that are injected into the context of other web application. Since these applications are scoped to data and not layout, their properties are simplified and usable across the web.
Privly works within browser extensions by scanning web pages for specially formatted hyperlinks. When the extension detects the hyperlink, it “injects” the link into an iframe that is served locally from the browser extension.(footnote 1: This is currently how the Chrome extension performs, but different platforms are at different levels of sophistication. This approach can be universally applied to all platforms and does not necessarily require locally-served JavaScript code. However, without serving the JavaScript code locally, the security properties of the system are lost) Since the injected application is a full web application, the app could potentially support any web-implementable feature, including APIs between the host page and the injected application.
In short, if you scope an application to the data, then the cryptography can be viewed in potentially untrusted contexts.
Pre-Distributing Client Code
Privly creates an ecosystem of apps with known properties because it allows us to reason about security uniformly across the web. However, security is only as strong as the weakest attack point, which is why great care must be taken to appropriately distribute these applications. By packaging a set of applications for integration into browser extensions and mobile apps, the code is not re-loaded from a remote source every time the browser loads a new page.
Requiring the pre-distribution of applications is not normally compatible with the free and open internet. However, pains must be taken to realize the differences between the limited use cases of injected applications, and the general cases supported by web applications in general. Distributing every website to the client before visiting a website is impossible, but distributing a set of general injectable applications is lightweight and perhaps the only way to achieve security within the modern JavaScript runtime.
Requiring users to install an extension before they can view content is likely an impediment for any security system looking to gain users. However, since Privly uses hyperlinks to reference the content, it provides opportunity for a hosted fallback application. Depending on the nature of the injectable application, clicking the hyperlink could either present the same application as normally delivered by the extension, or present a prompt to install the appropriate browser extension.
Read more…
JavaScript Is Way Too Slow – for What?
There's more to mobile web apps than JavaScript
I keep finding that programmers—even web programmers—frequently think “web application” means “JavaScript application.” Programmers are, of course, used to working with programming languages, and often see application environments from the perspective of the programming language in use.
These blinders derail Drew Crawford’s detailed rant on Why mobile web apps are slow. It turns out that “slow for what?” is a key part of the question, as Crawford reveals near the very end:
JavaScript is too slow for mobile app use in 2013 (e.g., for photo editing, etc.).
Do we need to run Photoshop on our mobile phones using JavaScript underneath? I agree that cramming everything into an interpreted language on a memory-, processing-, and bandwidth-constrained device is a stupid idea—but “photo editing” is an extreme case, to put it mildly. Perhaps critics will move on to video editing when we eventually get to the next round.
Despite that flaw, if the rant had been titled “Why mobile JavaScript apps are slow,” it would have done better. His lists of benchmarks, discussions of processor challenges, and recognition that the easy work in JavaScript optimization is already done, are all tremendously useful. There is little reason to expect JavaScript performance to improve in the future at the rate is has achieved for the last decade.
It may also be true that the browser vendors have optimized their performance as far as they can, at least in the relatively stable fields of HTML parsing and processing, and CSS selectors and formatting. Adding querySelector to the DOM was a massive one-time speed upgrade, letting JavaScript developers drop most of their tree walking in favor of a more declarative approach relying on native code in which vendors had already invested heavily.
So how can we optimize mobile web development?
The first answer is pretty simple: don’t try to use JavaScript for tasks (like photo or video editing) that push it past its limits. As far as JavaScript has come, it wasn’t built for that. Native apps are indeed good for more than building browsers.
The second answer is trickier: it means recognizing that web applications include much more than JavaScript. JavaScript began as a scripting language for gluing together objects written in other languages, and it still excels at that. Build your application from the HTML—the easiest stuff to process!—up. (If you want graphics, SVG might be a better path.) Then layer CSS on top of that. Rely on APIs built into the browser whenever you can, using JavaScript to connect with their much faster processing. HTML5 keeps making that a better and better option.
When I was programming our HTML 4 & 5: The Complete Reference, I marveled regularly at how tasks that seemed huge, like loading a new CSS stylesheet, moved rapidly compared to implementing smaller changes using JavaScript. More broadly, Estelle Weyl’s JavaScript: You Don’t Need a Framework For That (slides) resonates both because it shows how to use smaller chunks of JavaScript and because it explores how to use CSS creatively to avoid using JavaScript at all.
Building great applications using JavaScript, especially great mobile web applications, often means using JavaScript itself as sparingly as possible. That’s always been a feature of JavaScript, not a bug.
Learning to Wait: Asynchronous Becomes Normal
Software grows patient
The biggest change I’ve seen in the last few years of software development isn’t a new language, a new environment, or magical new algorithms. The biggest change is that programmers in many different arenas, working independently, have come to accept waiting.
Part of the joy of computers, a magic that grew and grew as computers and networks got faster and faster, was the confidence that making a change was immediate. Yes, it took time to get a message over a network or for a CPU to execute calls—but things happened.
The event loop has been around for a long time—computers have always had to wait for us slow humans. Transactions have provided a buffer against the possibility of simultaneous changes to the same data, and certainly slowed things down, but the time that buffering took was generally considered a cost, not a feature. Message queues have existed for a long time, but again, seemed bulletproof but expensive.
Over the last few years, these approaches have become more common and better understood. I suspect that there are two main drivers of this change:
-
As larger scale projects have become more common, the knowledge needed to use these approaches has become more widely available. The average project may be larger scale as well, but these techniques are appearing even in cases where I wouldn’t have thought them necessary. (Of course, I also like playing with Erlang in tiny single-user environments.)
-
The Web always has latency, and JavaScript practice has evolved to support that. Asynchronous JavaScript may not be everyone’s dream work, but the pattern has evolved from UI events to Ajax to promises, deferreds, and much more. Node is built on these foundations. It’s not just JavaScript, though—I just found Asynchronous Processing with PHP on App Engine.
I saw a great talk last week on IndexedDB. It wasn’t the data storage or the asynchronous API that grabbed my attention, but the conversation about promises and ways to make “wait for it” seem like a normal programming idiom. There are a lot of those conversations happening now, about many environments.
Should we make asynchronous seem normal with syntax sugar? Or should we flag it, call attention to it, and make sure programmers remember that their code is waiting?
Safe and Sane Windows 8 Programming Experiences with HTML and JavaScript
Windows 8 is mostly about touch.
There was a time, some fifteen years ago, when the choice of the programming language was a delicate decision. It stopped being a problem when .NET arrived. Because .NET languages compile to the Common Language Runtime, .NET compatible languages became more or less indistinguishable other than syntactically, and developers could happily mix Visual Basic with C# and even JScript.
The JScript language you could use to build plain .NET applications was simply a programming language with syntax close to JavaScript. Choosing JScript didn’t mean you were going to write .NET applications following the web metaphor.
In Windows 8, things are different.
A Windows 8 application runs on top of a new runtime environment—called “Windows Runtime” or WinRT for short. WinRT is a modernized and redesigned version of the .NET Common Language Runtime. You can write a Windows 8 application using C#, Visual Basic, or C++ for the logic and XAML for the layout. In doing so, you can take advantage of patterns that are made-to-measure for XAML, such as the Model-View-View-Model pattern (MVVM). In this regard, developing for Windows 8 is not that much different from developing for Silverlight or Windows Phone.
Read more…
5 Surprises for PHP Developers Coming to JavaScript
Unique features concealed within familiar syntax
PHP programmers often see the familiar C-like syntax of JavaScript and think it’s all flowers and roses. And while trivialities like loops and conditions are pretty much equivalent in both languages, things get very weird very quickly. Let’s take a look at the top 5 marvels JavaScript has to offer to the unsuspecting PHP veteran.
1. Functions are objects
Consider a function:
function sum(a, b) {
return a + b;
}
It looks familiar, the only apparent difference being the missing $ to denote variables. But it turns out there’s more than that. The function sum() is actually an object. That means it can have properties and methods.
Something like:
sum.length; // 2
… may come as a surprise. In this case length property of the sum object gives you the number of arguments this function expects.
And you’re not limited by built-in properties; you can assign any properties you like to the sum object. For example you can have a cache property that stores the results of previous (potentially expensive) calculations.
And since you can refer to functions just as regular variables, that means your function can take other functions as arguments (callbacks) and can also return functions as return values.
Read more…
Smuggling Web Practices into the Enterprise
How fast can the enterprise change?
At last year’s Fluent Conference, I kept having the same conversation with attendees from large companies. They had come to the show with a mandate from their bosses to figure out how to bring that fast-moving web work into their slow-moving enterprise systems.
I enjoyed some of that same conversation this year, but also a different note: even with management support, making that transition was difficult. Some parts meshed, others were difficult: changes in one place could reverberate through many others. The whole concept of “rapid prototyping” fit badly with a variety of technologies and approaches meant to minimize unpleasant surprises. Even eight years after the advent of Ajax, a variety of server-centric techniques limit the flexibility of front-end developers.
Someone at lunch said that “the technology helps, but the culture matters.” A few others talked about how everyone wanted better front-end work, but thought it could be grafted easily on existing back-end practice. The shiny parts are easy to talk about, but the plumbing is harder.
I was happy to see Bill Scott (@billwscott) of PayPal take on these challenges in his keynote. Bill wasn’t smuggling anything—that would be difficult under the title “Clash of the Titans: Releasing the Kraken.” He was brought to PayPal to change the company, to bring the lean “build – measure – learn” approach. In a risk-averse world, with “a 20-day class on how to use their version of Spring,” Scott had to change the “culture of a long shelf life” (something publishing folks are starting to do as well).
It’s a hard-hitting talk, calling for major change, skunkworks projects, and shifts in both company culture and technology.
8 Dart Features Those Fat Cats Don’t Want You to Know
Productive code without ceremony
In this article, I’ll show you eight more features that help Dart stand on its own as a productive, ceremony-free language. Remember, Dart compiles to JavaScript, so everything you see here works across the modern Web.
Dart makes fluent APIs easy
Libraries like jQuery have popularized a fluent design that encourages chaining calls for easier-to-read code. Dart takes a cue from Smalltalk and adds method cascades to the language, so that any API can be used in a fluent style.
Without cascades, the variable button is repeated for every method call.
// Without cascades.
var button = new ButtonElement();
button.id = 'awesome';
button.classes.add('important');
button.onClick.listen((e) => beAwesome());
button.text = 'Click Me!';
Use cascades to help reduce repetition.
// With cascades.
var button = new ButtonElement()
..id = 'awesome'
..classes.add('important')
..onClick.listen((e) => beAwesome())
..text = 'Click Me!';
