"node" entries
Isomorphic JavaScript with LazoJS
In search of the holy grail, again
When I started at @WalmartLabs I was placed on team that was tasked with creating a new web framework from scratch that could power large public facing web sites.
I recently had the opportunity to speak about this experience at OSCON. The title of the talk was “Satisfying Business and Engineering Requirements: Client-server JavaScript, SEO, and Optimized Page Load”, which is quite the mouthful.
What the title attempted to encapsulate and the talk communicated was how we solved the SEO and optimized page load issue for public facing web sites while keeping UI engineers, myself included, happy and productive. Let’s take a look at how we achieved this with the creation of a new isomorphic JavaScript web framework, LazoJS.
Next-generation Web apps with full stack JavaScript
Power scalable Web apps with 100% JavaScript
Since its introduction, JavaScript was often seen as a limited object-oriented language that had many “bad” parts. The situation today is almost the opposite.
In competition with Java, C#, and Ruby, JavaScript is developing one of the largest ecosystems for web applications today. Why, as it seems, is a language made for web browsers gaining traction for building next-generation web applications on the server-side too?
In fact, you can see another example of disruptive innovation at work. As Clayton Christensen explained in his innovation theory, affordability and access are important drivers behind technology shifts. While the LAMP stack and its peers with Ruby, Python, Java, and C# provide the foundations for many server-side web applications today, JavaScript ships natively with web browsers, which enables a much larger part of the digital population to experiment with web development. In addition to lower costs of infrastructure and easier installation, companies get access to a larger pool of web developers.
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.
What Kind of JavaScript Developer Are You?
Fault lines make conversation difficult
“JavaScript developer” is a description that hides tremendous diversity. While every language has a range of user skill levels, JavaScript has a remarkably fragmented community. People come to JavaScript for different reasons from different places, and this can make communication difficult. Sometimes it’s worse than that—not everyone likes everyone else.
“JavaScript developer” used to mean “web developer,” specifically a developer who spends a lot of time working in the browser. Even as JavaScript became a specialty of its own, most JavaScript developers came through a broader web practice first, learning HTML and CSS before tackling the DOM. This was my path, and is still a common one. It was reasonably easy to absorb JavaScript by example, using it as an object manipulation language before pushing into the harder corners.
Many programmers, however, started on the server-side, building code that filled templates. Server-side JavaScript existed, in the Netscape Enterprise Server, for example, but was a tiny fraction in a world dominated by Perl, Java, Python, Ruby, and ASP’s languages. Developers who spent most of their time writing code that ran on the server worked with a different set of tools and expectations, and had to shift gears as JavaScript became a more critical part of web applications. (Some of these developers generate a lot of JavaScript—JSON is, after all, JavaScript—but would prefer to think of JavaScript’s role in that as an accident.)
Another group of developers came from desktop applications, and expected more direct control over the interface. Many of these developers now understand JavaScript because the browser forces them, not because they want to.
Involuntary JavaScript creates a tremendous amount of tension around the language. Normally, the people who dislike a programming language can just work with something else. JavaScript’s browser dominance makes that hard.
Other developers, though, are much much happier and much deeper into JavaScript. The JavaScript revival that became visible with the rise of Ajax in 2005 gave the language greater credibility. Douglas Crockford’s work “Unearthing the Excellence in JavaScript,” JavaScript: The Good Parts demonstrated a powerful language lurking in a toolset many had considered trivial.
Over the past decade, JavaScript’s power and reach have grown thanks largely to a core group of developers whose focus on the language has created best practices and frameworks, while driving browser vendors to improve their implementations. Node.js emerged from this work, giving JavaScript a unique server-side framework that deeply reflects the language.
The Fluent Online Conference Preview
JavaScript power on display
As JavaScript and the Web connect more and more technologies, conversations grow broader and broader. While the Fluent conference is large enough to cover a broad range, we created a sampler of topics for the two-hour online conference I hosted with Peter Cooper last Thursday. They’re all very different talks, showing many paths you can explore.
Martha Girdler opened the show with a pure JavaScript talk, “this” in JavaScript: How It Really Works (at 6:38). She isolated the headaches I’d given myself the last time I used “this” with her discussion of sorting out the scope chain (at 14:34).
Next up was Wes Bos, demonstrating Hardware Access and Device APIs with JavaScript and HTML5 (at 23:30). As new APIs let JavaScript connect more deeply with the capabilities of the mobile devices we carry, he’s finding opportunities that go well beyond what we thought of as “the Web” even a couple of years ago. He demonstrated how access to the camera and microphone can let you treat the device as a motion detector, an unusual task for a web browser (at 44:07).
Pam Selle visited the server side, demonstrating Prototyping a la Node with Express (at 1:02:41). She showed how to quickly build a simple application for user testing, explaining how the testing worked as well as the code (at 1:14:17, though I really liked the discussion of anger in testing at 1:17:20).
Given the intense activity in JavaScript frameworks, we had to explore at least one. Brad Green and Shyam Seshadri, who just finished our AngularJS book, explored the Principles of AngularJS (at 1:23:35). The shift toward a model in which a framework “allows you to teach the browser how to understand these new components that you create” (at 1:27:08) reminded me that JavaScript isn’t just working with the browser lately. In many ways, it’s becoming a tool for adding capabilities to the browser instead. As they put it later (at 1:42:03), AngularJS is in many ways a meta-framework.
The video doesn’t quite capture the interactivity of the event, though you’ll get to see the questions speakers took from the audience over chat. For a much more intense encounter with JavaScript and the Web, please consider coming to the live version of Fluent, May 28th to 30th in San Francisco. We’ll have coverage of all of these topics and many many more.
[adrotate banner=”3″]
Where are JavaScript and the web going?
The Fluent conference co-chairs look ahead.
JavaScript and HTML5 just keep moving. One day it’s form validation, the next animation. Then it becomes full-on model view controller stacks getting data from sensors on devices and communicating with back-end servers that are themselves largely JavaScript.
Peter Cooper and I have tried to capture some of this power in the upcoming Fluent conference, so that attendees can find their ways to the tools that work for them. We also have an online preview coming this Thursday, April 4th.
Peter and I paused for a moment to talk about what we’re doing and where we see JavaScript and the Web heading. Though we work together on the conference, our perspectives aren’t quite the same, something I think works out for the better.
Editorial Radar: Functional languages
The benefits of functional languages and functional language techniques.
O'Reilly editors Mike Loukides and Mike Hendrickson discuss the advantages of functional programming languages and how functional language techniques can be deployed with almost any language.
Microsoft opens up
How Microsoft is contributing to and benefitting from open source.
Microsoft seems to be embracing open source more and more. What does this tell us about the company's near-term future?