Skip to content

The State of Webpack

Webpack is a module bundler that allows you to write modules that is then compiled to work in browsers. In recent months, many developers in the JavaScript community have been adopting Webpack as the defacto module bundler for their projects. Some prominent projects that use Webpack are Angular’s Angular-CLI and React’s Create-React-App.

Sean Larkin from the Webpack core team gives us an update on the state of Webpack at This.JavaScript.

#The Webpack Community Webpack 2 was released a few months ago. The primary emphasis on the recent release was the documentation. The extensive community involvement with Webpack 2 called for more support for the contributors. These resources can be found at webpack.js.org.

In addition to documentation, the release of Webpack 2 brought about brand revitalization. Previous to this iteration of Webpack, there was no core team or medium. Now, customers and supporters can read about some tips and tricks or partner articles on medium.

#Recent Activities in Webpack Webpack recently joined Open Collective. This gives individuals the opportunity to become stakeholders and shareholders of the product. Since joining, an estimated budget of $83k/year was made through the support of sponsors and backers. With these funds, the webpack team has been able to facilitate a better open source platform.

Webpack has great hopes for the future of the open source community and the tools that will result of such collaboration. Unlike many other platforms, Webpack is not sponsored by a specific company or framework, meaning that the tools created by the community are centered entirely around the needs of the user.

#Growth and Scale Webpack has grown significantly since its commencement, beginning with 500k monthly downloads in April 2016, and presently, with more than 5 million monthly downloads.

Due to the expansion of the community and contributions, a newer and richer Webpack ecosystem now exists. What was once thought of as a black box tool, is currently a product that contains better triage and acceptance of contributions from people in the community.

New repositories added to the organization include Webpack-contrib, Webpack-cli and Webpack-canary.

All loaders and plugins were moved from the initial webpack organization to a separate organizing tool called Webpack-contrib. This repo promotes a common a set of standards across the board that would apply to every loader and plugin.

Although there is already a Webpack-cli, this recent version helps reduce the work and complexity involved with setting up webpack. The purpose of the improvements was to make it easier to migrate through break changes (while still being able to apply best practices), and have quick and easy setups that would allow for customization.

There is also a migration feature for going from Webpack 1 to 2, as well as an entire add-on system so that library authors can have their own stamp of approval. For details, you can visit webpack.webpack.cli

#What’s in progress for 2017? Webpack ranks the most sought after improvements in the community through a voting system (found at webpack.js.org/vote). The top features to look forward to this year are: -roll-up style hoisting -better tree shaking -hard cache Webpack plugin and native implementation -general typescript integration and support (i.e compilation, speed, etc.) -Working with different browsers

Webpack has been collaborating with Firefox regarding web assembly integration. The proposal aims to make web assembly a first class module type in webpack. This adjustment would eliminate the worries developers may have about shared memory buffers or compiling to web assembly module. The two-part step process proposed states that developers should be able to directly import any language capable of compiling web assembly, then pass it through a loader and have it return to the web assembly module, so that it could be used like Javascript.this should allow for the for the adoption of web assembly to sky-rocket as well as increase accessibility to developers that may not be able to use it in the state that it is today. The initial proposal can be found at http://bit.ly/2oubZqF.

If you are interested in using Webpack 2 or becoming a sponsor, visit opencollective.com/webpack.

To keep up to date with what is happening with Webpack or if you have any questions, contact Sean Larkin on Twitter @TheLarkInn.

By Trinh Kien & Necoline Hubner

This Dot Labs is a development consultancy that is trusted by top industry companies, including Stripe, Xero, Wikimedia, Docusign, and Twilio. This Dot takes a hands-on approach by providing tailored development strategies to help you approach your most pressing challenges with clarity and confidence. Whether it's bridging the gap between business and technology or modernizing legacy systems, you’ll find a breadth of experience and knowledge you need. Check out how This Dot Labs can empower your tech journey.

You might also like

State of Headless CMS Wrap-up cover image

State of Headless CMS Wrap-up

We recently hosted State of Headless CMS where we were joined by some very talented people to talk about a growing ecosystem. There are a lot of problems that a headless CMS can solve when it comes to indie development, and even small restaurants and shops. Before we dive into the key points of the event, I'll give you a brief introduction to the hosts and panelists. Hosts - Jesse @jtomchak - Keionne @KeionneD Panelists - Kapehe - Senior DevRel, sanity.io - @kapeheok - Daniel Madalitso Phiri - DevRel, Strapi - @malgamves - Samuel Snopko - Head of Developer Relations, Storyblok - @samuelsnopko - Stefan Judis - Dev Rel, Contentful - @stefanjudis - Arisa Fukuzaki - Dev Rel Engineer, Storyblok - @arisadev There were a lot of great discussions during this event which is why I want to suggest that you head on over and watch The State of Headless CMS on Youtube to hear all of the great discussions. Who is a headless CMS for? Headless CMSs give developers the ability to use a CMS without being restricted to using the CMS platform itself. It's like using Wordpress, without having to actually use Wordpress itself. This enables developers to build more customized solutions for their clients. Some questions to ponder - What are some Headless CMS technologies that you're excited about? - How do we help the little shop manage their content? - What problems does Headless CMS solve for you? We want to give a huge shout out to our hosts and panelists for participating in the State of Headless CMS event....

