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!
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.
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.
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.
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?
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
I am 70 f*ing years old and have kicked butt on many platforms. And I am amazed at a current revolution being missed by many: Javascript Everywhere. Browser, desktop, networking (JSON for transport), server (node.js). One Language To Rule Them All.
I'm a student at UNM and took a graphics course which was opengl based. I asked if either GLSL or WebGL would be OK for homework. After all, webgl had finalized its spec 3 days earlier! Yup, why not .. the prof was even interested enough to write several webgl demos himself.
Processing, the wonderful 2D/3D system approachable by designers was converted to ProcessingJS by John Resig.
HTML5 is mind blowing.
So in short, I've left all the rest behind. This brilliant ecology is no longer just a language .. its far too rich for that. Imagine the surprise when someone asks: "What's a JS library" and I answer "A URL".
Biggest fears? I'm concerned that some of the attempts to "tame" JS may screw it up. Will "Require" make JS as hard to deploy as Python with a web of interdependencies that end up being intractable? (i.e. nearly O(n^n)? And will classes be as bad as I think they may be? And will Google go all evil on us with Dart?
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.