In the beginning was HTML, and our pages were fast. But they were boring, so we added JavaScript.  JavaScript ended up being so capable that we ended up creating entire applications with it, dynamically creating and destroying DOM interactively to users’ delight.

Introduction Web Vitals scores can have a huge influence on your search engine rankings and directly impact your user’s experience when visiting your website. Follow our guide to automating Web Vitals checks against your Vercel CI Deployment using GitHub Actions and ensure that you don’t introduce performance issues into your code that could affect your search engine ranking.

At SitePen, web application development is the core of what we do. We pride ourselves on our reputation for creating rich web apps that are highly responsive and reliable.

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.

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.

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. Every time the JavaScript language gets challenged, the community strives to create mechanisms to improve performance bottlenecks, which we have seen over the years with efforts from Mozilla, Google, Apple, and Microsoft.

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.

Introduction 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. Commercial web performance dashboards would show granular level performance metrics for back-end aspects, like database lookup times, template compilation, server response times, etc.

“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. The ease of using these approaches has improved as we’ve finally seen the decline of legacy browsers, and as we’ve seen the introduction of functional and reactive paradigms within ES6 and ES8.

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.

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.

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. While many of the challenges with today’s web applications come from the vast array of technologies that are available, there are clear strategies that can be employed to turn those same issues into advantages that can make building applications easier.

Web applications provide many benefits. Most organizations seek to improve the efficiency and effectiveness of business processes through the use of software.

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. V8’s motivation is always performance, and a more stringent set of ECMAScript would obviously allow them to tune the engine to streamline performance, but are there other benefits? Update: Status of the V8 strong mode experiment.

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.

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. 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. As we intently watch enterprise organizations everywhere begin to roll out AMD (read about why AMD matters) and the associated code improvements, we are thrilled with the industry’s direction toward toolkit interoperability! Why? Because! Our masterful engineering team, consisting of influential members of various open source communities, positions SitePen perfectly to offer full-on, front-end web development support to the world! Getting right to the point, (The Official Point!), we are pleased to announce the expansion of SitePen Support to officially include more than fifteen popular open-source JavaScript toolkits! Now supporting the following JavaScript toolkits: Dojo Persevere packages dgrid Curl.js CometD Twine jQuery Backbone underscore RequireJS PhoneGap/Cordova MooTools jQueryUI Wire Socket.IO Express In addition to toolkits, we will continue to support your custom JavaScript source code, as well as key underlying technologies and formats, including JSON, HTML5, WebSockets, SVG/Canvas, Mobile Web, Server-Side JavaScript, AMD, Node.js and many more.

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.

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. Dojo 1.4 adds a new core utility called dojo.cache.

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. These are in direct contrast with tests such as ACID3 which attempt to test the future of the web rather than just what’s possible today.

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.

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 JavaScript engine. My friend and colleague Alex Russell challenged me to show him hard data supporting this hypothesis—and the results were quite eye-opening! For this analysis, I used two sources for tests: the dojox.string.Builder Builder performance test, and a custom test implementing three versions of a common JavaScript task: a JSON Serializer.

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.

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.

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.

Hello, Writing RPM packages seems to intimidate some, but it can be easier than you might guess. Below, I will: point out the online reference RPM documentation describe one method of configuring a build environment outline a simple specfile (sysreport package) describe the process of building the package from the specfile introduce a few convenient RPM macros Here are a few terms: specfile a file containing the rules for building an RPM package RPM the distributable package intended for the target SRPM a special package containing all the source code and the specfile for a given package rpm the command-line program used for installing packages rpmbuild the command-line program used for building packages The best place to get detailed documentation is the Maximum RPM Book, which is a bit old, but has documentation on most RPM building questions.

This post is all about the tools of the trade for doing Ajax app performance tuning and how to use them. Here at SitePen, we often get called into a project when the heat is really on: after most of the code is written and just before the hoped-for (or worse, already slipped) ship date.