node webkit

https://github.com/rogerwang/node-webkit/

Discuss.

I don't care.

Also, see: Mozilla prism.

Call all Node.js modules directly from DOM and enable a new way of writing applications with all Web technologies.

Every project summary in the field of ``web technology'' sounds like a bad commercial for some reason.

Why does Intel love Javashit so much anyway? First this one engine that was supposed to super-optimize your Web 3.0 apps, now this. It's like they are sponsoring bad and slow languages with the goal to sell more processors.

>>3
What? If you have a critique please state it. I see it simply as a way for node.js apps to have an UI. And javascript is fast.

JavaScript numbers are always stored as double precision floating point numbers, following the international IEEE 754 standard.

Why would you do that?

>>3

Why does Intel love Javashit so much anyway?

Because JS is one of the few areas where having a few super-fast cores still makes consumer sense over having lots of pretty fast cores (AMD). Video games have been console ports for so long that they no longer stress machines enough for Intel to see them as useful benchmarks for marketing purposes, and not even the best efforts of Microsoft and Google can make the ``Run an office suite AND a browser!'' claim impressive anymore, so they are shifting gears and trying to embrace layers and layers and layers of shitty, slow middleware.

In the near future (or more probably, now) you'll see that CPUs are advertised by how may FPS they can crank out on le epic web 3.0, and that future can only come about if the web actually needs CPUs that powerful.

Do you want to sell your soul and make fat loads of cash? Write a transcompiler of something like Haskell to JS and sell it off to Intel, Mozilla, and Google. The only problem is that you might suffer heart failure from excessive masturbation to the idea of Real-time interactive correctness-proofs during live deployment of next-generation web frameworks.

I'm not sure I understand this project well.

call Node.js modules directly from the DOM

Does this mean that calls that are made to the server are used directly from the Javascript code that anyone can see (or edit)? If this technology were to be widely adopted, would this not lead to a large surge in javascript injection attacks on web sites?

>>4
node.js ``apps'' are the problem, or rather [m]node.js[/m] is. Just when you think web development got back to its senses and started to move away from Javashit, this thing comes and sets the world back with completely ridiculous claims of performance that everybody and their grandmother gobbles up immediately, no matter how obviously bullshit they are:

node.js scales linearly with the number of cores.
— Ryan Dahl

What people don't mention in the advertisement is that you have to write your program in callback-style Javashit, which has got to be the worst way to do concurrency ever conceived. I'd say only raw mutexes are worse, but I'm not even sure about that one because at least I'd have a language choice there. You can't really use anything else either because node.js doesn't play well with saner concepts like promises and most modules, another purported strong point of node.js, rely on callbacks.

So what this project essentially does is package a bad platform based on a bad language and a bad idea together with a rendering engine that infests the web with its ad-hoc, IE6-like pseudo-standards, thus create a lovecraftian software stack and call it ``a new way of writing applications with all Web technologies''.

This project seems completely and utterly pointless to me from a development perspective. Web technologies are for the web, and they suck in their current state, even for their original purpose. Why anyone would try to port them and shit up the desktop world with repurposed tools unsuited to the job at hand is beyond my comprehension. This seems all too much like this node.js solves everything mindset that appears to run rampant in its community right now and happens every other year when the new overhyped framework hits its peak in popularity.

Sorry, Intel, your new way to write applications sucks.

Web technologies [...] [b]suck[/b]

Yeah but a lot of web devs don't know about this, because they've never done anything else than HTML/JS/CSS. They think they are in control and from their perspective they are.

XYZ scales linearly with the number of cores.

Doesn't Amdahl's Law say something else or don't I get it?

Huh, it worked in the preview window.

The preview window is better at parsing than the actual post handler, it seems.

>>9
I'm pretty sure you got what >>8 meant. Amdahl's Law just formalizes the response ``Perhaps, but that doesn't actually mean anything, and certainly not anything impressive''.

>>5
In lua, all numbers (even integers) are doubles
>>8
It seems you don't know much about the design concepts of node and all you can say is "b-but I hate callbacks!"
Non-blocking in the same thread is awesome, and the only way to do it is with callbacks. I'd also like to see a threading library for node, but the designers seem to opt for many node process communicating over sockets instead.

>>4

And javascript is fast.

So is Java, actually. The resource consumption for both is fucking abysmal, though.

>>12
Lua is a shitty Javashit clone for faggots.

>>12
If ``b-but I hate callbacks'' is all you extracted out of my post, I recommend you to double-check your reading comprehension. If you think callbacks are in any way acceptable for a high level of concurrency in 2014, I recommend you to double-check your sanity as well while you're at it.

Haskell solved the problem node.js tried to solve in a completely superior way when it put green threads and an event-driven architecture into its runtime. Another frequently quoted benefit of node.js's model is the lack of race conditions because everything is in one thread. This is not only false, but once again easy to mitigate in other languages through clean, proper concurrency primitives, which node.js doesn't put any kind of focus on. After all, there are no race conditions if there's only one thread, right?

