web development

The browser wars and the birth of JavaScript

The browser wars and the birth of JavaScript

“Any application that can be written in JavaScript will eventually be written in JavaScript.” — Atwood’s Law, stated by Jeff Atwood in a blog post titled “The Principle of Least Power,” July 17, 2007

Before anything like an Android device or iPhone existed, desktop computers were the battleground for the browser wars. The battle involved billions of dollars invested by a number of companies, all based on the premise that whoever ruled the desktop browser market would own the internet. Today, mobile devices account for nearly half of all website traffic. Back in the 1990s, however, almost all of the action on the web came from desktop machines, and the vast majority of those desktop machines were running some flavor of Microsoft Windows.

In the browser world, the first-mover advantage belonged to Netscape Communications Corporation. They built the Netscape Navigator browser that made the web accessible to millions for the first time. Netscape had more than 80% of the market, but they also had no shortage of competition. IBM had a browser for OS/2. Oracle had the Powerbrowser, a Netscape-compatible product that included something called the Database Markup Language. The real danger to Netscape, of course, came from the company that owned more than 80% of the world’s desktops: Microsoft.

Strategically, Netscape realized that the web needed to move past static web pages to reach its full potential. Even if they were created dynamically by something like a CGI script on the web server, pages didn’t change once they arrived in your browser. If you wanted to see even a slightly modified version of a page, you had to send a request back to the server and wait for a response. For all its sophistication, a web browser felt a lot like a dumb terminal attached to a mainframe. What web developers needed was a programming language that would run in the browser, taking advantage of the processing power of the desktop machine to give users a richer experience.

Continue reading “The browser wars and the birth of JavaScript”

Share
Modern web applications on OpenShift: Part 3 — Openshift as a development environment

Modern web applications on OpenShift: Part 3 — Openshift as a development environment

Welcome back to the final part of this multipart series about deploying modern web applications on Red Hat OpenShift. In the first post, we took a look at how to deploy a modern web application using the fewest commands.

In the second part, we took a deeper look into how the new source-to-image (S2I) web app builder works and how to use it as part of a chained build.

This third and final part will take a look at how you can run your app’s “development workflow” on OpenShift.

Continue reading “Modern web applications on OpenShift: Part 3 — Openshift as a development environment”

Share

Have some CoffeeScript with your React

In my continual search for the ever more efficient and pragmatic Javascript UI framework I’ve stumbled upon React, but not just React, the special combination of React, Coffeescript, and RequireJS.

JSX is the more elegant way to compose the DOM within React classes, however, it does require an additional compile step, and there is a bit of added complexity when integrating with RequireJS.

It would be hard to give up JSX and go back to building the DOM with plain javascript, the syntax isn’t so elegant, and it gets quite busy. Coffeescript, at first thought, may seem like a lesser alternative; I will propose, however, that it may just be equal to more practical than even JSX.

Continue reading “Have some CoffeeScript with your React”

Share

Communicating Large Objects with Web Workers in javascript

As html5 and client side solutions become more prevalent, the need for handling more and more data through javascript will increase.  One such challenge, and the focus of this article, is a strategy for handling hundreds of megabytes of data through Web Workers.

What created this need for me personally was the development of Log Reaper [1] which is a client side approach to parsing log files with no server side upload or processing. Log Reaper identifies and parses log files (of currently accepted types) in a Web Worker, then communicates the structured objects back to the browser where they are further map reduced and visualized.

Continue reading “Communicating Large Objects with Web Workers in javascript”

Share

Git Bonsai, or Keeping Your Branches Well Pruned

Today, we’ll share a small victory in our DevOps journey at Red Hat IT. This cross-team collaboration has saved our IT organization some headaches and wasted time. We open-sourced the code, hoping it can help you, too.

The Dev problem, from Sam Van Oort:

Old, pruned git branches are sometimes re-created by accident, making a mess for our developers.

Continue reading “Git Bonsai, or Keeping Your Branches Well Pruned”

Share

Feeling Developer Pain

Introduction

Hi, I’m Steve, a member of the Inception team at Red Hat. The Inception team was pulled from different parts of IT to foster DevOps culture in Red Hat. Though we’ve only been a team for a little over a month, we’ve been trying to do some early projects to make everyone’s lives easier.l

We spent quite a bit of time in our early meetings identifying pain points in the current processes. We talked with a few developers, ops folks, noted historical issues and ran with general brain storming. We heard a lot about configuration management, lack of information, redundant and time consuming tasks, and many more of what one expects when asking tech people what pains them.

Of course, Tim (another Incepticon) and I were itching to write some code so once the team identified a common issue for both developers and ops engineers we jumped in head first.

The rest of this post describes our journey from initially trying to implement a simple solution to improve the day-to-day lives of developers, through the technical limitations we experienced along the way, and finally arrives at the empathy for our developers we’ve gained from that experience. We’ll wrap up with a note on how Red Hat Software Collections (announced as GA in September) would’ve simplified our development process.

Continue reading “Feeling Developer Pain”

Share

Leveraging RHSCL for DevOps

As you certainly know, DevOps is all the rage these days. While DevOps is many things, some pure “buzz” and some legitimate, we aren’t going to talk about all that. Instead, let’s talk about one small piece of the problem, simplifying the consistency of deployment platforms.

Part of what has made DevOps, and, by extension, Continuous Deployment concepts possible has been the simplification, at least on some vectors, of the modern data center. Starting with virtualization, extending to configuration management and deployment (e.g. satellite and puppet), and finally, the advent of the hybrid cloud, operational functions have become much simpler for the layperson. However, ensuring that your development environment is the same as production is still not a completely solved problem.

Continue reading “Leveraging RHSCL for DevOps”

Share

Red Hat Software Collections 1.0 Beta Now Available

You may have seen references to “software collections” in this blog, but this is different.  “Red Hat Software Collections”, now in beta for the first time, is a collection of refreshed and supported web/dynamic languages and databases for Red Hat Enterprise Linux.   Now you can have two versions of software on one OS, or refresh these languages and databases more frequently.  See this list below!

Continue reading Red Hat Software Collections 1.0 Beta Now Available

Share