An Interesting Look At the Performance of JavaScript On Mobile Devices 157
First time accepted submitter faffod writes "Coming from a background of console development, where memory management is a daily concern, I found it interesting that there was any doubt that memory management on a constrained system, like a mobile device, would be a concern. Drew Crawford took the time to document his thoughts, and though there is room for some bikesheding, overall it is spot on. Plus it taught me what bikeshedding means."
Spell-check in IDEs (Score:5, Informative)
Coincidentally, most IDEs for javascript have little to no spelling assistance
Spell-check in IDEs generally relies on static analysis of the variables in scope at any given point in the program. The more dynamic a language's type system is, the harder it is to statically find the names of symbols in scope at any given point in the program. PHP and Python are kinda-sorta OK for this because all global variables are out-of-scope (PHP) or read-only (Python) unless declared otherwise at the top of a function's definition (or, in PHP, unless the variable is one of the predefined superglobals, whose names are all uppercase starting with $_). This way, the IDE can parse a function for all variables assigned to in a function and assume they're local. JavaScript, on the other hand, defaults to making all variables global unless declared local with the var keyword.
Spell-check also relies on static knowledge of what source code files are in scope. This is dead easy for Java. In PHP you scan for require_once, and in Python you scan for import, but even then, a module is occasionally conditionally imported, and importing has side effects. JavaScript can't include JavaScript at all except by appending a <script> element to the HTML DOM with the src= attribute referring to the other script, and the idiom for that is harder to recognize than a simple import statement.
TLDR version (Score:5, Informative)
An important point he made regarding GC routines and how they tend to be unpredictable in terms of when and how long they run. Also, much was discussed on his observations that, if you have several times more memory available than what your app needs, the GC routines are very non-intrusive. However, when you get into a low memory situation, the performance hit from GC is huge and causes obvious stutters in the application and/or it's UI.
Also, some discussion on the irony of working around (or trying to "spoof") the GC by using various manual techniques, and how that almost amounts to manual memory management. All in all, a really interesting read.
Re:TLDR version (Score:2, Informative)
Your super short summary was still 3 paragraphs long... TL;DR indeed!
Re:What's better than JS? (Score:4, Informative)
Sorry. Things change. It won't be long before browsers are just wrappers around the JSVM and all web addresses are just sandboxed applications running in it. The web is the biggest App Store there is.
You want raw data in a structured format? There are REST APIs for that, they return JSON. HTML is too verbose by far as the default response and is useless for any other client besides an HTML renderer.
Text content is moving to Markdown as a standard as well. It's quicker and easier and covers text formatting. Clients should just render it directly.
I could go on but it's probably lost on you. Suffice to say that modern server app development is evolving to be service driven and client agnostic. HTML is one of many targets. Why write server apps or content engines (CMS/blog/forum) for a single client when you can instead create a server based API and several thin client apps (JS, DART, iOS, Android, C++, .Net, Lua, etc).
Re:The editors don't RTFA (Score:2, Informative)
- Is there only one editor, who always reads every single featured article?
- Are slashdot editors barred from clearing their browser histories?