"isomorphic" entries
Renaming isomorphic JavaScript?
What you need to know to make an informed choice.
Abbott and Costello performing “Who’s on First?”
Abbott and Costello’s signature wordplay sketch “Who’s on First?” is one of the most renowned comedic routines of all time. Trying to describe the routine here will do it little justice, you’ll just have to watch it yourself. As funny as it may be, the sketch reveals a crucial fact: names are important. Good names should be self-explanatory, precise and reveal intent. Bad names leave people confused and aggravated and should be avoided at all cost. When we write code, we must always think about variable names, function names, file names, etc. But naming things is hard. Phil Karlton probably said it best: “There are only two hard things in Computer Science: cache invalidation and naming things.”
Since Node.js was first released in 2009, many developers have started discussing and implementing ways to share JavaScript code between the web application server and the browser. This sharing of JavaScript code allows for assembling web pages on either the client or server, with the benefits of faster initial page load times and improved search engine optimization. The name of this approach was coined by Charlie Robbins and later popularized by Spike Brehm as “isomorphic” JavaScript. Such applications are isomorphic in the sense that they take on equal (ἴσος: isos) form or shape (μορφή: morphe) regardless of which environment they are running on, be it the browser or the server.
The power of connection
URLs are the Web's unique superpower.
Over the past two decades, the heart of the Web has come to seem ordinary, forgettable. Some software has gone so far as to bury it and make it invisible, but it still worked its magic behind the scenes. As competing systems have made it disappear, though, absence has made many hearts grow fonder.
The humble URL is pretty ugly. The Web’s creator, Tim Berners-Lee, was embarrassed that people looked at them. It’s plain text, the computing interface that came right after punchcards and switches. The openings are always verbose, with a long “http://” (or similar) preceding the actual place you want to go. Excessively abstract debates about URIs aside, automated systems’ fondness for opaque identifiers has made many URLs hideous piles of characters that only a lookup table could enjoy. (Are QR codes even uglier?)
Even done badly, however, the URL is perhaps the most powerful innovation in networking history. While prior systems (IP addresses, DNS, and similar) had let us connect computers, URLs let us connect people’s creations. URLs let us share other people’s ideas, and promote our own ideas. The power to say “this bit of text will (mostly) reliably get you this content today” is a basic feature fundamental to the Web’s triumph.
Read more…
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.
It’s the end of the web as we knew it
You might feel fine.
For the past 15 years, Google has enforced the classic “HTML as foundation” architecture at the heart of the Web. Content creators and the developers who support them had to present content and link information as part of their pages’ HTML if they wanted Google’s spidering bots to see them. Google effectively punished developers who made links or content available only through JavaScript (or images, or CSS), giving them low or non-existent search results.
Google did this to keep their processing simple, not because of a deep fondness for HTML. Even as Google’s bots stuck to a simple diet of HTML, other parts of Google were developing JavaScript-centric approaches, like AngularJS: a “Superheroic JavaScript MVW Framework” that “is what HTML would have been, had it been designed for building web-apps.”
Angular is far from alone. As JavaScript grew, more and more programmers wanted to build their apps as programs, not as pages. Or, as Jen Simmons summarized it at Fluent, “Dang that stupid HTML, I’m just going to load an empty page… then I’ll run the real program, I’ll run the JavaScript.” Read more…