Checkout v0.1 - 1.0

aka "Checkout Alpha"

• Adhoc style in Backbone + Backbone.Form
• Originally thought of as a github boilerplate.
• No defined workflow yet
• No defined backend api
• Klarna Core.JS
• TDD using QUnit
• More developers = Faster time to market
• The sky is the limit!!! 

Checkout 2.0

aka "Checkout Beta"

• Completely rewritten in Backbone + NestedModel
• Devserver/Fejkend/Mockplayer
• Depencency handling via AMD / require.js
• Handlebars
• TDD using Mocha
• Concept of widgets
• Modular thinking
• A/B tests
• Themes

Checkout 2.5

aka "Germany Release"

• Multi market
• Totally rewritten CSS layer using SASS/BEM
• Coffee-script for tests
• Grunt
• Rewritten engine/controller
• Experimenting with CasperJS / Integration tests
• New backend = missing KATT-scenarios

Checkout 2.9

aka "Germany Release"

• More markets (squeezed in)
• Fine tuning of every aspect of the application
• Backbone is getting really old.
• "New team"
• Javascript community has exploded.
• IE7 is dead, IE8 is dying....
• Mobile performance is no longer a big issue.
• We know what we wan't to do, and we got data to support the features we need!

Checkout 2.999997

aka "How the hell does this huge application work?"

• Scattered conventions
• Hard to test
• Low productivity
• Low motivation
• Hard to recruit and keep unhappy engineers.
• Proud of the product. Not the code.

Creativity gone bad!

FACTS

• We want to give the consumers a product they need & love.

• We want to make sure the product is as good as we say it is!

• We want to respect the value of deadlines.

HIGH LEVEL ROADMAP

• Enter more markets

• Create new features

• Tweak existing features

• Become more effecient

• Hire more people

• Split teams per market

TIME TO MARKET

What we should be

What we should not be

Checkout 3.0

Or ...."Are you rewriting the checkout again?"

The checkout is not just a javascript driven 

application anymore.

It's a concept!

Klarna Checkout is a toolbox a merchants integrate to the checkout page

"Klarna Checkout is a toolbox that merchants

integrate to their checkout page"

Olov Eriksson

Why do we take frontend and UX so seriusly?

"No regular customer will ever call us and praise our beautiful backend"

Software Architect at large company

A lot of $$$$ is put into this ...

...so let's try to avoid this.

Elevator buttons

...and this...

More buttons

...or this.

Competitor?

"Best practices as a service"

Johan Borestad @ Klarna 2014

Scaling like a boss!

...on EVERY single possible level!

So how will such an amazing solution look like?

First ... a reminder!

SQY PLC 

SQY PLC 

Service minded

We should focus on creating the best

user experience.

In every single way, on every market, at any given time.

SQY PLC 

QUALITY

Produce quality software. Not just today.

Everyday.

All the time!

SQY PLC 

YOU

Solve your own problems.

Take responsibility for creating your own awesome working environment.

SQY PLC 

PLAY AS A TEAM

Create modular software that other team members can understand and use, even if people leave the project.

Use our individual strengths to solve complex problems in different layers.

SQY PLC 

LEARN

Build large applications by building many small applications with their own depencencies.

Care deeply about the the communication layer. Then we can start to reason what framework or language we need.

SQY PLC 

COMMITMENT

Create a feeling of ownership and responsibility.

Maximize creativity and productivity

Large-Scale JavaScript Application Architecture

• Decoupling
• Create modules
  • ​Javascript
  • CSS
  • Assets
• ​Build process
• Shared conventions

All the things we need to solve, part1

• Semver (tricky)
• Github vs Stash
• Private npm
• Package manager
  • npm
  • bower
  • webpack
  • components.io
• Local development
• CSS is global
• Testing with CI
• Streamlined build process

• Coding style
  • CommonJS
  • Require.js
• Compiled dists
  • r.js
  • browserify
  • components.io
  • webpack
• modules vs plugins
  • dependencies
  • peerDependencies

All the things we need to solve, part2

• Bumping of interpreters
  • Ruby
  • Node
  • Sass
  • libsass
  • Coffescript
  • Stylus
  • Less

• Coding style
  • CommonJS
  • Require.js
• Coding guidelines
  • Javascript
  • CSS
  • Assets
  • File structure
  • Testing
  • Cli-Tools

Assumptions are the mother of all f*ckups

Meet "Lilly" - your friendly cli-tool

Stuff that are "in the works"

• npm 2.0
  • Private packages (Early 2015?)
• Lilly (A JavaScript best practices tool)
• OTP
•  

Choosing a package manager

??

ONGOING

Awesome links

• http://blog.npmjs.org/post/100099402720/registry-roadmap#private-packages
• http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging
• https://github.com/webpack/webpack/issues/378
• http://mattdesl.svbtle.com/browserify-vs-webpack
• https://news.ycombinator.com/item?id=8091120
• https://medium.com/@tomchentw/why-webpack-is-awesome-9691044b6b8e