John Slegers

> I chose to rock no dashes because it felt right for a longer term vision of how HTML and frameworks could evolve. We're on the same page here. Unfortunately,...

Being able to write code in LLJS and convert is to asm.js sounds awesome to me. However, with no new submits in 5 years, it looks like LLJS has been...

Those also interested in converting staticly typed variations of JavaScript to asm.js, WebAssembly or C might want to take a look at [ThinScript](https://github.com/evanw/thinscript) or [TurboScript](https://github.com/01alchemist/TurboScript). ThinScript compiles to JavaScript, WebAssembly,...

> To solve this we need to add encapsulated management of the `state` of launcher and log its transitions. > We did this for browser in #3202. I'm not entirely...

I don't really need a custom URL loader for the type of projects I work on per se, and it seems needlessly complicated to me. However, I do need a...

> For example, suppose your package `contains common/balloon/close-icon.png` and `common/balloon/luciad-balloon.scss` with `background-image: url(close-icon.png)`. A user then installs this via npm, so their package contains `node_modules/luciad/common/ballon/close-icon.png` et al. Then they import...

@nex3 : In https://github.com/sass/sass/issues/779 you mentioned that you were planning on deprecating the `@import` feature, which is used in pretty much every Sass implementation of moderate to high complexity. Why...

@nex3 : There's always a reason to maintain compatibility : stopping old code from breaking when you upgrade to a new version of Sass. This kind of crazy decisions makes...

@nex3 : Another great use for polyfilling : if I could polyfill either the `@import` syntax or the new syntax in some way, I would not have to worry about...

Any updates? I need this feature badly!