Over the years, Xebia has been the driver of Agile software development at Intergamma, known for the GAMMA and KARWEI DIY stores. A year ago, we set out to replace the checkout process for their webshops. The existing checkout was slow and cumbersome to use, and no longer on par with other parts of the website. We knew there was a lot of room for improvement. In order to justify the investment we needed measurable results quickly. Within a year, we’re consistently seeing a significant conversion rate improvement.

Before starting out to replace the checkout, we discussed the technology stack and general approach. We had prior experience with React and Next.js, but decided against Next.js because of the complexity it adds. A checkout app also doesn’t need to be indexed by search engines, which is why you’d otherwise want to use Next.js. We decided to stick with a standard React setup, which enables us to focus and keep things simple. In order to measure our success, we set up A/B testing to directly compare the old and new checkout running in parallel.

Read more →

In the world of e-commerce, customers are becoming increasingly mobile. In The Netherlands, 50% of consumers is shopping on their mobile phone. Among those under 35 years of age mobile purchases is at 65%. Numbers for searching and browsing for a potential purchase is over 70% overall. Converting these visitors into customers is a delicate task. Consumers are still hesitant to make mobile purchases. The challenge lies in optimizing the mobile user experience. Luckily we can use new web technologies to deliver a stellar user experience with instant page transitions. Nowadays we can offer our customers an e-commerce experience that will not alienate or drive them away, but one that they will love.

Read more on Medium →

With over 200k packages, npm is the world’s largest registry of open source packages. It serves several million downloads each month. The popularity of npm is a direct result of the popularity of JavaScript. Originally npm was the package manager for Node.js, the server-side JavaScript runtime. Since Node.js developers mostly follow the Unix philosophy, the npm registry contains many very small libraries tailored to a specific purpose. Since the introduction of Browserify, many of these libraries suddenly became suitable for use in the web browser. It has made npm not only the package manager for Node.js, but for the entire JavaScript ecosystem. This is why npm is not an abbreviation of Node Package Manager, but a recursive bacronymic abbreviation for “npm is not an acronym”. Wow.

If you do any serious JavaScript development, you cannot go without libraries, so npm is an indispensable resource. Any project of meaningful size is quickly going to rely on several dozen libraries. Considering that these libraries often have a handful of dependencies of their own, your application indirectly depends on hundreds of packages. Most of the time this works out quite well, but sometimes things aren’t that great. It turns out that keeping all of these dependencies up to date can be quite a challenge. Even if you frequently check your dependencies for updates, there’s no guarantee that your dependencies’ authors will do the same. With the pace at which new JavaScript packages are being released, it’s close to impossible to keep everything up to date at all times.

Read more →

This post is part of a series of ES2015 posts. We’ll be covering new JavaScript functionality every week!

Most of the software we work with at Xebia is open source. Our primary expertise is in open source technology, which ranges our entire application stack. We don’t just consume open source projects, we also contribute back to them and occasionally release some of our own. Releasing an open source project doesn’t just mean making the GitHub repository public. If you want your project to be used, it should be easy to consume. For JavaScript this means publishing it to npm, the package manager for JavaScript code.

Nowadays we write our JavaScript code using the ES6 syntax. We can do this because we’re using Babel to compile it down to ES5 before we run it. When you’re publishing the code to npm however you can’t expect your package consumers to use Babel. In fact if you’re using the Require Hook, it excludes anything under node_modules by default and thus will not attempt to compile that code.

Read more →

Ever since Spike Brehm of Airbnb popularized the term Isomorphic JavaScript people have been confused about what exactly it means to have an Isomorphic JavaScript application and what it takes to build one. From the beginning there were people opposing the term, suggesting alternatives such as monomorphic or polymorphic, whatever that all means. Eventually Michael Jackson (the React guy) suggested the term Universal JavaScript and most people seem to prefer it and proclaim “Isomorphic” to be dead.

To reopen the discussion, JavaScript guru Dr. Axel Rauschmayer recently asked the question: Is Isomorphic JavaScript a good term? I’ve already left a comment explaining my view of things, but I’d like to explain a little more. I used make the distinction between Functional Isomorphism and Technical Isomorphism. In my talk at XebiCon I explained the difference. Having the server render the HTML on first page load is the functional part, the thing that provides for a better user experience. The technical part is where we use the same code in both environments, which no user ever asked for, but makes a developer’s life easier (at least in theory).

Continue reading at Medium.com