The horrible irony to see here is that other languages are not only more pleasant to use than node.js (might as well call it a dialect of JS) but perform better, too, and I didn't even use languages optimized for concurrency as an example. So node.js is not even a good trade usability for performance kind of platform, it's just ass-backwards.

There's no reason to use it, and even less of a reason to bring it to the desktop. Let Javashit and nineties paradigms die already, for Christ's sake.

>>13
So it's all a plot of hard drive makers?

>>14
There are no race conditions in single thread.
What languages perform better than Node? You must be using Node wrong.

Also, callback style isn't hard to program in if you have half a brain.
You're complaining about it just because of some misplaced sense of beauty in code.

>>13

The resource consumption for both is fucking abysmal, though.

resource consumption? did you ever used node.js? node is much faster than sbcl, python, and php and the resource use is minimal. I know that you hate ecmascript, but node is actually good, pretty damn good, and so is npm

>>16,17
There are if callbacks are everywhere because the execution order of those produce the same kind of problems. Blindly relying on a conceptually unsound platform to fix every problem of concurrency is not only naive but dangerous.

About languages that outperform Node, I gave Haskell as an example in my post. Once again, please read something completely before you reply, it's annoying if I have to repeat myself or reply to plain misquoting constantly.

callback style isn't hard to program in if you have half a brain

Web programming in Assembly isn't hard if you have half a brain. It's your job to show why node.js is worthwhile: Why should I use it if it's harder to maintain and slower than other platforms?

Misplaced sense of beauty in code is a funny term. Is beautiful code not desirable? Is beautiful code impossible? If you write node.js, maybe. But the world isn't node.js, and I sure as hell am not going to maintain callback JS if I have superior alternatives.

>>19
Choosing between Haskell and JavaScript is like choosing whether that muscly guy named Ahmed Ivanov Goldberg Kim is going to put you inside a Chinese iron maiden or use a set of dirty pliers to slowly and painfully extract your teeth and organs.

In any case program text should definitely not aim to be ``beautiful'' because that doesn't mean anything. Instead, programmers should aim to write program tex that is understandable, useful and easy to change.

>>18
Are you sure node.js is faster than sbcl? sbcl is pretty fast. I may have to challenge you to a game of benchmarking golf.

>>20
What if understandable, useful text that is easy to change is my definition of beautiful?

Just decided on my first node-webkit project :)
https://github.com/affiszervmention/p2pmmo

>>19

Haskell
outperforming node

HAHAAHAHAA, get back to currying monads please

>>24
Just wondering who are you quoting?

>>24
Fifteen seconds on the internet found me http://moreindirection.blogspot.com/2011/01/thoughts-on-nodejs.html , and I don't even like Mexican food.

>>19
Like I said, the ideal would be to have both non-blocking and threading. Node's non-blocking engine is the best there is, ever, and there is no way to do non-blocking without callbacks (maybe you could sugar it to hide the lambdas, though). A for loop is actually sugar for a callback, if you consider callback a instruction that is stored instead of executed immediately. So there you have it, there wouldn't be programming as we know it without callbacks, we'd all be programming in assembly. It can't be that it is only event callbacks that you don't like, because even haskell has events, and any language with events will have a event callback for each of them. Some of these languages use threads to schedule the events, node doesn't need to, but that doesn't change much in the syntax.
TLDR: if you're doing events without "callbacks" it is just some sugar, and if you complain that node doesn't have threads, you can always spawn many node processes and have them communicate.

>>22
Then you have trouble expressing yourself.

>>27
Loops aren't ``sugar'' for a callback.

I wish you people used language properly. As programmers you should know better.

>>26
yeah, that's not how you work with node, friend
to scale with node, you need to create new processes for every order of magnitude you increase. It can't do threads like it's been said, so it's obvious it'll have to lose eventually, if you have enough cores for a lot of threads and you test a single core program against a multi core one, even if it is non-blocking, with a sufficient size of requests the single core one will lose every single time.
Sorry for the basic cs lesson, I thought you weren't trolling.

