JavaScript and the Netflix User Interface 195
CowboyRobot writes Alex Liu is a senior UI engineer at Netflix and part of the core team leading the migration of Netflix.com to Node.js. He has an article at ACM's Queue in which he describes how JavaScript is used at Netflix. "With increasingly more application logic being shifted to the browser, developers have begun to push the boundaries of what JavaScript was originally intended for. Entire desktop applications are now being rebuilt entirely in JavaScript—the Google Docs office suite is one example. Such large applications require creative solutions to manage the complexity of loading the required JavaScript files and their dependencies. The problem can be compounded when introducing multivariate A/B testing, a concept that is at the core of the Netflix DNA. Multivariate testing introduces a number of problems that JavaScript cannot handle using native constructs, one of which is the focus of this article: managing conditional dependencies."
What browser apps need.. (Score:5, Insightful)
Re:What browser apps need.. (Score:5, Insightful)
Re: (Score:2)
It's the default action for the backspace key for basically every browser ever on Windows, as well as in Explorer windows. I used it that way for a long time, but since switching to Linux where using backspace to go back in history isn't the default, I was annoyed for a little while and then just stopped using it. I have no idea why it's the default on Windows, though.
I did lose a lot of forums posts back in the Windows days due to backspacing while not having the text box focused.
Re: (Score:2)
I used it that way for a long time, but since switching to Linux where using backspace to go back in history isn't the default, I was annoyed for a little while and then just stopped using it.
FYI, it's still the default behaviour of backspace on Firefox on Linux Mint.
about:config, browser.backspace_action=2 (Score:4, Informative)
Re: (Score:2)
Who the hell actually uses backspace to go back in history on a website?
Maybe people who navigate windows with the keyboard ?
That's what backspace does in windows explorer.
Go back to the folder you came from.
Re: (Score:2)
You can thank Microsoft for that moronic decision. It's also in e.g. Outlook. Why you would want to map a key that's universally used to delete stuff, to act as "go to the previous view" (and worse, swap between the two behaviors depending on focus) is beyond me.
Re: (Score:2)
Re: (Score:2)
The big problem is the javascript "rich" editors that mess with browser state saving.
Backspace is a non-issue a lot of the time if you're using standard HTML widgets - every browser I've used from IE, Firefox and I think even Chrome save the state so if you accidentally backspace, you can hit Forward and boom, everything is restored. It's useful if you want to multi-quote Slashdot, f
Golden Hammer (Score:5, Insightful)
Re: (Score:2)
And in addition, those using it do not understand how they should actually doing things. Browser-side application logic is a nightmare and cannot ever be reliable or secure. If you really need client-side processing, do a real piece of software for it. A browser is just a glorified terminal, _not_ processing infrastructure.
Re: (Score:2)
Browser-side application logic is a nightmare and cannot ever be reliable or secure. If you really need client-side processing, do a real piece of software for it.
I don't see why a browser-base app could not, at least in principle, be as reliable and secure as "real software". As an example, say I write the real application you recommend, and then I also find a way for it to run inside a web page. Will it become insecure simply because there is now a web-browser window wrapped around it?
Re: (Score:3)
You are right in principle. All it takes is to make the browser a real VM environment with security guarantees, a standardized interface, etc. But that is not going to happen anytime soon, because virtualization technology is not there yet and pretty complicated, and a browser does not have VM isolation and reliable execution as primary tasks. In fact, if you remember, a browser's primary task is rendering HTML.
I do expect that some day, many browsers will come with a standardized sand-box that does fulfill
Re: (Score:3)
You are right in principle. All it takes is to make the browser a real VM environment with security guarantees, a standardized interface, etc. But that is not going to happen anytime soon,
... because the standardized interface has already happened, or is happening: https://wiki.mozilla.org/WebAP... [mozilla.org]
The fact that browsers have such a large userbase, and its incredibly easy to make browsers execute potentially evil javascript, js is one of the most secure and best sandboxed languages that exist, that is still powerful. OK there are things as canvas tracking, and webgl shaders. But show me something that supports truly secure accelerated graphics.
When I run my browser, I choose which file to upl
Re: (Score:2)
Somebody has standardized some interface, but that is vastly different from having a generally accepted "standard interface". Seriously, some insight required in this discussion.
Re: (Score:2)
That "somebody" is W3C. And if Microsoft doesn't implement it in their internet explorer, the fact that it is a "standard interface" is not the fault of "browser vendors", but of microsoft. and browser vendors (even microsoft) have aligned their js implementations.
So yes, there is no "generally accepted" standard interface, when you define "generally accepted" as being runnable on IE8. But when you can afford to say to your users "get a modern browser" (still don't understand why google discontinued their c
Re: (Score:2)
Not everything that comes from the NSA is bad. Also, not everything they do can easily conceal backdoors. Some insight into the subject is required to understand what things comming from the NSA are dangerous.
1. Basically, all crypto that uses "magic constants" without a clear and complete spec of how they were reached is highly suspect. That includes most ECC crypto the NSA has done so far and is likely the reason the NSA and some vendors like RSA are pushing for the use of ECC crypto.
2. On a bit more abst
Re: (Score:2)
1. Basically, all crypto that uses "magic constants" without a clear and complete spec of how they were reached is highly suspect. That includes most ECC crypto the NSA has done so far and is likely the reason the NSA and some vendors like RSA are pushing for the use of ECC crypto.
Very true in general. With elliptic curves, you need to use specific curves because randomly selected curves are easily compromised. Only curves with very specific properties are acceptable, but as you point out the NSA has not publicly enumerated those properties. The very same thing happened with the selection of the S boxes in DES, but in that case it turned out that the NSA recommendations did, in fact, harden the algorithm from attacks such as differential cryptanalysis, an analytical technique not
Re: (Score:2)
Java is a great teaching language but will never penetrate business applications to any significant degree until it runs faster for the end user.
You do realize that Java is the #1 language for enterprise business applications right?
Re: (Score:3)
Yes, because the dumbest programmers and most IT-challenged managers are found there. Hence it is no surprise they standardized on using the worst tool available that just about can still get the job done. And yes, from code security reviews of quite a bit of "business" Java code for decidedly "enterprise" settings, I do know what I am talking about. I have never seen anything so stupid anywhere else as what I routinely find in Java "enterprise business applications".
An excellent reason to use C (not C++) f
Re: (Score:2)
They do, but that is not the primary problem. The primary problem is that these "tools" attract coders that suck.
Re: (Score:2)
While not impossible to do in principle (see qemu), such a VM is exceedingly slow.
"Real piece of SW" for which platform? (Score:5, Insightful)
If you really need client-side processing, do a real piece of software for it.
For which platform shall this "real piece of software" be developed? Windows (desktop), X11/Linux, OS X, Windows Phone, iOS, Android, Windows Store, or something else?
Re: (Score:2)
Browser-side application logic is a nightmare and cannot ever be reliable or secure. If you really need client-side processing, do a real piece of software for it.
There's no way in which a non-browser client-side application is more reliable or secure than a client-side application in the browser. That is, unless you deliver it as some kind of tamper-proofed USB dongle with its own processing resources (and perhaps even then).
Re: (Score:2)
That is just not true at all. Maybe look at what secure software engineering can do these days?
Re: (Score:2)
With real software, I do not have that. Reading comprehension: fail.
Re: (Score:2)
Why the hell... (Score:5, Insightful)
Why the hell are we still stuck using Javascript for the web? Why have we not got some virtual machine (not a language specific one like the JVM), that we can compile any language we like to? Half the world is trying to hack around javascript's shortcomings. If even half that effort was directed at making PNaCl viable on all browsers, we would be so much further forward.
Re:Why the hell... (Score:5, Insightful)
First JVM is not language-specific: http://en.wikipedia.org/wiki/L... [wikipedia.org]
Second, javascript can be the compile target of LLVM bytecode. You can compile your favourite C program to js. See emscripten: https://github.com/kripken/ems... [github.com]
Third, javascript has a very fast but still backwards compatible bytecode like subset called asm.js: http://en.wikipedia.org/wiki/A... [wikipedia.org]
asm.js can be set as target for emscripten. The browsers supporting asm.js simply JIT it to bytecode, and those which don't still can run asm.js, but way slower.
Re: (Score:2)
First JVM is not language-specific:
Meaning that it easily supports (without unreasonable overhead) execution of pointer-based languages such as C, or multiple-inheritance languages such as C++, or dynamic languages (with hash-like objects) like Javascript or Python, or multiple-dispatch languages such as Common Lisp/CLOS, or languages with restartable exceptions such as (again) Common Lisp, or languages with lazy evaluation strategies such as Haskell or Scheme, or languages with continuations such as Scheme, right? Oh, wait, it doesn't - it
Re: (Score:2)
OK, point taken.
Re:Why the hell... (Score:5, Informative)
Whuuu? The JVM does not have opcodes for allocating "java" objects unless you use a very strange definition of the term - if it worked that way then how could other languages target it? The JVM has opcodes for allocating objects and calling methods on them, including opcodes like invokedynamic that exist purely to support non-Java languages like Javascript, Python, Ruby, etc.
The JVM has a really large variety of languages that target it. It's impressive. There are static languages like Java, Scala, Kotlin, Ceylon etc, there are dynamic scripting languages like JS (using the new Nashorn engine it's only about 2-3x slower than V8), there are Lisp like languages, there are implementations of Erlang and so on. And thanks to the fairly well specified "least common denominator" type system Java provides, code written in these languages can all interop pretty nicely.
If you think the JVM is language specific then I'd suggest looking at Ruby and Kotlin, two very different languages that are not much like Java, yet nonetheless both can run on top of the JVM.
Re: (Score:2)
Re: (Score:2)
The JVM has opcodes for allocating objects and calling methods on them
And there are many languages out there that don't work in terms of objects and calling methods on them ;).
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
For other languages, sure - I imagine Ocaml, Haskell, C, C++, etc... would be slower if they ran interpreted on the JVM.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Whuuu? The JVM does not have opcodes for allocating "java" objects unless you use a very strange definition of the term - if it worked that way then how could other languages target it?
But they can't. They either have to look sufficiently like Java in order to be able to run on it, or they have to resort to complicated translation strategies to pretend that they look sufficiently like Java. For example, one of the hallmarks of Smalltalk is the #become: operator that causes an object to be replaced by another object of any class (including fixing all the references to the object from anywhere if it can't be replaced physically in place). That's no problem in a dynamically typed language (t
Google has a love/hate relationship with JS (Score:2)
Isn't that more or less the idea behind NaCl/Native Client? [wikipedia.org] It doesn't seem to have caught on. For that matter, there was also ActiveX, and the best that you could say about it is that it had a flawed implementation.
Chrome also just added a runtime for Android apps [google.com], which seems to handle at least some simple apps at native speed on my chromebook. I suppose that's a java runtime of some sort?
I know that there are many wonderful things done daily in JS, but I really would prefer another scripting language.
Re: (Score:2)
I suppose that's a java runtime of some sort?
Actually, it's based on exactly the Native Client environment that you said hadn't caught on. :-p
Re: (Score:2)
I was wondering about that, but I didn't manage to find any information. Do you have a link handy? And maybe information about the differences between Google's stuff and ARChon?
When I said that it hadn't caught on, I meant that other browser vendors were not interested in implementing NaCl.
Re: (Score:2)
Re: (Score:3, Funny)
Simple: Client-side executable content in web-pages is an exceedingly stupid idea, so all the bright language designers stay away from it. Hence it is JavaScript for all those that do not understand how to do a web application right.
Re:Why the hell... (Score:5, Insightful)
It has a lot of merit, especially if you're trying to do anything fancy. Getting the needed processing power from the client, especially in this day and age of overpowered commodity hardware, rather than the server frees up the server to do more important jobs, and really as long as you're sanitising properly inputs why not. What's really needed is a proper push routine but that comes with its own tangled web of problems.
Re: (Score:2)
Oh, I do understand the arguments for it, but it still causes a lot more problems than it solves, and hence should not be done, ever. Reliability and security are critical. If you do not have them, stop right there. Wanting "fancy" is not a valid excuse to mess up. And lets face it, most modern web applications have pretty low actual processing needs. An inefficient implementation on the server-side is not a valid excuse to do processing on the client. It is an often used one though.
Re: (Score:3)
Re: (Score:2)
Well, since of all these sites I use only Amazon and Google, it seems that JavaScript is primary a tool for wasting people's time. No surprise. But who says I refuse to use JavaScript? That is entirely in your mind. I will just call trash trash, even if I use it because there is no good alternative.
Re: (Score:2)
Thanks, that is exactly what I am saying. If technology is not done sanely, there usually is a huge cost to pay at some time that invalidates all advantaged gotten.
Re: (Score:2)
Re: (Score:2)
I know that. That person has the valid excuse that JavaScript was never intended to be used for anything large or security-critical. It was a quickly hacked-together tool to do small things like changing the color of a button on mouse-over. The problem is all the utterly clueless morons that think JavaScript and the browser are suitable for real computing.
Re: (Score:2)
Because it would take a large group of organizations to cooperate and work together, which rarely happens. Closed source wants to lock out competitors and open source wants to each be their own kings of their own little hills for bragging rights. (Almost nobody really works for "free", they all want either money or credit/status.)
I'd loooove to see a GUI-friendly markup language that is either far less dependent on any scripting or application code for the
Re:Why the hell... (Score:5, Informative)
Why the hell are we still stuck using Javascript for the web? Why have we not got some virtual machine (not a language specific one like the JVM), that we can compile any language we like to?
JavaScript is [github.com] the 'bytecode' to compile to these days.
Not saying that's optimal, but if JavaScript is what the world's web browsers run, then JavaScript is what people will target to get onto those web browsers. At least you can still use your language of choice to do so...
Re: (Score:2)
Re: (Score:2)
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... [wikipedia.org]
asm.js (Score:3)
Why the hell are we still stuck using Javascript for the web? Why have we not got some virtual machine...
asm.js is a subset of javascript that is easily translated to low-level instructions... And runs at near native speed in browsers that optimize asm.js. :) In in practice it might n
Don't get me wrong, I totally agree that asm.js is a messed up construction... One can think of it as a bytecode encoding in Javascript...
But it works, it's fast, and it's backwards compatible... Though anyone trying to use large asm.js programs in browsers with a poor javascript engine will get an extraordinary poor performance
Re: Because it's WEB SCALE on the server (Score:2)
It is a badass Rockstar technology [youtube.com]
Meh (Score:2)
Re: (Score:2)
The delayed transitions are just shitty resource management from lazy hacks, that's a bunch of plugins loading from hither and yon, and it grinds my gears too.
JavaScript sucks badly (Score:2, Flamebait)
Do your damn application logic on the server, as it is indented to. Everything else is insecure and unreliable. Really, that something is possible to do does not mean it is by any means a good idea.
Spaces not tabs (Score:5, Funny)
And use spaces not tabs.
Re: (Score:2)
For most things, that is actually not true. For the few things that need to beat the interaction limit (~200ms), a web-application might not be the right choice in the first place.
While I fully agree on the server-side validation, one thing the client cannot be trusted to do either is keep your web-app isolated from others, which basically invalidates the whole idea for anything serious. Really, a web-browser is not a VM, even if often misused as such these days. If you need that fast response, probably bes
Expand and collapse (Score:2)
For the few things that need to beat the interaction limit (~200ms)
What about things that don't absolutely need low latency but still need to complete without an explicit form submission and complete page reload, such as autocompletion of search terms or expand/collapse of replies to a post in a threaded discussion board?
a web-application might not be the right choice in the first place. [...] Unless you want to start coding for a specific browser in a specific version running on a specific platform?
A not-web application needs to be coded for an even more specific platform than a web application. Make it for Mac, for example, and you exclude users of Windows desktop, X11/Linux, Windows Phone, Windows RT, iOS, and Android.
Re: (Score:2)
"I want" is not a valid excuse for using fundamentally defective technology. It is just an expression of egomania.
Re: (Score:2)
It is also cheaper to have your client's browsers get hacked than your servers. But you are right, the bean-counters are at the root of most evil these days.
Bytecode not Textcode (Score:4, Insightful)
Browsers should not standardize on a particular programming language, but rather on bytecode. But no one wants to use the other's Bytecode solution ( although we have sever great bytecode standards to choose from ) so we're stuck with Javascript.
Re: (Score:2)
I'm pretty sure that's what Java was supposed to be.
In any event, the problem they're discussing isn't unique to JavaScript/ECMAScript, it would plague a bytecode solution too... They're deciding to send all the dependencies they could possibly need over the wire before they know they'll need them, instead of deciding which ones to send on the server-side when the page is requested.
Javascript (Score:2)
Ah Javascript. The language we all love to hate, but isn't going anywhere. It seems like a good portion of all development will be Javascript in the not-too-distant future as legions of low paid programmers take up code writing and maintenance.
In defense of Javascript (Score:2)
I fully expect it [Javascript] to eclipse every other language in terms of popularity over the next ten years, for exactly the reasons you state. Driving down the cost of labor, and unifying skill sets so that people are even more interchangeable.
It pains me to say this, but Javascript is not that bad... I used to really hate it; but over the last year I've done a lot of node.js development. And if done right, it can be really nice. I usually write classes that takes a JSON object and does something... Then I can be very declarative when I put things together. Also asserts helps :)
But yes, static type safety seems to be underrated these days.
As for driving down cost of quickly writing something, I think that is good... Lots of administrative ta
Re: (Score:2)
It pains me to say this, but Javascript is not that bad... I used to really hate it; but over the last year I've done a lot of node.js development. And if done right, it can be really nice.
That roughly translates to ...
"I used to think that JavaScript had a rough learning curve, with all the pitfalls that lure novices in, but now that I know the language it doesn't seem all that hard to pick up."
JavaScript isn't bad because you can't do something right, it's bad because it's so easy to do something wrong. Being successful using it only shows that you have developed the habits and tools to navigate it's minefields, not that it doesn't have tons of minefields. JavaScript is one of those languag
Browser Apps are NOT desktop apps (Score:3, Interesting)
Lets stop pretending they are anything close.
Google docs/sheets/whatever is a really crappy imitation of a full fledge office suite ... from 15-20 years ago. It doesn't even compare to Office 95 other than it has online sharing and collaboration, which is great, except thats a tiny subset of what its actually used for.
Just because you can make a half assed, no where near feature complete but looks pretty and does the first 3 things that come to mind look-a-like of an desktop app doesn't mean its a desktop replacement.
There are no desktop applications 'written entirely in javascript' unless you redefine what a desktop application is to fit a narrow subset of what everyone else does.
Learn to use the right tool for the job and stop thinking just because you can make something look-a-like and emulate a few basic functions that it is the same thing. A screwdriver can be used as a hammer, but it makes a shitty hammer. Google docs CAN be used in place of a full fledge office suite, but it makes a shitty office suite when you replace one entirely. Most geeks who use 'office suites' don't actually use office suites, they occasionally type a few pages into a word processor, sure but they don't do the same things as your full time paper pusher.
Re:Browser Apps are NOT desktop apps (Score:4, Insightful)
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.
Re: (Score:2)
Most browsers actually support web-workers: http://caniuse.com/#feat=webwo... [caniuse.com]
And there are a bunch of wrappers to make them feel more like regular threads. Easy-peasy.
Re:Browser Apps are NOT desktop apps (Score:5, Informative)
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.
Re: (Score:2)
Oh no, you've invented a contrived scenario in which you assert there will "surely" be a performance penalty, therefore the model is entirely unacceptable.
Maybe you should just, you know, leave the text in the non-GUI worker to start with? Or you can incrementally update the background thread as the data changes. I'm not even positive that postMessage() doesn't execute concurrently with the calling thread, as I'm sure the JIT could do.
Re: (Score:2)
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
Re: (Score:2)
Sure bud, you have one central non-gui worker, which the GUI thread communicates with and dispatches shit to other workers that need to process stuff. You store a bit of "extra" text (probably 50 pages would easily fit) in the GUI and make requests when it gets closer to the end.
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. You haven't worked with any other message-passing model
Re: (Score:2)
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
Re: (Score:2)
A lot of AAA videogames have been done single threaded. Web apps can be done the same way.
Have the action change the state, and use requestAnimationFrame to update the UI nicely, v synced. 60 frames per second is enough to feel snappy. Of course, all I/O is already happening asynchronously, and for the very few cases that are left, you can use workers.
Re: (Score:2)
You're probably still running Windows 3.1, with pre-emptive multitasking.
Re:Browser Apps are NOT desktop apps (Score:4, Insightful)
Because three week crash course dev school graduates won't have a clue what pre-emptive multitasking is.
Re: (Score:2)
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).
Re:Browser Apps are NOT desktop apps (Score:4, Interesting)
Re: (Score:2)
Because of convenience. Updates and new features are added automatically, and the developers only have to deploy a single copy to know that everyone has the latest features and bugfixes, instead of having to rely on people updating their local copies. And as long as you have access to a computer with an Internet connection, you have access to the apps you're used to.
Of course there are downsides, but local software has downsides too. It all comes down to your user profile, and for most people, Google docs h
Re: (Score:3)
Because of convenience. Updates and new features are added automatically, and the developers only have to deploy a single copy to know that everyone has the latest features and bugfixes, instead of having to rely on people updating their local copies. And as long as you have access to a computer with an Internet connection, you have access to the apps you're used to.
Of course there are downsides, but local software has downsides too. It all comes down to your user profile, and for most people, Google docs has all the features they need. For power users, you have locally-installed applications with larger feature sets and harder learning curves.
Also, with Google Docs I have full access to my content anywhere, on any device... and, again, all for free. Desktop software, in these respects, is hardly superior.
Re: (Score:2)
Atom editor isn't as good as more mature equivalents, but its close.
Adobe has a tool to create responsive website mockups thats also all in javascript/html while still being a desktop app, I forget its name.
A lot of stuff is done in Node-Webkit, and in many cases you probably don't even know.
Re: (Score:2)
Adobe Reflow was what I was thinking of*
Re: (Score:2)
Javascript? (Score:2)
Man, web apps are so early 2000s. We're all running local apps on tablets and phones now, dudes.
Getting better (Score:2)
As an old-school back end specialist, I hated the spaghetti runtime error aspect of Javascript -- until I started decoupling various aspects using, for instance, AngularJs. Lack of compile-time checking is an increasing part of even compiled languages like C# (dynamic, reflection), but since AngularJs supplies dependency injection, sanity has returned to the logic that needs to be in the front end. As I've increasingly shifted page loads to Ajax calls, my pages have become sweetly responsive even on slow (m
JavaScript is teh SUX!!11 (Score:2)
Oh, wait. I'm trapped seven years in the past.
JavaScript is wicked fast, has first class treatment of functions, JSON and the object model are beautiful, and its duck-typing supports great mixins patterns. JavaScript is now outside the browser with Node.js. The Node people made some awesome wise design decisions and Node is awesome. In spite of stupid haters, JavaScript just keeps getting bigger and bigger and racking up more successes. It beat Applets, Flash, VBScript, and challengers not worth mentio
Re: (Score:2)
Re: (Score:2)
It's not regular DNA - it's Adonis DNA.
Re: (Score:2)
So you man all looks and no function?
Re: (Score:3)
Why do hipster designers insist on dumbing down the entire internet by removing useful features and replacing them with worthless JavaScript pages?
Re:Only Node.js is webscale (Score:2)
That is why hipsters love it as a bad ass Rockstar technology.
http://m.youtube.com/watch?v=b... [youtube.com]
Re: (Score:2)
Indeed. And with server-side generated clean HTML, you also get rid of all the browser issues. This is really another example of technology being misused to (badly) cover up architect, designer and coder incompetence.
Re: (Score:3)
Idiots trying to be cool are still idiots. On the other hand, the content industry is in such a bad shape, that cool idiots may be an improvement.
Re: (Score:2)
Did you choose the "sketchy" type in the pencil settings, by any chance? Try using the "plain" type instead :-)