Amusing, this article was submitted 2 weeks ago and got no comments. https://news.ycombinator.com/item?id=5973914
Bad timing?
Enough with the JavaScript already
171–180 of 231 posts
Re: Enough with the JavaScript already
#172Re: Enough with the JavaScript already
#173OK, who clicked through all 84 slides?
Re: Enough with the JavaScript already
#174Earlier quoted context omitted.
It works well. It takes advantage of Portable Class Libraries (PCLs) in .NET which can target just about any platform including Xbox's. Basically all your UI logic sits within these PCLs. And the only stuff you have to write/design for each platform is the actual screen layouts. Then you just setup the data bindings back to your models. It's a shame this is news to people on here. It seems like the real innovation th…
How do you write UI code to make apps look and feel correct across platforms? Does Xamarin already support the API changes in iOS 7?
Re: Enough with the JavaScript already
#175Earlier quoted context omitted.
Save 5 MB and condemn yourself/your team/your company to the hell of maintaining multiple code bases that all do basically the same thing but subtly different and written in different languages. Sounds like a dumb ass decision. It's the sort of logic that makes people pick C or C++ when a managed language would have been more appropriate.
I'm curious how well these tools work. Having a single unified code base and supporting all (desired) platforms is every developer's dream. I'm skeptical because supporting multiple operating systems can be a headache even for desktop apps. I remember Facebook originally used HTML5 to support all platforms. This did work, but they became unsatisfied with the performance and ended up rewriting both the iOS and Android…
What is extremely telling about this whole ordeal is how awful the facebook app on iOS is now. Their biggest issue (they claimed) with their HTML5 version was adding new elements as a user would scroll. The DOM operation was said to be both costly and leak memory like crazy. Sencha Labs has shown that they were able to accomplish it just fine.
Where I feel they should place some of the blame is the backend architecture. Perhaps the app doesn't scale well. Perhaps they should research what the proper amount of data is to send to any given device. Implement more of a lazy approach. They have some very brilliant people working there. I find it hard to believe that HTML5 can be blamed totally for their app's poor performance.
Re: Enough with the JavaScript already
#176There is a place for Javascript, but it feels like it's being excessively overused.
Anyone who browses with Javascript disabled (using, for example, the noscript browser add-on) will be aware how many sites, even those with mostly text content, fail to load without Javascipt.
Google's blogger/blogspot service is one of the worst offenders. Here's an example: the official Android blog from Google. The page simply won't load with Javascript disabled. Once it is enabled, you have a page of mostly text. This is simply bad web practice in my opinion.
Re: Enough with the JavaScript already
#177JavaScript is a tool. Once it becomes trendy idiots will always abuse a tool. It's not JavaScript's fault people are bad at web design and development. If it wasn't fucked up JavaScript these people were contacting you about it'd be something else, be glad you have a job.
It does not however, preclude the possibility that the tool is in fact a bad tool, and that the tool is bizarrely the only tool we have. They say poorly skilled people blame their tools, and that highly skilled people who know their tools well, will know how to use it well. That being said, see that circular saw over there that will occasionally bounce and cut off its user's fingers? I'm not gonna use it, no matter h…
But JS isn't just a tool. No programming language is.
JS is more a workshop that happens to contain, amongst its stations, a less-than-safe circular saw. And you can absolutely, productively use the shop without using the saw, or by using the saw, if necessary, with additional safety precautions.
And because some people use the saw willy-nilly, you're saying we should throw out the whole shop?
Re: Enough with the JavaScript already
#178I love how the tech community promotes something until it's over used and only AFTER everything breaks then we THINK about how / when we can use a technology...
Re: Enough with the JavaScript already
#179Earlier quoted context omitted.
It does not however, preclude the possibility that the tool is in fact a bad tool, and that the tool is bizarrely the only tool we have. They say poorly skilled people blame their tools, and that highly skilled people who know their tools well, will know how to use it well. That being said, see that circular saw over there that will occasionally bounce and cut off its user's fingers? I'm not gonna use it, no matter h…
Fortunately, JS is not the only tool we have. JS is a relatively fine compile target , and with asm.js, a pretty fast one. So pick your favorite among CoffeeScript, TypeScript, Dart, GorillaScript, Elm, ClojureScript, etc, or try compiling your favorite language using LLVM. Let a compiler take care of all the numerous rough edges raw JS has.
> JS is a relatively fine compile target ...
No, it's not.
> ... and with asm.js, a pretty fast one.
And asm.js demonstrates why it's not, because asm.js isn't JavaScript. It's a strictly defined ASCII-encoded bytecode that happens to be representable using a subset of valid JavaScript.
At which point, one must ask, what bizzaro-world engineering justification do we have for using a JavaScript subset as a first-order bytecode format? Why couldn't the silly JS bytecode format be a second-tier target for legacy browsers that don't support a proper format?
On top of which, why are we willing to throw away 2x+ performance (in the best case)? Is the iOS/Mac App Store not successful enough for us, such that we absolutely refuse to try something other than adding more JavaScript to every problem we face with web app deployment?
Re: Enough with the JavaScript already
#180Earlier quoted context omitted.
Fortunately, JS is not the only tool we have. JS is a relatively fine compile target , and with asm.js, a pretty fast one. So pick your favorite among CoffeeScript, TypeScript, Dart, GorillaScript, Elm, ClojureScript, etc, or try compiling your favorite language using LLVM. Let a compiler take care of all the numerous rough edges raw JS has.
> JS is a relatively fine compile target ... No, it's not. > ... and with asm.js, a pretty fast one. And asm.js demonstrates why it's not, because asm.js isn't JavaScript. It's a strictly defined ASCII-encoded bytecode that happens to be representable using a subset of valid JavaScript. At which point, one must ask, what bizzaro-world engineering justification do we have for using a JavaScript subset as a first-order…
asm.js is JavaScript. It executes according to the semantics specified in ECMA-262.
The 2x performance numbers for OdinMonkey are not "best case": they include compilation time and will certainly improve (they are better now already).
Regarding having a "real IR", throwing away backwards compatibility for surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for example. It failed.