3 Web Performance Concepts that Will Help Start a Conversation Around Performance cover image

3 Web Performance Concepts that Will Help Start a Conversation Around Performance

In 2021, This Dot Labs released PerfBuddy, the free online platform for testing web and mobile based sites. With the release of this tool, it was our sincere hope to simplify the conversation around web performance, helping team leaders develop easy to understand metrics that they can use to advocate for further investment into their various web technologies. But we also realize that many new to web development, or who work in software but not as developers, might need more clarification on some of the basic key terms to help them engage more actively in conversations surrounding web development. Below, I’ve defined three of the top terms in web performance to help readers better ascertain your site’s performance, and play an active role in refining their technologies to provide the best experience for their customers. First Contentful Paint Time (FCP) FCP__, or __First Contentful Paint Time__, is a critical metric that measures the time that users must wait in order for a page to load its first visible element. For some sites, this could be the entire page. However, for others, the FCP time might measure the seconds between a user navigating to a site, and any responsive element, such as a loading bar, appearing in front of them. This is not a measurement of backend nor even frontend script loading speed, but a metric that affords development teams the ability to infer the quality of their site’s initial UX. According to metrics published by Akamai in 2018, sites are liable to lose nearly half of their visitors if their page takes more than three seconds to load. In fact, just a single second of load time delay can result in a 7% decrease in sales conversions for eCommerce platforms. This is especially true when considering mobile users, whose likelihood of leaving a page increases 90% when made to wait 5 seconds for a page to load And as more eCommerce shoppers turn to using their mobile devices- with 53% of users accessing shopping sites via mobile platforms on 2019’s Cyber Monday, representing a 40% YOY increase- teams need to be acutely aware of their cross platform performance with respect to FCP. Time to First Byte (TTFB) Not to be confused with FCP, TTFB, or Time to First Byte, refers to the amount of time that the browser waits in order to receive initial data from its server. In order for a site to display any information, a browser must make dozens, if not more, data requests. Issues related either to the quality of the host, site functionality, or complexity can all contribute to a site’s latency, or the amount of time it takes for data to be passed between the server and the browser. Of course, reducing site latency will improve user experience by decreasing FCP, and generally increasing browsing speed. However, ensuring low TTFB will also boost your SEO by making your site more quickly crawlable by leading search engines. Page Weight As developers add features and functionality to support more advanced user experience, web pages get heavier. As of 2020, the average desktop webpage weighs 2080 KB, up from an average of 1532 KB in 2017, with the weight of mobile web pages slightly lower, but still seeing a near 40% increase in size when compared to stats from just four years ago. eCommerce websites need to maintain acute awareness of their page weight, and ensure that their latency is not overly impacted by it, due to the tendency for shopping sites to be especially complex, supporting large catalogs of products along with other features to promote customer engagement. And as this era of advanced digital transformation continues to expand, eCommerce sites must develop strategies to meet market expectations for performance without over burdening their sites with heavy plugins and functionalities. Finding Your Path to Performance It starts with equipping yourself with the right tools to test your site’s speed and weight. There are countless platforms used for testing sites, however, there are only a handful that are capable of unlocking the insight that you need to support your most critical websites. Though PerfBuddy is a great place to start in order to identify potential roadblocks, it cannot do the work of actually improving site performance. By leveraging testing platforms such as Lighthouse, and continuously improving your performance metrics with assets such as DevTools, and strategies like Google’s PRPL, eCommerce retailers can ensure that their sites meet user expectations and promote their most critical business objectives. Need help? Contact This Dot Labs to learn more about how developing the tools and strategies to ensure optimal site performance can support scalable growth as you continue refining user experience!...

I Broke My Hand So You Don't Have To (First-Hand Accessibility Insights) cover image

I Broke My Hand So You Don't Have To (First-Hand Accessibility Insights)

