joepie91

ES Modules are terrible, actually

This post was adapted from an earlier Twitter thread.

It's incredible how many collective developer hours have been wasted on pushing through the turd that is ES Modules (often mistakenly called "ES6 Modules"). Causing a big ecosystem divide and massive tooling support issues, for... well, no reason, really. There are no actual advantages to it. At all.

It looks shiny and new and some libraries use it in their documentation without any explanation, so people assume that it's the new thing that must be used. And then I end up having to explain to them why, unlike CommonJS, it doesn't actually work everywhere yet, and may never do so. For example, you can't import ESM modules from a CommonJS file! (Update: I've released a module that works around this issue.)

And then there's Rollup, which apparently requires ESM to be u

MarcoWorms

function createStore (reducers) {
  var state = reducers()
  const store = {
    dispatch: (action) => {
      state = reducers(state, action) 
    },
    getState: () => {
      return state
    } 
  }

xjamundx

This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.

In that post I talked about 3 main reasons for moving from require.js to webpack:

1. Common JS support
2. NPM support
3. a healthy loader/plugin ecosystem.

Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.

ddlsmurf

# Example with basic types
---
hash:
  string: some text
  number: 12345
  array_of_bool: [on, off, true, false, yes, no]
  ruby symbol: :symbol
  array:
    - item one
    - item two