>>28
you might not create a function object for the instructions, but you parse the instruction and store it somewhere, it could be done with a function object all the same (see scheme's hacked up for-loops), it is just such a common pattern that they decided to parse away the need for the lambda.

>>27
Way to miss the point. The blog posted by >>26-san contains a very striking line:

"I object to doing things computers can do" - and explicitly handling I/O responses certainly falls into the category of Things a Computer Should Do.

Arguing that everything is just callbacks under the hood actually suggests that this line, every single one of its implications and my entire point is correct. Doing callbacks manually when a clearer form of code can be translated to equally fast or even faster callbacks by the machine is comparable to writing everything with gotos in order to optimize loops and ifs because you think compilers produce slow code. Sure, they are gotos under the hood, but that doesn't mean we should use goto to emulate while.

This isn't progress, it's an incredible regression disguised as progress.

>>28

I wish you people used language properly.

Get with the times, man! ``Using language properly'' is for old fogeys and things like standards and specs. You should be more Agile.

>>27
Events aren't a language feature (except maybe in something like Esterel or GOLOG (see below)). They're a system or run-time (or even library or framework) feature.

You don't need callbacks to do ``events'', e.g. you can make an ``event'' framework using continuations, coroutines, streams etc. etc.

GOLOG did ``events'' (the situation calculus) declaratively.

>>29
You are very incoherent. I'm not sure if you understand that operating systems such as Linux will schedule multiple processes over multiple hardware threads of execution. The performance difference is that usually when people say multiple processes they mean multiple processes that don't share memory, whereas when they say threads they refer to threads in the one process which share methods (again, usually).

BTW what's with the influx of novices here?

>>33

...which share methods...

by ``methods'' I mean ``memory''.

>>33
Going off completely unresearched speculation, I'd say the pedorider thread on the old /prog/ was bumped and got some more exposure. It'd explain the amount of crossposting, too.

>>33
I suspect something a bit more sinister than >>35-san.

>>31
You can't create sugar for every single kind of callback.

>>33

continuations
storing the environment and execution point, to continue there later

yeah, a lot different from callbacks

multiple processes they mean multiple processes that don't share memory

a node server is lightweight (unless you're doing some pretty big simulation), the overhead would be minimal

>>38
also, you don't need that many node processes compared to threads because of the async performance

I'd wager that node with multiple processes is the single best way to explore multiple cores, or even a network of clusters

single best way known*

>>38-41
Could you please quote properly and stop making quadro posts in two minute intervals?

>>38
Yes, continuations are very different from callbacks. For example when I call a callback, a new frame is pushed onto the current execution stack. By contrast, when I call a continuation, the execution stack is swapped out for a different one.

You're using callback very generally, i.e. to mean calling procedures and passing procedures as arguments. Do you understand what this definition of callback entails? Do you understand why such a definition might be redunant and thus useless?

　.＿＿ I LOVE
ヽ|･∀･|ノ NOODLES
　|＿＿| DOT
　　|　| JIZZ

This thread looked like it may have had interesting content in it, but I have discovered it's just a train wreck of someone forcing node.jizz into a practical situation like one delivering a pet duck by savagely shoving it though some nasty pipes that it don't quite fit together and it comes out on the other side in many pieces and there's blood everywhere and the duck handler is panting furiously and reflecting upon the struggle and pondering if there is or is not a better way to accomplish the task of duck transportation and coming to the conclusion that further research into shoving ducks through jagged pipes is required and is the only way in which duck transportation will progress.

I LOVE JIZZ

http://taskjs.org/

Tasks are interleaved like threads, but they are cooperative rather than pre-emptive: they block on promises with yield.

node.JEWS

Is https://github.com/affiszervmention the node.jizz lover posting on this thread?

>>49
All signs point to yes.

>>49
Yes, see https://github.com/affiszervmention/permadeath/blob/master/about_me.md

>>43
I know the common definition, I was just pointing out that the basic principle is the same and there's no reason to prefer one over the other.
So continuations are more memory-efficient? Still that's no reason to completely disregard callbacks.

>>52
Continuations are different from callbacks, and rarely supported by languages due to the overhead they incur. Imagine you can you save a point of execution in your program, and then return to this point later. You may reinvoke the execution point many times. Each time you reinvoke it, you may pass back a different value each time.

It's like you are making a sandwich. You put the ingredients on. You put it together. You take it back to the couch and watch TV. Then you see a television commercial that shows a certain topping that you missed. But you've already started eating the sandwich. So you go back in time to when you were putting the sandwich together but this time you have that topping in mind. You continue making the sandwich again and sit and watch TV. But then another commercial has reminded you of a different topping that you forgot. So you return again to the prior point of execution with a new topping to make.

You can support execution that behaves like continuations, but it's cumbersome and uses tail calls and an emulated function call stack with a stack of linked functions. Oh and the post you are replying to, you can still have that effect if you do a tail call on the callback.

I don't like how these functions are being called 'callbacks', and also that something as fundamental as a 'callback' is being associated exclusively with something as retarded as node.jiss. This pattern is used all the time in almost all languages.

>>53
Is node.js retarded because of callbacks or are callbacks looking bad because of node.js? Please decide yourselves.
But I agree that callbacks are a pretty basic concept and not an exclusivity of node.
And I didn't know much about continuations, thanks for explaining it.

So, I think we all agree that Node.js is a good PLATFORM but yet using ECMAScript makes it useless?
What about those languages that compiles to javashit? like coffeescript, livescript, or lispyscript..

>>51

Javascript programmer (mainly, both browser and node) and crazy-about-it gamedev. (I'm the main guy defending javascript on /prog/)

OH SHIT IT'S THE ACTUAL JAVASHIT KIKE

>>55

So, I think we all agree

No, fuck off.

>>56
Yeah, it's me. Ask me anything.

>>58
Will you kindly leave and never come back?

>>58
How often do you go to the synagogue?

>>59
No, I need you guys' level of expertise for feedback on my ideas and projects. And I also find some of you guys' projects interesting (like DistBB for instance).

>>60
I'm an agnostic atheist. (And a libertarian bleeding heart.)