Category: Performance

There’s an old adage in the software industry – premature optimization is the root of all evil. A corollary to this should be – no optimization is just as bad as premature optimization.

Rendering large data sets in the browser while optimizing for performance and accessibility is a complex problem. The current approach to handling long lists of data is using an infinite scroll pattern to incrementally load and render data just before the data enters the view.

When building web apps, writing processing intensive code can be a challenge. One issue is getting predictable running times across browsers and JavaScript engines that optimise different code paths differently, as well as producing code that doesn’t interfere with user experience.

So you’ve built an amazing app using Dojo and now you are ready to go live. After a bit of research, you learn that traditional deployments are challenging! Luckily, the days of FTPing files are long gone, and we can rely on Docker for fast, reliable deployments.

In a previous post we looked at how to compile the popular programming language Go to WebAssembly. WebAssembly is a new programming language which provides a compact binary format for the web. In this post we’ll explore another WebAssembly target language called AssemblyScript.

For many years there has been the only way to write client-side logic for the web; JavaScript. WebAssembly provides another way, as a low-level language similar to assembly, with a compact binary format. Go, a popular open source programming language focused on simplicity, readability and efficiency, recently gained the ability to compile to WebAssembly.

WebAssembly has grown in popularity due to its ability to improve application performance and support transpilation of source code in other languages into something that may get leveraged in a web browser.

Last Thursday I was lucky enough to get over to the highly regarded web development conference ffconf in Brighton. This was my first time at the event and I can say that it lived up to and even exceeded my expectations.

A common complaint of modern web apps is the concept of jank; web pages being unresponsive to user input and frame rates being low. Left unmitigated, this problem leads to a poor quality experience for end users of our web applications.

At this months’s FullStack London 2018, SitePen Engineer James Milner presented the talk “Improving User Experience With Web Workers”. Web browsers use single-threaded JavaScript to perform tasks; business logic, layout, reflows, and garbage collection. This means complex and heavy JavaScript functions can block the main thread from rendering.

Introduction Outline Accessing paint metrics from JavaScript Reporting paint timing metrics to a server Viewing paint metrics in the Chrome DevTools Browser Implementations Traditionally, front-end performance focused primarily on page load times as an important performance metric.

“Blockchain” is the newest term to enter the tech industry’s buzzword repertoire. Whether a company is processing sub-second banking transactions or transporting artisanal goat cheeses across state lines, it seems as though any company not investigating this technology, the same technology that powers infamous cryptocurrencies like Bitcoin, will surely go the way of the dodo.

A significant amount of work on JavaScript toolkits and frameworks has centered around trying to fix, normalize, and optimize browser implementations. Doing so requires making many assumptions about what the problems are, how our tools will be used by developers, and what we expect of the future.

Functional programming and reactive programming principles are not new to JavaScript, but their adoption has recently become widespread across most modern frameworks and toolkits.

Web applications can be deployed to many environments, including desktops, tablets, and mobile devices. We can even deploy web applications natively using a wrapper such as Apache Cordova to gain access to device features such as GPS, battery, and accelerometer data.

The motivation for Intern 4 is to make it easier to author tests with ES6+ features within tests, with or without transpilation. Want to skim? Here’s the Intern Roadmap which lists our high level status for each Intern release going forward.

Intern already has a wide array of capabilities and today we’re pleased to announce one more: accessibility testing. Thanks to a generous award from Mozilla Open Source Support we’ve created the intern-a11y plugin, which allows users to run accessibility tests on pages or components using Intern.

FullStack is a large London JavaScript conference hosted at the Skills Matter CodeNode. The conference brings together an impressive line-up of speakers and workshops covering five tracks over three full days of festivities. We were invited to speak at FullStack, and also enjoyed many of the other sessions and met many great engineers.

In this installment of our series on building web applications, we look at the SitePen approach to solving challenges in web application development. We employ all of the solutions described in part 2 of the blog series. Additionally, we have some overarching principles we apply to our work.

While there are many challenges today with building web applications, there are also many options to address the issues we face with technology, process, and people, allowing us to reap the benefits of the web as an application platform.

