| CARVIEW |
Popular topics:
Web Dev Posts
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.
Drupal for Designers
Dani Nordin on what you need to know
Dani Nordin (@danigrrl) is an O’Reilly author (Drupal for Designers) and UX designer.
We sat down recently to catch up on her current projects and her predictions for the future of Drupal design. She shared some best practices for designing, her experiences with a large-scale academic project, and what criteria goes into the Design 4 Drupal Boston event.
Highlights from the conversation include:
- Learn the common pitfalls Drupal designers fall into, along with some tips and tricks to avoid them (hint: Drupal is like a cake recipe) [Discussed at the 0:17 mark].
- How the Berklee College of Music is using Drupal [Discussed at the 5:49 mark].
- The focus for 2013′s Design 4 Drupal Boston [Discussed at the 7:50 mark].
- The ways Drupal 8 could change how designers work [Discussed at the 9:40 mark].
You can view the entire interview in the following video.
How you can stop trashing PHP code
Design patterns for PHP
William Sanders (@williebegoode) is a Professor of Interactive Information Technology at the University of Hartford and author of over 40 technical books! His latest book with us is Learning PHP Design Patterns. We recently sat down to talk about design patterns and how they can help create reusable code and save you valuable time. You can also check out more from Bill at his website.
- Why use design patterns for PHP? [Discussed at the 0:28 mark.]
- Big programs and lots of code can become unwieldy [Discussed at the 2:06 mark.]
- Mobile devices and PHP design patterns [Discussed at the 5:30 mark.]
- Bill talks common design patterns and how they help [Discussed at the 7:25 mark.]
- How to start using design patterns with PHP [Discussed at the 10:15 mark.]
You can view the entire interview in the following video:
Related:
Stop standardizing HTML
It's time for developers to create their own vocabularies
When HTML first appeared, it offered a coherent if limited vocabulary for sharing content on the newly created World Wide Web. Today, after HTML has handed off most of its actual work to other specifications, it’s time to stop worrying about this central core and let developers choose their own markup vocabularies and processing.
When the W3C first formed, it formed around HTML, the core standard of content on the Web, defining the structure, appearance, and behavior of content. Over the next few years, however, it became clear that HTML was doing too much, and the W3C and other groups refactored appearance, behavior, and many semantics into separate specifications:
-
Cascading Style Sheets (CSS) took responsibility for presentation and layout.
-
JavaScript took responsibility for behavior, aided by the Document Object Model (DOM) and a variety of APIs for handling device and multimedia interactions.
-
WAI-ARIA took responsibility for accessibility semantics, ensuring that content remained available to a broad audience even if developers pushed the current boundaries of markup.
It’s not a completely neat separation – some of CSS feels like behavior, and JavaScript can manipulate presentation, for example, but it certainly took a lot of pieces out of HTML. A few aspects of HTML, notably media inclusion, are still mostly handled at the markup level, but most of them aren’t any longer. Forms and linking are both still defined in HTML itself, but aren’t difficult to implement separately.
Yet another JavaScript book?
For the next 15 weeks, a new learning video every week.
Eric Freeman and I are writing a new book: Head First JavaScript Programming, and to go along with it, we’re creating a series of teaser videos to give you a taste of what’s coming in the book, and a chance to learn a few JavaScript tidbits.
Why undertake writing a JavaScript book now? After all, isn’t there already a Head First JavaScript book (not to mention all the many other JavaScript books on the market)? Well, to make a long story short, when we published Head First HTML5 Programming, a book that teaches you how to use all the new HTML5 APIs (with JavaScript, of course), we discovered something: a lot of folks know a little JavaScript, but really want to understand it at a deeper level. They want to go beyond just simple scripting. To remedy that, we ended up taking a month to write a brief introduction to JavaScript in our Head First HTML5 Programming book, but it wasn’t enough. Readers needed more.
Will JavaScript take over the programming world?
Not if it surrenders its ubiquity advantage
Last July, I had to give an impromptu talk. What came out, much to my surprise, was roughly “JavaScript will dominate the programming world.” I didn’t say that JavaScript would dominate through sheer popularity – JavaScript may in fact top the list of languages disliked by programmers, because so many programmers use it as a strictly secondary language beside their preferred server-side toolkit.
Instead, I argued, as you’ll see in “Concentration,” that JavaScript would win by ubiquity, offering a solution that fit well enough in both clients and servers. While I still think JavaScript could indeed “fit well enough,” the winds have changed and JavaScript may be about to surrender its ubiquity advantage, as you’ll see in “Dispersion.”
Concentration: The Wrong Story
After decades of a Cambrian explosion, we may finally see a concentration in the use of a few programming languages and a corresponding decline of many others, leaving us with three main families of programming languages. (Remember, this story is wrong.)
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.
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:
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.
CSS keeps growing
Once used for simple formatting, CSS now dominates the web presentation layer.
Eric Meyer, the author of CSS: The Definitive Guide (and much more) has taught thousands of people CSS through his books, his talks, and his articles. I’ve always enjoyed hearing his take on the state of CSS, as he manages to find combinations of capabilities that make CSS more powerful than I thought it was when I first looked.
We sat down last week to discuss the many huge changes CSS3 is bringing, from improvements to old capabilities to completely new tools for animations, transforms, and layout. The continuous rate of change and the size of the specification are driving him to serialize the next edition of the Definitive Guide, releasing it in pieces. Developers can work from familiar foundations, but reach new destinations. The declarative strength of CSS3 lets you create presentation by describing it, and that style keeps proving more powerful.
Highlights of the interview include: Read more…
