"jquery" 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.
Event-driven application design with JavaScript
Look beyond jQuery to an MV* approach
When you start building dashboards for interacting with data, such as calculators, editors, or result browsers, understanding JavaScript and client-side MVC becomes important. Why do you need an event-driven application design and a separation of interface state and behavior? Let me walk you through some examples.
You’ve probably seen seen simple example editors, where the browser acts as an editor for to-do lists. In these applications, you edit to-do items, consisting of a text and a state (pending or done). These small editors are very helpful for studying monitoring events from the keyboard and partially updating page content. These are the main principles for building applications in web browsers.
Once you going beyond to-do list editors, the requirements quickly increase. For example, you might work with multiple counters that observe the cursor position, or the number of words in a text box. You might need to support multiple editing modes or text formatters, or edit actions and state synchronization with a backend.
A concrete approach to learning how to program
A solid foundation on which more meaningful learning can happen
As someone who has previously taught computer programming for nearly a decade, I’m often asked questions that involve “what’s the best way to go about learning to program computers,” or “what’s the best way to get a software engineering job,” or “how can I learn to build mobile or web apps?”
Most of the readers of this blog have probably faced the same question at some point in their career. How did you answer it? I’ve seen many different responses: “come up with an idea for an app and build it,” or “get a computer science degree,” or “go read The Little Schemer,” or “join an open-source project that excites you,” or “learn Ruby on Rails.”
The interesting thing about these responses is that, for the most part, they can be classified into one of two categories: top-down approaches or bottom-up approaches. Top-down approaches are informed by the opinion that it’s better to be thrown in the middle of an application or a framework which encourages the learner to piece together knowledge in that context. Many books and online tutorials use an explicit top-down approach, often starting with the basics of a popular methodology, framework or technology. The most visible example of this are books on Ruby on Rails — they almost always inevitably begin with a description of the Model-View-Controller design pattern, but defer the incredible number of non-obvious ideas that make it up (Object-Oriented Programming, for instance).
On the other hand, a bottom-up approach starts with the basics/fundamentals of programming and then slowly builds your knowledge over time. In contrast to top-down approaches, bottom-up approaches try to minimize the number of these non-obvious ideas that the learner has to take for granted. Khan Academy and Code Academy are two examples of online sites that use a bottom-up approach to teaching programming. For the most part, they completely leave out any specific framework and focus on fundamentals of programming.
Keeping jQuery in Check
Segregated DOM makes for a maintainable JavaScript codebase
jQuery makes it really easy to work with the DOM and other browser APIs. Almost too easy. Having the almighty $ available to you at all times can lead to an architectural style that I refer to as “jQuery soup.”
A jQuery soup codebase is one where adhoc references to $ appear everywhere. AJAX calls and DOM manipulations are intermingled alongside application logic and business rules.
Taking this approach in a JavaScript app of any real significance will cause a lot of pain. Any part of your app that is reaching out to the DOM via $ is essentially mutating a big bag of shared global state. That means that whenever you want to modify or extend that part of the app you need to carefully maintain a large mental model of every DOM interaction in your head. That’s really hard to do, and very much prone to error.
Interactive map: bike movements in New York City and Washington, D.C.
The cities appear to breathe as bicycles move into office districts in the morning and out in the evening.
From midnight to 7:30 A.M., New York is uncharacteristically quiet, its Citi Bikes — the city’s new shared bicycles — largely stationary and clustered in residential neighborhoods. Then things begin to move: commuters check out the bikes en masse in residential areas across Manhattan and, over the next two hours, relocate them to Midtown, the Flatiron district, SoHo, and Wall Street. There they remain concentrated, mostly used for local trips, until they start to move back outward around 5 P.M.
Washington, D.C.’s bike-share program exhibits a similar pattern, though, as you’d expect, the movement starts a little earlier in the morning. On my animated map, both cities look like they’re breathing — inhaling and then exhaling once over the course of 12 hours or so.
The map below shows availability at bike stations in New York City and the Washington, D.C. area across the course of the day. Read more…
The Power of a Private HTTP Archive Instance: Finding a Representative Performance Baseline
Velocity 2013 Speaker Series
Be honest, have you ever wanted to play Steve Souders for a day and pull some revealing stats or trends about some web sites of your choice? Or maybe dig around the HTTP archive? You can do that and more by setting up your own HTTP Archive.
httparchive.org is a fantastic tool to track, monitor, and review how the web is built. You can dig into trends around page size, page load time, content delivery network (CDN) usage, distribution of different mimetypes, and many other stats. With the integration of WebPagetest, it’s a great tool for synthetic testing as well.
You can download an HTTP Archive MySQL dump (warning: it’s quite large) and the source code from the download page and dissect a snapshot of the data yourself. Once you’ve set up the database, you can easily query anything you want.
Setup
You need MySQL, PHP, and your own webserver running. As I mentioned above, HTTP Archive relies on WebPagetest—if you choose to run your own private instance of WebPagetest, you won’t have to request an API key. I decided to ask Patrick Meenan for an API key with limited query access. That was sufficient for me at the time. If I ever wanted to use more than 200 page loads per day, I would probably want to set up a private instance of WebPagetest.
To find more details on how to set up an HTTP Archive instance yourself and any further advice, please check out my blog post.
Benefits
Going back to the scenario I described above: the real motivation is that often you don’t want to throw your website(s) in a pile of other websites (e.g. not related to your business) to compare or define trends. Our digital property at the Canadian Broadcasting Corporation’s (CBC) spans over dozens of URLs that have different purposes and audiences. For example, CBC Radio covers most of the Canadian radio landscape, CBC News offers the latest breaking news, CBC Hockey Night in Canada offers great insights on anything related to hockey, and CBC Video is the home for any video available on CBC. It’s valuable for us to not only compare cbc.ca to the top 100K Alexa sites but also to verify stats and data against our own pool of web sites.
In this case, we want to use a set of predefined URLs that we can collect HTTP Archive stats for. Hence a private instance can come in handy—we can run tests every day, or every week, or just every month to gather information about the performance of the sites we’ve selected. From there, it’s easy to not only compare trends from httparchive.org to our own instance as a performance baseline, but also have a great amount of data in our local database to run queries against and to do proper performance monitoring and investigation.
Visualizing Data
The beautiful thing about having your own instance is that you can be your own master of data visualization: you can now create more charts in addition to the ones that came out of the box with the default HTTP Archive setup. And if you don’t like Google chart tools, you may even want to check out D3.js or Highcharts instead.
The image below shows all mime types used by CBC web properties that are captured in our HTTP archive database, using D3.js bubble charts for visualization.
Mime types distribution for CBC web properties using D3.js bubble visualization. The data were taken from the requests table of our private HTTP Archive database.
Read more…
8 Dart Features Those Fat Cats Don’t Want You to Know
Productive code without ceremony
[contextly_sidebar id=”2bca5cb6af99cf17862f5497954ec380″]
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!';
Weekly Highlights and Insights: April 29-May 3
Leading indicators, CSS selectors, medical data sharing, DDoS visualization, and a new jQuery class
Leading Indicators: Over on O’Reilly Radar, Mike Loukides and Q Ethan McCallum come up with a few ideas for evaluating an organization’s data science program from the “outside.”
CSS Selectors as Superpowers: Simon St. Laurent hopes that “the success of CSS selectors will bring developers to look for other ways to apply pattern-matching to their markup.”
Data sharing drives diagnoses and cures, if we can get there (Parts 1 & 2): Andy Oram explores the take-aways from this year’s Sage Congress.
Visualization of the Week: Jenn Webb shows us Ludovic Fauvet’s Logstalgia visualization of a recent VideoLAN DDoS attack.
jQuery for Advanced Front-End Development: New jQuery class from O’Reilly School of Technology.
CSS Selectors as Superpowers
You thought CSS was weak? Think again.
[contextly_sidebar id=”9b64912f350d6f393dda0b36710050d8″]
After years of complaints about Cascading Style Sheets, many stemming from their deliberately declarative nature, it’s time to recognize their power. For developers coming from imperative programming styles, it might seem hard to lose the ability to specify more complex logical flow. That loss, though, is discipline leading toward the ability to create vastly more flexible systems, a first step toward the pattern matching model common to functional programming.
Way back when I was writing about styling XML in browsers, I didn’t even have to stop to think about how difficult it would be to repurpose CSS selectors for XML documents. Since they weren’t tightly bound to assumptions about HTML beyond the existence of elements and attributes, they just worked.
The tool that most vividly demonstrated the real power of selectors, though, was jQuery. I may have annoyed some people by referring to jQuery as “that framework that lets you use CSS selectors instead of DOM tree walking” for a while, but Remy Sharp makes clear the power of that:
The ease in which jQuery could be learnt was the appeal to me. All the DOM navigation was done using CSS expression using some insane black box magic that John Resig had come up [with] – saving my limited brain power, and once I had those DOM nodes, I could do what I wanted to them (usually some combinations of showing, hiding, fading and so on).
Over time, as Sharp notes, Web browsers learned from jQuery, building this basic lesson deeper into their tools and making it work more efficiently:
In those 7 years, quite a bit has happened. Probably one of the most important steps forward was the introduction of querySelectorAll.
Being able to give a native function of a browser a CSS expression, and it doing the work to navigate the DOM is a huge (literally) part of jQuery.
Learning Paths for JavaScript
Cody Lindley on finding your way through a popular and powerful language
Everyone learns and teaches JavaScript their own way, but Cody Lindley (@codylindley) has spent a lot of time with a lot of different kinds of learners. He made the jQuery Cookbook happen, finding and managing contributors as well as making a large contribution himself, and he’s a regular at JavaScript conferences.
O’Reilly recently published his JavaScript Enlightenment and DOM Enlightenment, so it seemed like a good time to talk about how developers find their way through the many choices JavaScript offers.
Highlights include:
- JavaScript developer? Or front-end engineer? Websites? Or applications? (at 0:52)
- Don’t be down on jQuery users (at 2:03)
- JavaScript objects are different, and critical (at 4:07)
- The varying degrees of genius in JavaScript libraries (at 7:17)
- Are buffers between your code and browser APIs necessary? (at 9:17)
- Running browser tests on the DOM (at 11:08)
- Needing more focused in-depth documentation (at 12:57)
His closing – “we need to do a better job communicating with the bulk of developers out there” – sounded just right to me.
You can view the entire conversation in the following video: