Originally shared by Ramin Honary

John Hardy Turnbull delenda est’s prediction about a bunch of “shitty” compilers targeting WebAssembly is already turning out to be correct. Here is a project (although I feel bad calling them “shitty,” they’re working hard on it) trying to port musl libc to WebAssembly, with the goal of then using Clang to compile LLVM bytecode to WebAssembly statically linking musl libc to power the Haskell Runtime System (RTS). Since GHC Haskell alreaedy targets LLVM, this would mean any Haskell program will run in the browser, complete with optimizations. Whether the WebAssembly+musl libc emitted by Clang will be well optimized to run on a browser is another question entirely, but almost certainly the answer is “no,” it won’t be well optimized, hence “shitty,” though not bad at all for an experimental project.

https://github.com/WebGHC/musl

Agreed. When there are two ways of doing something that’s one way too many.

Plus there are maintainability headaches associated with default exports.

https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad

Originally shared by mathew murphy

Unit testing seems to correlate with increased cyclomatic complexity, and other surprises.

https://blog.ndepend.com/unit-testing-affect-codebases/

A typical Angular app is a veritable sea of Singletons ie. Stateful Services.

Sometimes it feels as if the Angular team decided to collect together all the world’s worst programming patterns and a put them into one convenient framework.

Originally shared by mathew murphy

Many people have expressed the opinion that singletons are a code smell. Now someone has looked at codebases to quantify to what extent that’s true.

https://blog.ndepend.com/singleton-design-pattern-impact-quantified/

I seriously don’t have a dog in this fight. Some people really despise NodeJS as a production level server. I’m interested to know why.

I mean Node runs a scripting language like Ruby or PHP but is superior in performance to those systems because of its non-blocking architecture. Naturally being interpreted it can’t be as fast as a compiled language such as Go or Java.

So this is an open thread asking why you wouldn’t use it in production? Note that “because it’s JavaScript” is not an argument that is going to carry any water around here. JavaScript performance from the point of view of an interpreted language is already pretty good relative your favourite scripting language X so let’s get down non-bullshit arguments about why it’s bad.

https://medium.com/javascript-scene/introduction-to-node-express-90c431f9e6fd

Functional programming in Node using monads and the Fantasyland specification.

https://www.humblespark.com/blog/extensible-effects-in-node-part-1

A pretty good summary of js front-end framework performance. Preact pretty much still rules.

Eric Elliott takes a hard line on JavaScript’s “new”, “instanceof” and “class” keywords. In a nutshell, don’t use them.

In their place he suggests object factory functions which still create objects but do it via Object.create().

JavaScript: “the good parts” remains a small subset of the full language.

https://medium.com/javascript-scene/javascript-factory-functions-vs-constructor-functions-vs-classes-2f22ceddf33e