We take accessibility quite seriously here at This Dot because we know it's important. Still, throughout my career, I've seen many projects where accessibility was brushed aside for reasons like "our users don't really use keyboard shortcuts" or "we need to ship fast; we can add accessibility later." The truth is, that "later" often means "never." And it turns out, anyone could break their hand, like I did. I broke my dominant hand and spent four weeks in a cast, effectively rendering it useless and forcing me to work left-handed. I must thus apologize for the misleading title; this post should more accurately be dubbed "second-hand" accessibility insights. The Perspective of a Developer Firstly, it's not the end of the world. I adapted quickly to my temporary disability, which was, for the most part, a minor inconvenience. I had to type with one hand, obviously slower than my usual pace, but isn't a significant part of a software engineer's work focused on thinking? Here's what I did and learned: - I moved my mouse to the left and started using it with my left hand. I adapted quickly, but the experience wasn't as smooth as using my right hand. I could perform most tasks, but I needed to be more careful and precise. - Many actions require holding a key while pressing a mouse button (e.g., visiting links from the IDE), which is hard to do with one hand. - This led me to explore trackpad options. Apart from the Apple Magic Trackpad, choices were limited. As a Windows user (I know, sorry), that wasn't an option for me. I settled for a cheap trackpad from Amazon. A lot of tasks became easier; however, the trackpad eventually malfunctioned, sending me back to the mouse. - I don't know a lot of IDE shortcuts. I realized how much I've been relying on a mouse for my work, subconsciously refusing to learn new keyboard shortcuts (I'll be returning my senior engineer license shortly). So I learned a few new ones, which is good, I guess. - Some keyboard shortcuts are hard to press with one hand. If you find yourself in a similar situation, you may need to remap some of them. - Copilot became my best friend, saving me from a lot of slow typing, although I did have to correct and rewrite many of its suggestions. The Perspective of a User As a developer, I was able to get by and figure things out to be able to work effectively. As a user, however, I got to experience the other side of the coin and really feel the accessibility (or lack thereof) on the web. Here are a few insights I gained: - A lot of websites apparently tried_ to implement keyboard navigation, but failed miserably. For example, a big e-commerce website I tried to use to shop for the aforementioned trackpad seemed to work fine with keyboard navigation at first, but once I focused on the search field, I found myself unable to tab out from it. When you make the effort to implement keyboard navigation, please make sure it works properly and it doesn't get broken with new changes. I wholeheartedly recommend having e2e tests (e.g. with Playwright) that verify the keyboard navigation works as expected. - A few websites and web apps I tried to use were completely unusable with the keyboard and were designed to be used with a mouse only. - Some sites had elaborate keyboard navigation, with custom keyboard shortcuts for different functionality. That took some time to figure out, and I reckon it's not as intuitive as the designers thought it would be. Once a user learns the shortcuts, however, it could make their life easier, I suppose. - A lot of interactive elements are much smaller than they should be, making it hard to accurately click on them with your weaker hand. Designers, I beg you, please make your buttons bigger. I once worked on an application that had a "gloves mode" for environments where the operators would be using gloves, and I feel like maybe the size we went with for the "gloves mode" should be the standard everywhere, especially as screens get bigger and bigger. - Misclicking is easy, especially using your weaker hand. Be it a mouse click or just hitting an Enter key on accident. Kudos to all the developers who thought about this and implemented a confirmation dialog or other safety measures to prevent users from accidentally deleting or posting something. I've however encountered a few apps that didn't have any of these, and those made me a bit anxious, to be honest. If this is something you haven't thought about when developing an app, please start doing so, you might save someone a lot of trouble. Some Second-Hand Insights I was only a little bit impaired by being temporarily one-handed and it was honestly a big pain. In this post, I've focused on my anecdotal experience as a developer and a user, covering mostly keyboard navigation and mouse usage. I can only imagine how frustrating it must be for visually impaired users, or users with other disabilities, to use the web. I must confess I haven't always been treating accessibility as a priority, but I've certainly learned my lesson. I will try to make sure all the apps I work on are accessible and inclusive, and I will try to test not only the keyboard navigation, ARIA attributes, and other accessibility features, but also the overall experience of using the app with a screen reader. I hope this post will at least plant a little seed in your head that makes you think about what it feels like to be disabled and what would the experience of a disabled person be like using the app you're working on. Conclusion: The Humbling Realities of Accessibility The past few weeks have been an eye-opening journey for me into the world of accessibility, exposing its importance not just in theory but in palpable, daily experiences. My short-term impairment allowed me to peek into a life where simple tasks aren't so simple, and convenient shortcuts are a maze of complications. It has been a humbling experience, but also an illuminating one. As developers and designers, we often get caught in the rush to innovate and to ship, leaving behind essential elements that make technology inclusive and humane. While my temporary disability was an inconvenience, it's permanent for many others. A broken hand made me realize how broken our approach towards accessibility often is. The key takeaway here isn't just a list of accessibility tips; it's an earnest appeal to empathize with your end-users. "Designing for all" is not a checkbox to tick off before a product launch; it's an ongoing commitment to the understanding that everyone interacts with technology differently. When being empathetic and sincerely thinking about accessibility, you never know whose life you could be making easier. After all, disability isn't a special condition; it's a part of the human condition. And if you still think "Our users don't really use keyboard shortcuts" or "We can add accessibility later," remember that you're not just failing a compliance checklist, you're failing real people....