From Spike’s homepage:

Spike is a next-generation static site generator. It is built on top of webpack, and a foundation of html, css, and js parsers that accept plugins to transform the output. It’s fast, actively developed, and very data-friendly.

Read as, new static site generator based on Webpack, Babel, PostCSS, and Reshape. Seems like a toolset I would like.

I’ve never heard of Reshape before. Seems new. Git commit messages say, Aug 9, 2016 was first commit.

A free, once–weekly e-mail round-up of JavaScript news and articles.

If JavaScript is your thang, you should subscribe.

Nice collection of free JavaScript books.

This is a summary of Alex Grigoryan’s talk from @WalmartLabs, at Nodevember 2016.

The story of how @WalmartLabs successfully migrated to React and Nodejs with efficiency and speed. At the end of this talk, you should be able to make your own successful strategy to transform your technology stack quickly and successfully.

What does a migration mean?

• FE apps take about 10,000/rps
• 400 engineers
• 2 dozen apps comprise @walmartlabs
• 70% of Walmart.com traffic is on React and Node
• Next year samsclub.com traffic will be on Electrode too

Took less than a year for them to migrate.

Why migrate?

• 50 - 60% walmart users on mobile
• responsiveness here was slow
• productivity of engineers was slowing down (java, handlebars, etc)
• Performance, Productivity, Reusability, Responsiveness
• multiple components being rebuilt
• services are similar, multiple ecommerce sites (react component model helped here)
• Use 500 different React components

How did we start?

• Built the Electrode platform first: http://www.electrode.io/
• Built the platform team first, small, cohesive, and versatile (full stack)
• while simultaneously building organizational alignment - met with leaders, set realistic expectations, talked through concerns
• • anxiousness can spread through organization quickly; talk to leaders thougout the org, and talk through why it’s happening; make sure the business side is onboard and understands why
• with some headway into the platform, we then built the vertical team: senior, bought in, vocal, distributed
• • distributed in terms of organization location
• • this team will be your future ambassadors
• next we united the Platform and Vertical teams
• Now you needed to decide on the first application to migrate: not too simple or complex, not business critical, server side render, bought in
• we chose the ‘collections application’, choose collections of things
• • once we hose collections and started building, there was a constant feedback loop, to refine the platform and process
• • the application went live (about a month)
• • we continually monitored and fine-tuned: performance, conversion, scalability, reusability
• Next Application? Walmart.com Checkout: client-side rendered, complex, single page application, business critical
• Rinse and repeat
• Finally, all the other applications start migrating (search, login, my account, profile pages)
• • This is where the ambassadors Play a Key Role
• • the small team is protected, and you don’t get crushed by requests from the organization; this larger vertical team can help with that (every single team has a person there with deep knowledge of the system)
• currently onboarding Samsclube.com

What are the benefits we’re seeing?

• impact on customer experience:
• • 90% functional automation
• • 40% reduction in bundle size
• • 60% improvement in response time
• impact on developer productivity
• • 3x faster from code to production
• • Training days down from 5 days to 1 day
• • First commit from 7 days to 1
• • Improved talent recruiting
• these kinds of things, changes the culture of the company

Electrode Focuses on Three Things - http://www.electrode.io/

• getting you up and running quickly
• making your server side render fast
• enabling you to reuse across multiple applications

How does one get started with Webpack? Well, with the simplest Webpack config evar of course. Tots.

Here’s how we slay this beast, start by running the following

You need to install webpack first via npm:

1
2
3

mkdir myfirstwebpackproject && cd myfirstwebpackproject;
npm init -y;
npm install webpack;

Ok, simplest webpack config, one entrypoint, one output:

1
2
3
4
5
6
7
8

//webpack.config.js file
module.exports = {
    entry: "./entry.js",
    output: {
        path: __dirname,
        filename: "bundle.js"
    }
};

1
2

//entry.js
document.write("It works.");

1
2
3
4
5
6
7
8
9
10

/* Your index.html that you include your bundle.js file with */
<html>
    <head>
        <meta charset="utf-8">
        <title>ZOMG Webpack <3</title>
    </head>
    <body>
        <script type="text/javascript" src="bundle.js" charset="utf-8"></script>
    </body>
</html>

Creator Una Kravets says You Might Not Need JavaScript:

JavaScript is great, and by all means use it, while also being aware that you can build so many functional UI components without the additional dependancy.

Some good examples of doing things you thought you need JavaScript to do. I love sites like this. Code examples, zomg.

From Preactjs.com’s site:

Preact is an attempt to recreate the core value proposition of React … using as little code as possible, with first-class support for ES2015. Currently the library is around 3kb (minified & gzipped).

So you get a React-like developer API experience in 3kb of JavaScript — That is insane.

At the time of this writing Preact has 4,000+ stars on github. Checkout Jason, the creator of Preact, talking about the origins of it on the React30 podcast episode. If you like React, then you should definitely give Preact a go in your next project.

Webpack takes things and turns them into other things. The ‘input’ is the ‘entrypoints’. If you can remember in the graphic of Webpack where it shows modules going into the front, and then compiled assets coming out the other side of Webpack, the modules going in, are the ‘entrypoints’.

That’s all those are, just your JavaScript modules that are going to be processed by Webpack.

Your entrypoints can just be one, as shown as ‘entry.js’ on the getting started page, or they can be many, as shown here:

1
2
3
4

entry: {
	pageA: "./pageA",
	pageB: "./pageB"
},

via multiple entrypoints example | see the docs

I hope that helps explain what entrypoints are in Webpack, and how they’re used in configuration. They’re the starting point for loading your code through Webpack!

From the new electrode.io site from the folks at @WalmartLabs:

UNIVERSAL REACT/NODE APPLICATION PLATFORM

Electrode is a platform for building universal React/Node.js applications with standardized structure, best practices, and modern technologies baked in. Electrode focuses on performance, component reusability, and simple deployment to multiple cloud providers—so you can focus on what makes your app unique.

From the name, I at first thought this was an Electron platform. But it’s actually a server/client platform built on React and Node.

Interestingly, some of the magic is a custom Wepback loader:

A webpack loader, plugin and library to make NodeJS require work with complex files like images when we are doing server-side rendering.

Also a custom Wepback bundle analyzer.

Interesting to see Webpack at the core of their platform, which is something I agree with, obviously.

David Gilbertson on the hackernoon publication on medium has a great write up of some chrome devtools tips that I really like.

Checkout number eight on the page:

1. Edit any text on the page
   So, you have a fixed width menu and you want to know if longer text will wrap with any level of grace. Drop that doc into design mode!

Drop this in your console

1

document.designMode = "on"

And then you can freeform edit anything on the page. (Refresh the page, to get out of that mode.)

I didn’t know about that one. That is fancy.