- Awesome Awesomeness — list of curated collections of frameworks and libraries in various languages that do not suck. They solve the problem of “so, I’m new to (language) and don’t want to kiss a lot of frogs before I find the right tool for a particular task”.
- Breach — a hackable, modular web browser.
- The CompuServe of Things (Phil Windley) — How we build the Internet of Things has far-reaching consequences for the humans who will use—or be used by—it. Will we push forward, connecting things using forests of silos that are reminiscent the online services of the 1980′s, or will we learn the lessons of the Internet and build a true Internet of Things? (via Cory Doctorow)
ENTRIES TAGGED "browser"
Curated Code, Hackable Browser, IoT Should Be Open, and Better Treemaps
Trusting Code, Deep Pi, Docker DevOps, and Secure Database
- Trusting Browser Code (Tim Bray) — on the fundamental weakness of the ‘net as manifest in the browser.
- Deep Learning in the Raspberry Pi (Pete Warden) — $30 now gets you a computer you can run deep learning algorithms on. Awesome.
- Announcing Docker Hub and Official Repositories — as Docker went 1.0 and people rave about how they use it, comes this. They’re thinking hard about “integrating into the build ship run loop”, which aligns well with DevOps-enabling tool use.
- Apple’s Secure Database for Users (Ian Waring) — excellent breakdown of how Apple have gone out of their way to make their cloud database product safe and robust. They may be slow to “the cloud” but they have decades of experience having users as customers instead of products.
You might feel fine.
this is used to refer an object. But which object this refers too depends on the code you’re executing and how
Getting started with the DOM is easy once you understand how the browser translates your HTML into this internal structure made of objects. Once these objects are created, then you can manipulate them using a wide variety of properties and methods, to change the content of an element, to add a style to an element, or even remove an element from the page completely.
Web technologies have become the default, and are spreading
A few years ago, venture capitalist Marc Andreessen wrote that “software is eating the world”:
Six decades into the computer revolution, four decades since the invention of the microprocessor, and two decades into the rise of the modern Internet, all of the technology required to transform industries through software finally works and can be widely delivered at global scale.
That may be true, but Andreessen seems to have left out some of his earlier, more Web-centric visions (though perhaps he considers them complete).
Software may be eating the world, but the Web has been “eating software” in a similar sense for as long as the Web has been visible.
On the front end, the browser has grown from being a strange dumb terminal of documents and forms to a full partner. The browser not only provides a window into the world of classic websites, but helps us deal with devices that we can reach over a network. Their interfaces may be invisible or basic on the physical device, but offer much more when accessed through a browser. Web apps, though frequently not as capable as their desktop competition, long ago passed the point where their collaborative possibilities were more valuable than the details they lack.
The changing landscape of web platform extensibility
From its nascent days, the growth of the web has been marked by the waxing and waning of technologies, frameworks and ideas. Old ideas and technologies expire and fade away, and new ones arise in their place. Much as the cicada molts and leaves behind an old shell as it moves into adulthood, the web has seen countless ideas come and go as it has evolved.
Relics (and Catalysts) of the Web
Remember XHTML? More specifically, do you remember caring deeply about XHTML? You likely do. Do you still care about XHTML? Chances are, the answer is no. The same goes for Flash, DHTML, HTML Components and countless other buzzwords of the web that once felt so alive and important, and now feel like relics of another time.
Occasionally, however, we collectively stumble upon ideas and technologies that stand the test of time. These are ideas that don’t just evolve with the web–they are often a catalyst for the evolution of the web itself. Ideas like Cascading Style Sheets and XMLHTTPRequest, the vendor hack that spurred the AJAX revolution, are two examples among many.
Live coding a shopping cart and other rich web UI goodness
In his talk, Rich Web UIs with Knockout.js, Steve quickly summarized the problems Knockout solves and why Knockout is a particularly strong candidate to solve those problems, before working on a shopping cart example to show off how bindings, including custom bindings, work within Knockout.
Some key parts of Todd’s talk include:
- A description of the problem Knockout solves [at 00:41]
- What is Knockout and MVVM? [at 01:38]
- 4 unique things about Knockout [at 03:12]
- Live coding a shopping cart [at 06:02]
- Summary [at 20:15]
Anyone with a further interest in Knockout should check out the project’s homepage and particularly the live Hello World example and interactive online tutorial which guides you through building a Web UI using the MVVM pattern with Knockout.js in an interactive sandbox-style environment.
One speaker at Fluent 2013 whose talk was particularly well received was Todd Kloots of Twitter who spoke about HTML5′s pushState API and demonstrated how it was used in Twitter’s Web-based interface.
Some key parts of Todd’s talk include:
- The opportunity Twitter saw in pushState [at 01:45]
- What you had to do with dynamic URLs before pushState [at 02:46]
- A summary of the pushState API [at 06:10]
- Gotchas and browser support [at 07:58]
- How pushState sped up navigation on Twitter.com without re-architecting [at 12:15]
- What Twitter had to do server-side to make progressive enhancement work [at 19:11]
- Final thoughts [at 31:37]
- Q&A [at 32:15]
Creating flexible expectations
“Expect the unexpected” has long been a maxim of web development. New browsers and devices arrive, technologies change, and things break. The lore of web development isn’t just the technology: it addresses the many challenges of dealing with customers who want to lock everything down.
Is there room for programmers to tell a similar story?
I don’t mean agile. Agile development is difficult enough to explain to clients, but applications that adapt to their circumstances are a separate set of complications. Iterating on adaptable behaviors may be more difficult than iterating on adaptable designs, but it opens new possibilities both for applications and for the evolution of the Web.
Responsive Web Design is (slowly) becoming the new baseline, giving designers a set of tools for building pages that (usually) provide the same functionality while adapting to different circumstances. Programmers sometimes provide different functionality to different users, but it’s more often about cases where users have different privileges than about different devices and contexts.
Adjusting how content displays is complex enough, but modifying application behavior to respond to different circumstances is more unusual. The goal of most web development has been to provide a single experience across a variety of devices, filling in gaps whenever possible to support uniformity. The history of “this page best viewed on my preferred browser” is mostly ugly. Polyfills, which I think have a bright future, emerged to create uniformity where browsers didn’t.
Browsers, though, now provide a huge shared context. Variations exist, of course, and cause headaches, but many HTML5 APIs and CSS3 features can work nicely as supplements to a broader site. Yes, you could build a web app around WebRTC and Media Capture and Streams, and it would only run on Firefox and Chrome right now. But you could also use WebRTC to help users talk about content that’s visible across browsers, and only the users on Firefox and Chrome would have the extra video option. The Web Audio API is also a good candidate for this, as might be some graphics features.
This is harder, of course, with things like WebSockets that provide basic functionality. For those cases, polyfills seem like a better option. Something that seems as complicated and foundational as IndexedDB could be made optional, though, by switching whether data is stored locally or remotely (or both).
HTML5 and CSS3 have re-awakened Web development. I’m hoping that we can develop new practices that let us take advantage of these tools without having to wait for them to work everywhere. In the long run, I hope that will create a more active testing and development process to give browser vendors feedback earlier—but getting there will require changing the expectations of our users and customers as well.