Web applications provide many benefits. Most organizations seek to improve the efficiency and effectiveness of business processes through the use of software. The benefits of web applications include: Simple distribution model for end users (e.g. no installation required) Instant propagation of changes Unified code base to support many platforms (desktop, tablet, mobile, etc.

The V8 team (the JavaScript engine that powers Chrome, Opera, Node.js, MongoDB, etc…) are moving forward with an experiment in defining a stronger version of JavaScript that ensures that code being run is behaving well, and introducing run-time typing based on TypeScript’s typings.

Dijit and dgrid provide a powerful set of user interface components, allowing for fast construction of sophisticated web applications with excellent performance and interactivity. However, one particular configuration of dgrid that can impact memory and performance: heavy use of persistent Dijit editors within grid cells.

When writing object-oriented source code, you generally only want to expose a very specific API to whomever is using it. In many languages you would control this by marking methods and properties you do not want other developers to use as private.

Performance is a critical part of most applications. Research continually shows that good performance is essential for a good user experience. Reasonable load times, smooth animations, and responsive interaction gives user a sense of interaction and immersion, whereas slow load times frustrate users, and choppy animation and interaction quickly makes an experience awkward and disconcerting.

In October, 2014, I was coerced invited to deliver a talk at the first FullStack conference in London, a conference focused on Node.js, JavaScript and hackable electronics. The conference was an interesting cross-section of all things related to JavaScript.

At SitePen, we have long been advocates for building web applications on a RESTful architecture. Over the last several years, it has been exciting to see organizations increasingly provide RESTful endpoints for the Dojo-based front-ends that we support and develop.

Modern browsers have powerful new database capabilities that enable applications to store data locally, and perform advanced indexed queries without a network connection. Applications can be built with offline support without any disruption to data interaction, including searching.

As part of our great updates to the Dojo Tutorials for Dojo 1.8, we’ve been busy creating several new tutorials. Feature Detection and Device Optimized Builds Dojo 1.7+ now uses the popular has() pattern for feature detection in combination with a has()-aware build system.

In our recent post on dgrid and Dojo Nano, we showed a technique of using nested require statements in order to make use of optimized layers using the Dojo build system. As a refresher, a layer is Dojo’s terminology for a file that combines many JavaScript resources into a single file.

Dojo 1.7 added full support for asynchronous module loading, defined with the widely adopted asynchronous module definition (AMD) format. The new module loader and module format offer faster module loading, better performance, and wide interoperability.

We have been providing JavaScript and Dojo support to freelancers, start-ups and Fortune 500 companies for nearly a decade.

You may have seen our recent blog entitled “AMD: The Definitive Source” which exhaustively explained Asynchronous Module Definition. AMD is a topic with significant technical nuances but the purpose of THIS article is to explain the value of AMD for your business.

So what is AMD? As web applications continue to grow more advanced and more heavily rely on JavaScript, there has been a growing movement towards using modules to organize code and dependencies. Modules give us a way to make clearly distinguished components and interfaces that can easily be loaded and connected to dependencies.

You’ve likely read that the new dgrid can be as small as 32KB gzipped when including just its minimal dependencies. However, if you use the standard settings for the Dojo Web Builder or a standard Dojo build profile, you end up with a build that’s closer to 100KB gzipped.

Dojo provides a feature-rich system for including JavaScript modules. Before we begin this journey to explore this concept in depth, you should know that absolutely no knowledge of the Dojo module, packaging, and build system are required to use Dojo.

Dojo 1.4 sports a fantastic tree widget, complete with ARIA compliance, keyboard accessibility, and internationalization (including right-to-left layout for appropriate countries and languages). For large tree data sets, we want to be able to only load the necessary data for the visible nodes of the tree.

This article introduces dojo.cache and presents a technique for externalizing your widget templates in swappable configuration files, where they can be referenced by a custom templateKey widget property. Introducing dojo.cache Dojo 1.4 adds a new core utility called dojo.cache. To appreciate it we first have to review how Dijit’s templatePath works.

Recently, a number of performance tests have been released that are based on the performance of the top 100 web sites such as SpriteMe savings, the IE8 100 top sites test results, or the JSMeter research.

Google today announced Chrome Frame, a plug-in that selectively upgrades Internet Explorer without breaking existing sites. Think of it as working like Flash, but for open web technologies, replacing Internet Explorer’s entire rendering engine for sites that include a single meta tag indicating that they would prefer to use Chrome Frame rather than IE.

New to Dojo 1.2+ is dojox.html.style. This is a collection of methods which give you the ability to query the stylesheets collection in a document, add and remove rules, and dynamically create new sheets.

In the middle of May, we were given a mission: create a speedy, offline API documentation viewer and a graphical Dojo build tool. Here we are at the beginning of July, and the result is the Dojo Toolbox 1.0. This article is a first look at this new application.

I was doing some research on script loading speed tests. Each script load required the page to be refreshed, making it difficult to log the time to Firebug and get an average.

Recently I was writing a “tips and tricks” blog post that was going to focus on the idea that it is better to use an object as a “string buffer”; the idea was that by passing this object around to various functions and pushing string fragments into it, you can get better performance from a

Today, I was eating lunch alone at a restaurant and reading some news via my iPhone’s EDGE connection. Suddenly, Surfin’ Safari – Blog Archive » Optimizing Page Loading in the Web Browser made even more sense. Apple has been putting actual dollars into making Safari and the underlying open source WebKit really, really fast.

Mobile application development has many challenges. The announcement of Google Gears on Mobile Devices will help solve the problems of network connectivity, network latency, and limited bandwidth. On the desktop, a lot of the focus on Gears was its ability to allow applications to function when your computer was not connected to the network.

This past Friday, we pushed Dojo 0.9 Milestone Release 2 out of the nest. This is the last milestone before Beta and the system is starting to take a recognizable shape. Only thinner. Here’s what’s new and awesome in M2: Dijit has landed! Holy cow is it fast. Stay tuned for themes and more widgets.

Hello, Writing RPM packages seems to intimidate some, but it can be easier than you might guess.

Dylan’s last post on performance is only one in a series we’ll be running on the topic, and as promised this post is all about the tools of the trade for doing Ajax app performance tuning and how to use them.