Disqus - Latest Comments for developit

Re: ESP32 Development board-WT32-SC01

developit — Mon, 19 Apr 2021 16:29:23 -0000

There is an english manual now:
http://www.wireless-tag.com...

Re: Real sleep() in JavaScript

developit — Tue, 02 Mar 2021 18:59:44 -0000

No - that yields to the event loop for 5000ms. It "pauses" the calling function only, allowing any other code to run (timers, other promises, etc). It also only works for async functions.

To clarify: 99.9% of the time async/await is exactly what you want. This blog post is about implementing global deadlocks in JS - not something you'd ever do in an application, but a low-level technique that can be used to pause Web Workers.

Re: Modern Script Loading

developit — Tue, 18 Aug 2020 12:33:54 -0000

If you're loading scripts for client side navigation, you can use any mechanism you want to test for modernness. To use module/nomodule, just check for `'noModule' in script`.

Re: Rome, a new JavaScript Toolchain

developit — Fri, 28 Feb 2020 17:30:44 -0000

Not like a boilerplate, no. Boilerplates are an awful way to consume tools. When you start with a boilerplate, 100% of the code becomes yours to maintain - you never get updates or improvements, and you're stuck with those decisions forever.

I would say a closer comparison might be to something like Angular CLI, except Rome is an entirely new tool rather than an amalgamation of existing tools.

Re: Rome, a new JavaScript Toolchain

developit — Fri, 28 Feb 2020 14:51:28 -0000

It's a from-scratch implementation, and does much more than a bundler does. You can think of Rome as a single tool that does what (Webpack+ESLint+TypeScript+Babel+Jest+Prettier) do.

Re: Evaluating JavaScript code via import()

developit — Fri, 04 Oct 2019 17:26:51 -0000

Just a note - it's better to use a Blob URL for this, to avoid the Base64 conversion. It may also help with bytecode caching (can't confirm).

Re: Enabling Modern JavaScript on npm

developit — Tue, 03 Sep 2019 23:11:44 -0000

I think this could potentially work, except many bundlers either don't transpile node_modules, or treat package.browser as a hint that code is already transpiled for (legacy) browser support.

Re: Modern Script Loading

developit — Mon, 15 Jul 2019 09:05:57 -0000

I'm working on a whole post about this! Modules are supported in a bunch of browsers that have varying degrees of roughly ES2017 support: Edge 16, Firefox 60, Chrome 61 and Safari 10.3. This means you still need to transpile very new syntax (class fields and property initializers).

Re: Modern Script Loading

developit — Mon, 15 Jul 2019 09:03:22 -0000

Solutions like shimport don't transform new syntax for older browsers, they just polyfill ES Modules via eval. Shimport is great, but it's not a way to load modern syntax in old browsers.

Re: Modern Script Loading

developit — Mon, 15 Jul 2019 09:01:45 -0000

Preloading via <link rel="preload" href=".." as="script" crossorigin="">.

Re: Modern Script Loading

developit — Mon, 15 Jul 2019 09:00:57 -0000

@Wout Mertens Preloading has to be done using static HTML in order to be effective, since the preload scanner only looks at the HTML as it is being tokenized.

Re: Modern Script Loading

developit — Thu, 11 Jul 2019 16:38:21 -0000

The problem is that Service Workers aren't there to rewrite requests on first load.

Re: Enabling Modern JavaScript on npm

developit — Tue, 11 Jun 2019 14:47:42 -0000

I'd like to keep conjecture and personal attacks out of this discussion if possible.

Sindre is in a position to effect widespread change on npm package consumption, and as the most prolific author on npm that's his decision to make. Consider the opposite of the complaints lobbied here: if you were using a bundler or technique that only supported ES Modules, you could argue that Sindre not updating his packages is equally frustrating. Ultimately, he has the same goal I and many others do: moving the ecosystem past a difficult blockade so it can continue to grow.

