| CARVIEW |
Popular topics:
Web Dev Posts
TurboGears Just Keeps Getting Better
A quick look at the open source web framework
Alessandro Molina, is CTO at Axant.it and a member of the TurboGears web framework development team. I recently got the chance to sit down with him to talk about the exciting opportunities TurboGears offers users, how being open source has affected the proejct, and what we should expect next.
- The current focus of the TurboGears dev team is reducing dependencies and making the framework faster! [Discussed at 0:12]
- Yes, TurboGears 2.1 and forward supports MongoDB! [Discussed at 1:56]
- TurboGears make editing code on the fly very easy. [Discussed at 3:45]
- It takes an open source community to raise a web framework. [Discussed at 4:57]
You can view the entire interview in the following video.
From JavaScript to Declarative Markup
Evolving enhancements for web developers
Web architecture separates structured content (markup), presentation (style), and behavior (JavaScript). As recently as a decade ago, many developers worked in all three, but the years since Ajax arrived have brought more specialization. The rise of JavaScript in particular has led to approaches that have JavaScript carry the load. In the past few weeks, I’ve been delighted to see work that suggests a different path forward, one that takes greater advantage of the flexibility markup offers.
Last week, at the Artifact Conference, I was delighted to return to the world of web designers. The crowd was full of people who know very well what JavaScript can add to their site and how they want to include it, but who don’t focus on it. JavaScript is just a tool, often even a tool wielded later in the process after the basic framing of the site is complete.
JavaScript Flexibility: Fun, But Use with Care
JavaScript is dynamically typed
When you begin programming in JavaScript, you’ll need to use variables. A variable is just a bit of storage to hold a value. Just about every line of code you write will use a variable of one kind or another, so it’s a good idea to get familiar with the kinds of things you can put in variables, and how you can use them. Now, if you’re coming from another programming language, like Java, you might be surprised to see how loose JavaScript is about variables and their type. JavaScript doesn’t care if your variable starts out with a string value, and ends up being a number: JavaScript’s dynamically typed.
In this installment of Head First JavaScript Programming Teasers, you’ll learn about the basics of variables, how JavaScript is dynamically typed, and why it’s a good idea to stick with one type for your variables.
Exploring Hypermedia with Mike Amundsen
The Web Can Teach the Enterprise
The Web’s flexibility has helped it to survive and thrive, pushing well beyond the browser-based universe where it first showed its promise. While I’ve spent most of my time working with the HTML/CSS/JavaScript side, the HTTP side of the original HTML+HTTP combination that built the Web is perhaps even more flexible.
I enjoyed talking with Mike Amundsen, Principal API Architect at Layer 7 Technologies, who has spent much of his recent career encouraging enterprise customers to shift toward web architectures. While REST has emerged over the past decade to eclipse SOAP-based “web services”, Amundsen has eagerly promoted the next step beyond the simple CRUD-based model of early REST work: hypermedia.
Our conversation ranged from the history and foundations of REST through the many ways to integrate that work with existing enterprise practice to a glimpse at what the future might hold for frameworks, design, and architecture.
- REST as enterprise architectures principles applied to hypermedia (at 1:57)
- Transitioning from RPC-based models to hypermedia, by including additional information in response. (at 3:00)
- The value of opinionated message formats and eventual integration into opinionated frameworks. (at 5:51)
- Shifting from shared understandings of object models to messages. (at 8:50)
- “Enough coupling, but not too much” to allow mixing of technologies. (at 11:15)
- Human negotiation, HTTP negotiation, and responsive web design (at 14:20)
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.
JavaScript Makes Browsers Behave
Start adding functionality to your HTML and CSS with JavaScript
If you know HTML and CSS, you’re ready to begin learning JavaScript. But you might be surprised, because JavaScript looks quite different from both HTML and CSS. That’s because JavaScript is a language for computation. Unlike HTML, which is for marking up content to add meaning and structure to that content, and CSS, which is a set of declarative rules for adding style to selected elements, JavaScript is for describing computation: it’s a language for describing how things get done.
A JavaScript program consists of a series of statements, each of which does a little bit of computation. A statement might store some data in a variable, or modify data with an expression, or make a decision about what to do based on the value of a variable, or even tell the browser to do something, like pop up an alert.
Want to know more? In part four of Head First JavaScript Programming Teasers, Eric shows you how JavaScript is different from HTML and CSS, and why. He also steps you through a simple example of JavaScript code, so you can get a taste of how it works.
JavaScript: Not as Expected
A good match for the similarly unexpected Web?
JavaScript’s ever-growing importance still takes people by surprise. Every time I post about things JavaScript makes possible, I get pushback from people who refuse to be impressed by JavaScript. Why? Because it isn’t what they wanted.
In the course of a week, I get to hear from different quarters about how JavaScript is half Lisp, and terrible either because it dares to be half-Lisp or because it only manages to be half Lisp. Similarly, as functional programming has become more visible, I’ve heard more from people who think JavaScript programming is too functional or not functional enough. People disappointed in JavaScript because it doesn’t have strong typing are a constant, as are people who find prototypal inheritance perverse. JavaScript syntax—I’m sure someone must like it.
It’s tempting to tell the story of JavaScript as a series of historical accidents. Brendan Eich put together LiveScript, applying a variety of techniques to meet a particular set of needs quickly. Since then, we’ve been dealing with JavaScript’s shift from a simple object manipulation language to a much broader and more powerful toolkit, unable to change approach because of the unique dynamics of the browser world.
Cutting Your Programming Teeth on JavaScript
Why it's a great first programming language
JavaScript is a bit different from other programming languages. How? Well, JavaScript runs in an environment, and that’s usually the browser. So when you learn JavaScript, you’ll learn both the language basics, as well as how to use JavaScript in the browser to do things like interact with the page, add and remove elements, draw graphics, or store data locally in the browser.
Another way that JavaScript is a bit different is that it’s so easy to get started with: all you need is a basic text editor and a browser, and you’re ready to go. This also makes JavaScript a great first language. For instance, the fact that you can run JavaScript in the browser means you have a built-in, easy way to see your results, and you can create and interact with a web page interface, without having to write a huge amount of code.
We’re designing Head First JavaScript Programming so that you can learn JavaScript, from scratch, even if you’ve never programmed before. All you need is just some background in HTML and CSS. If that’s where you’re coming from, and you’re itching to learn how to program, check out part three of Head First JavaScript Programming Teasers, where we step you through what makes JavaScript unique, and why it’s a great first programming language.
CSS Selectors as Superpowers
You thought CSS was weak? Think again.
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.
Location, Location, Location
Why where you put your script element matters
Everyone knows you add JavaScript to your page by putting your <script> element at the top of your HTML page, right? Not so fast. In part two of Head First JavaScript Programming Teasers, Eric explains the nuts and bolts of the <script> element: how to add it to your page, and where.
While you can put a <script> element just about anywhere in your code, there are a couple of things you should know before you make any decisions about where to add it. For instance, you might already know that the browser reads your page top down and starts executing your JavaScript as it gets to the code. That means if you put your JavaScript in the <head> of your document, the browser will execute the code before it loads the rest of the page. That might be what you want… or it might mean that users are sitting there looking at a blank page while your script is executing.
Watch the video for a couple of other tips about the <script> element, taken from our upcoming book, Head First JavaScript Programming.
And if you missed the first part of this video series, you can watch it here.
