Forgot your password?
typodupeerror

Comment: Re:Browser Apps are NOT desktop apps (Score 1) 190

by StripedCow (#48194001) Attached to: JavaScript and the Netflix User Interface

The real underlying reason these apps feel flimsy is probably that Javascript is a single-threaded language.

The language is single threaded, doesn't mean it can't support "threads" in a message-passing way. The fact that my old Apple ][ can support threads by hooking 2 of them up through a serial interface doesn't make them "multithreaded". But if you want to look at it that way, then I apparently can't stop you :)

your assumptions simply don't match reality

Ok, so if a "for" loop is transformed so easily into an equivalent asynchronous structure, please enlighten me and show me how.
For example, take these simple nested loops, and I'm curious what code it transforms into.

function f(x)
{
    for(var i = 0; i < N; ++i)
        for(var j = 0; j < N; ++j)
            for(var k = 0; k < N; ++k)
                x = g(x, i, j, k);
}

where g is some constant-time function.

Comment: Re:Browser Apps are NOT desktop apps (Score 1) 190

by StripedCow (#48185147) Attached to: JavaScript and the Netflix User Interface

As threads are not an option in JS, it's a great opportunity for you to explore various alternative approaches.

Please don't forget that the whole point of my comment was that threads are broken in JS.

Go do some reading about asynchronous programming and event-driven programming.

The problem with event-driven/asynchronous programming is that it requires a lot of work, and makes your code look awkward. For example, a simple "for" loop turns into a monster of functions calling eachother, in order to break the inside of the for-loop into small chunks that can't lock the UI. Now imagine a doubly-nested for-loop. You'd need special compilers to keep your code clean.

Remember that Windows 3.1 was replaced by true multitasking for a reason.

Also, asynchronous code can only make use of 1 core of your CPU, which is also a waste.

Comment: Re:Browser Apps are NOT desktop apps (Score 1) 190

by StripedCow (#48185121) Attached to: JavaScript and the Netflix User Interface

A customer just called. He pressed "Ctrl+End" to go to the end of the document, while it was counting words. He complains that the user interface is frozen.

Just because you can't think of a way to solve a particular problem you've just thought of, doesn't mean that high-quality performant programs can't be written in the language.

Yes. But because of this problem of the (fictituous) customer, I now have to rewrite my 30.000 lines of code from web-worker style to single-threaded asynchronous style. Unless you have a better idea :S

Comment: Re:Browser Apps are NOT desktop apps (Score 1) 190

by StripedCow (#48181223) Attached to: JavaScript and the Netflix User Interface

The problem is that "threads" are supposed to be a solution to dividing work.
If you don't have threads, how will you divide work without ruining the nice hierarchical structure of your code?
You'll need a special compiler that does this for you. And the result will be *slow* (albeit perhaps more responsive).

Comment: Re:Browser Apps are NOT desktop apps (Score 1) 190

by StripedCow (#48180381) Attached to: JavaScript and the Netflix User Interface

Maybe you should just, you know, leave the text in the non-GUI worker to start with?

Let me get this straight. This means that when the user scrolls the document, the web-worker would feed the GUI with lines of text incrementally (?)
However, if, at the time of scrolling, the web-worker would be busy counting words in the document, I don't see how the GUI would not *effectively* freeze just as well (the main thread would be waiting for new lines from the web-worker which is busy counting words).

Or you can incrementally update the background thread as the data changes.

This is like splitting up the task of counting words into smaller tasks that execute incrementally.
"Splitting-up tasks" is the keyword here, and the thing is, that's what threads are supposed to do. If we split up all our tasks manually, we wouldn't need threads.
The web-worker thread-model is not really helping, because we'd have to split up tasks anyway ourselves.

Comment: Re:Browser Apps are NOT desktop apps (Score 4, Informative) 190

by StripedCow (#48178371) Attached to: JavaScript and the Netflix User Interface

Web-workers are not cutting it. For the following reason.
Real multi-threaded programs have a shared address space. Web-workers do not.

Example: suppose your GUI runs on a 1 megabyte long text-file.
The data-structure that models the text-file is 2 megabytes long.
Now you want a web-worker to do something with this text-file in the background (e.g., count the number of words).
So you start a web-worker thread. But then you need to send the text-file as a message to the thread (since there is no other way the thread can reach the data).
Sending this 2 megabyte chunk of data will surely freeze your GUI for a while, and so the whole point of multiple-threads is mostly lost.

Comment: Re:Browser Apps are NOT desktop apps (Score 3, Insightful) 190

by StripedCow (#48178239) Attached to: JavaScript and the Netflix User Interface

Lets stop pretending they are anything close.
Google docs/sheets/whatever is a really crappy imitation of a full fledge office suite ...

The real underlying reason these apps feel flimsy is probably that Javascript is a single-threaded language. It's like going back to the 80s.
This means that when processing one action of the user (especially if it is a complicated action), the user interface will temporarily freeze.
In this day and age, this is totally unacceptable.

Comment: Re:Why the hell... (Score 1) 190

by StripedCow (#48178227) Attached to: JavaScript and the Netflix User Interface

Totally agree with that.

The only problem seems to be the acceptance of NaCl by the other big browser vendors (Microsoft, Mozilla).

Here's what wikipedia says:
(warning: could be outdated)

Reception
Some groups of browser developers support the Native Client technology, but others do not.

Supporters: Chad Austin (of IMVU) praised the way Native Client can bring high-performance applications to the web (with about 5% penalty compared to native code) in a secure way, while also accelerating the evolution of client-side applications by giving a choice of the programming language used (besides JavaScript).[30]

Id Software's John Carmack praised Native Client at QuakeCon 2012, saying: "if you have to do something inside a browser, Native Client is much more interesting as something that started out as a really pretty darn clever x86 hack in the way that they could sandbox all of this in user mode interestingly. It's now dynamic recompilation, but something that you program in C or C++ and it compiles down to something that's going to be not your -O4 optimization level for completely native code but pretty damn close to native code. You could do all of your evil pointer chasings, and whatever you want to do as a to-the-metal game developer."[31]

Detractors: Other IT professionals are more critical of this sandboxing technology as it has substantial or substantive interoperability issues.

Mozilla's vice president of products, Jay Sullivan, said that Mozilla has no intention of running native code inside the browser, as "These native apps are just little black boxes in a webpage. [...] We really believe in HTML, and this is where we want to focus."[32]

Mozilla's Christopher Blizzard criticized NaCl, claiming that native code cannot evolve in the same way that the source code-driven web can. He also compared NaCl to Microsoft's ActiveX technology, plagued with DLL hell.[4]

Håkon Wium Lie, Opera's CTO, believes that "NaCl seems to be 'yearning for the bad old days, before the web'", and that "Native Client is about building a new platform – or porting an old platform into the web [...] it will bring in complexity and security issues, and it will take away focus from the web platform."[4]

See http://en.wikipedia.org/wiki/G...

When you don't know what to do, walk fast and look worried.

Working...