His point of leverage is the thousands of modules he maintains. Nobody has stepped up to help him make this push in a way that works for both maintainer and consumer, and eventually packages need to be moved forward. I know this because I have personally offered to do so, but so far I have failed to deliver. It's exceptionally time-consuming to maintain so many packages even without the added overhead of complex or slow build steps for every publish. It also makes testing slower and more difficult, since both the original and transpiled source must be tested in order to ensure packages don't break in one format but not another (I've personally had this happen and now test built files as I do source).

Regarding ads: remember that Open Source is not the same as free. Sindre's output is sustainable only because he works full-time on Open Source, and he is only able to do so through sponsorship. He makes it work, but maintenance at that scale is not a burden I would wish on anyone.

Re: Enabling Modern JavaScript on npm

developit — Fri, 31 May 2019 10:49:38 -0000

My guess is that detection will prove extremely difficult and error prone, however I'm super interested in collaborating if you're open to it!

Re: UMD is Dead! Long Live UMD!

developit — Fri, 15 Feb 2019 21:16:21 -0000

Not sure I follow your second point. FWIW this post is about library build target formats, not application code.

I do agree this post is miopic though, and we've since added a dedicated UMD bundle to Preact (about which this was originally written). We still ship ES Modules and CJS/globals by default though. Most folks using UMD directly are copying modules out of node_modules and that process requires a filename anyway. I've been in the habit of adding a `"umd:main"` field to packages, and Microbundle has always done this by default. That seems like the right compromise to make: ship UMD, but don't point to it as the default.

Re: Application Holotypes: A Guide to Architecture Decisions

developit — Fri, 15 Feb 2019 12:38:23 -0000

Think that represents a single grouping? I am tempted to add Salesforce as a holotype, but it's actually more of a platform for building types of apps.

Re: Color Cycling with Workers

developit — Mon, 10 Sep 2018 13:42:54 -0000

Two things I notice that seem like they could be low-hanging optimization fruit here:

1. what about only passing the imageData object into the Worker once? The worker sends it back to the main thread, so it knows the pixel values that will be passed down on the next iteration of its loop.
2. Passing the ImageData as a Transferrable here would likely result in a considerable speedup.

Re: Universal VDOM Components with factory-loader

developit — Sat, 25 Mar 2017 16:10:41 -0000

Ah - I totally could have made it clearer, but this doesn't require Webpack at all. You can always just import the factory and call it yourself. Webpack just makes that part automatic. Still, you're right in a sense - the adoption depending on Webpack to make things easy is not great.

Re: Props Down, Events Up

developit — Mon, 13 Mar 2017 18:04:56 -0000

Yup, it's just decko. You can declare those methods/properties however you like though:


// using class property initializer methods:
class Child extends Component {  
  handleInput = (e) => {
    let text = e.target.value;
    this.props.onInput({ text });
  };
  render({ text }) {
    return <input value="{text}" oninput="{this.handleInput}"/>;
  }
}

// or bind in the constructor:
class Child extends Component {
  constructor(props, context) {
    super(props, context);
    this.handleInput = this.handleInput.bind(this);
  }
  handleInput(e) {
    let text = e.target.value;
    this.props.onInput({ text });
  }
  render({ text }) {
    return <input value="{text}" oninput="{this.handleInput}"/>;
  }
}

Personally I prefer Decko because it performs better than the alternatives, but class property initializer methods are actually what I end up using most of the time because there's no library needed.

Re: Fun hacks for faster content

developit — Tue, 06 Dec 2016 09:56:51 -0000

Perhaps something to do with streaming being more tolerant of packet loss or something? They would delay fully buffered content, but only affect yet-to-be-streamed content.

Re: Converting a Node List to an Array – JS Tips – A JS tip per day!

developit — Fri, 25 Nov 2016 13:21:24 -0000

Is that with Babel transpiling turned on?

Re: Hidden Class - JS MythBusters_

developit — Thu, 13 Oct 2016 10:37:35 -0000

It's worth noting, instantiating a class and assigning properties in a constructor is now slower than a factory method that returns plain Objects of uniform shape.

Re: My ES2015 + LESS Webpack Setup

developit — Thu, 21 Jul 2016 14:21:06 -0000

Just import your .less files (or an index.less that imports them all) from JavaScript.
For example, you might have this at the top of your src/index.js:


import 'less/index.less';

Re: WTF is JSX

developit — Sun, 10 Apr 2016 22:15:24 -0000

Hmm - concat() is being used to flatten nested arrays. akin to:


concat( ...[ ['a'], ['b','c'] ] ) == ['a','b','c']

Just using the spread would yield [ ['a'], ['b', 'c'] ].

Re: Converting a Node List to an Array – JS Tips – A JS tip per day!

developit — Sat, 06 Feb 2016 18:03:22 -0000

Great post! Might be worth noting that the Array.apply() approach is quite a bit slower than simply looping over keys: http://esbench.com/bench/56...