backspaces

I wanted to create webdav servers hosted by glitch and cpanel. I ended up with exactly the same code on both, nice! Basically they both have node.js capabilities so I could use node.js webdav-server.

But then I got the bright idea of using deno deploy which I've used in the past and loved, even using kv rather than a file system. It works (thanks chat) but it basically required creating my own version of the node.js webdav-server. Kinda annoying.

The bottom line is that deno deploy is fighting a battle it can't win. Deno was the "better" node.js. And then it started integrating node capabilities, trying for a drop-in replacement of node. Nope. Sigh. I still love it for many simple projects but there's a reason node.js is, er, node.

https://comebackalive.org.ua/donate/ worked for me. I tried the original url last night and ran into problems. Note you need to use UAH currency. $250 was 7336.23 UAH .. sorta sticker shock!

Actually, it should be: JavaScript is weakening the JavaScript ecosystem.

In the olden days, html, css, js were it. But each were "subclassed" by better solutions compiling to html, css, js.

Then huge frameworks arrived to try to organize the mess we'd created. Making devs further than ever from html, css, js.

Remember the old saw: Sure I understand JS, I use jQuery every day! Er, but how about closures? direct DOM use via JS? And so on.

To be fair, jQuery and later CoffeeScript, improved JS considerably.

I don't get the feeling that TS is going to help JS, but hopefully I'm wrong. But unarguably it is SPLITTING the JS ecosystem into warring camps.

From 50,000 feet: - Top engineers are able to solve a problem, and are hired to do so. - Others are able to solve tasks, and are hired to do so.

This is easy: check out D3's architecture. It is "near functional" and tosses all the overly-complex (i.e. dangerous) parts.

And definitely read the still important "Javascript, the Good Parts".

Where is the repo? A project here in Santa Fe may be a useful addition and I'd like to get in touch with the authors.

Boy do I hope you're right! Performance is likely an issue tho. Wasm is designed to be faster, both loading/parsing and execution.

I did notice that es6 import/export works for Wasm, so I can write performant segments in C. Whew!

So I should give up on JS programming, go back to C/C#/C++/Java/Swift and have them generate wasm? Kinda sad, I like JS. But I like performance too.

Is there a possibility for JS tooling? Babel etc? Or any compile-to-JS language like CoffeeScript, TypeScript etc being able to emit/convert to wasm?

Or maybe I'm missing the whole point of this? :)

Turing Complete is soooo comfy!

(I write this without rancor, as ES4 needed to die.)

Apparently Chrome feels the same about ES6 .. they continue playing launch pad chicken (only 39% on Kangax)

Wow, JavaScript is approaching science fiction levels of sophistication! Love the idea of moving functionality from client to server or reverse. Knew about Docker but not Ansible, thanks for that. Now we need some Sweet Macros to help too.

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

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

+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.