Hacker Newsnew | past | comments | ask | show | jobs | submit | more backspaces's commentslogin

But of course no one uses either when there's Atom/GitHub's favorite: CSON. https://github.com/bevry/cson


Why aren't you discussing the es6 loader which is available now?

https://github.com/ModuleLoader/es6-module-loader

It can deal with both AMD and CommonJS modules, as well as es6 import/export. It does not need traceur and will work with today's JS. And is built upon the standards based System.js which basically provide loader hooks for node, JS, and even Web Components if they so desire.

It is sure nice to get rid of the forrest of <script> tags and not be concerned about order of dependencies.


Not having separate status hosting is liken not salting passwords. As a NC user, I may leave just for this reason


Well, I agree on the performance (speed) side, VM out, subset In. but feel abandoned on the memory footprint side.

Objects are just huge! Asm.js promises something more like structs, I think. Now making THAT available to JS programmers would be a great help.

I really don't want to go back to C just for faster JS. Lets use the knowledge of the last year to put some of the asm.js goodness into JS hands. LLJS is likely not the answer from a recent jlongster post. Rather than a new language, simply parts of asm.js would be better received by the JS community.

   -- Owen


Typed objects (ES7) offer struct-like packing and heap repr efficiency, independent of asm.js:

http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects


But alas, the browser wars are upon us once again. FF vs Chrome is approaching the silly.

On the other hand, there are merits in their differences. Chrome, although it would prefer Dart, looks upon JS as legacy that they can approach via a good VM/JIT, and a brilliant Developer Tools suite.

FF on the other hand is leading into the JS futures on two fronts: asm.js for both performance and C/C++/.. integration into the browser, and ESnext. Google is very reluctant to invest in ESnext now, just look at the compatibility charts.

This makes sweet.js strategic, it lets us at least experiment with ESnext features as far as macros can take us. I'm hoping sweet.js can also help us make use of asm.js from within the browser buy building macros for things like structs, which halve or more memory footprint of object arrays.

Lets be aware of the war, and do what we can do to resolve it.


It is SOOO odd to see folks not "get" the JavaScript Everywhere revolution. Node, JS/CoffeeScript, JSON: Server, Client, Network Data. Complete stack, period.

C++?? Gack, so yesterday. Python, Ruby, etc .. so without dynamic windows everywhere.

Google?? So confused. What's their next project jerked out of our workflow? When is Google coming out of beta?

Keep up the good work /be

   -- Owen


The Facebook "phone" approach is interesting: take over the phone to such a degree that it delivers a FB "experience". No dependencies of the Evil Triangle of the cell world: Handset mfgr, OS provider, Carrier.

Yet Moz apparently is looking to become another OS provider? I'm wondering if they might take the FB approach instead.

FB will succeed now with Android, there appears to be no App Store issues. But my bet they'll also force Apple to cry Uncle! relatively soon. Now THAT would be progress


We have a launcher-based approach in the works too. IMHO it's not going to sweep the world, and neither is FB Home.

Strategically, the big problem all such approaches face remains, and it may even get worse as Android matures. Google owns that OS and controls its APIs and rules for extensions.

Anyway, Android 4 doesn't even fit on 256M phones single-core phones, where Firefox OS is entering the market. It is priced out of the launch countries.

So taking a high-end-focused Android-only approach of "[do an FB-Home-like launcher] instead" does not make sense tactically or strategically.

"Also" rather than "instead" can help, we're exploring in the context of Firefox for Android and the Web Runtime based on it -- but it's not exclusively & clearly winning such that we would bet Mozilla on it.

/be


+1 BCPL! Like the first language after it was B. Then C. So shouldn't C++ be P? :)


As lovely as symbolic mathematics is, it does have one major problem: it can not be parsed.

I do not mean the symbols cannot be drawn etc, but even a simple expression like "ab + c" can not be disambiguated. Is it "a*b + c"? or is there a variable "ab" added to c.

This requires the idea of "closures" .. i.e. history/state in which the expression appears. (Wolfram discussed it at a conference once, but I don't have the reference alas.)

So the solution is either to simply introduce new symbols to facilitate parsing (i.e. require multiplication symbols .. but there are more) or introduce heuristics that use history as the human does.

One promising technology is touch screens and sophisticated trackpads (Magic Pad for example) which lets us "draw" mathematics.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: