Live data from Hacker News

Enough with the JavaScript already

fr.slideshare.net

131–140 of 231 posts

Re: Enough with the JavaScript already

#131

One can do a great many things with disciplined Javascript, and I shudder to think what Twitter was trying to do on their front-end that caused a 5x increase in load time compared to server-side template-rendering. That being said, I would very much welcome a high-performance alternative to Javascript that also runs in any browser -- something in the spirit of C or Java, which could be embedded in Javascript and vice…

You should check out ASM.js. It might not strictly be necessary to get a new universal language. It's a really interesting project.

Re: Enough with the JavaScript already

#132

One can do a great many things with disciplined Javascript, and I shudder to think what Twitter was trying to do on their front-end that caused a 5x increase in load time compared to server-side template-rendering. That being said, I would very much welcome a high-performance alternative to Javascript that also runs in any browser -- something in the spirit of C or Java, which could be embedded in Javascript and vice…

> That being said, I would very much welcome a high-performance alternative to Javascript that also runs in any browser -- something in the spirit of C or Java, which could be embedded in Javascript and vice versa.

Possible steps in that direction:

- Google Native Client: run native code in a sandbox [1]

- asm.js: A strict subset of JavaScript that can be optimized to native or near-native speed [2]

I much prefer the asm.js approach. I agree that there's a need for NaCl, but if we look at the browser as a sandboxed virtual machine that everyone has, we should all agree on a bytecode specification for that virtual machine. We pick JavaScript "because it is there". Once all browsers speak native asm.js, then you can compile your client-side code in whatever language you want, even C/C++ (see Emscripten for example). [3][4]

[1] https://developers.google.com/native-client/

[2] https://blog.mozilla.org/mbest/2013/06/25/asm-js-its-really-...

[3] https://github.com/kripken/emscripten

[4] http://games.slashdot.org/story/13/03/28/2113234/emscripten-...

Re: Enough with the JavaScript already

#133
post #36

Earlier quoted context omitted.

What's nasty about Obj-C?

The syntax and the APIs.

I understand not liking the syntax until you get used to it (I find it wordy, but very expressive), but what's wrong the APIs? Apple's documentation is pretty good and the APIs have lots of features especially with blocks. I also like that collections are immutable and the programmer must explicitly ask for the mutable version. Cocoa etc... is quite large, but once the programmer knows what's available many problems that are hard in other frameworks are trivial when coding for OSX/iOS.

Java is well java. I find one of Java's strongest points the extensive set of collections available. Add in Apache Commons and java is easy enough to use.

Re: Enough with the JavaScript already

#134
post #40

JavaScript 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.

Not only idiots, it seems everyone is so obsessed with creating ajax navigation, rich controls, and one page apps. The one apt reason why I never open Google Plus is because every things takes years to load with their fucking javascript in everything.

Why can't sites be like StackOverflow, it only uses JS where necessary.

Re: Enough with the JavaScript already

#136
post #47

Earlier 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…

Seriously your analogy is absurd. JS has a few rough edges that any decent editor will warn you about and that you automatically know to avoid after doing a lot of it for even a couple months. This complaining that JS is unusable is just BS and whining by people who are simply shying away from something they don't know. There are bigger things that can bite even experienced developers like memory leaks and bloat but…

He didn't say it's unusable, he said it's a bad tool...and it is. That's why a whole industry was born to work around it by transpiling to it.

It's a bit ridiculous to say that anyone who complains about JS doesn't know it.

Re: Enough with the JavaScript already

#138
post #47
post #40

JavaScript 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…

I know you are just making a point with the circular saw metaphor, but for those wondering here is some good info on how to use a circular saw as safely as possible:

http://www.docstoc.com/docs/87338746/CIRCULAR-SAW-SAFETY-AND...

http://carpenterbooks.com/userFiles/556/frame_table_mw_pdf_2...

Even still, as the safety guide states, "Be careful, making one small mistake with a circular saw could be the last thing you ever do in your life"

Re: Enough with the JavaScript already

#139
post #88

This slideshow lost all credibility when it said to put your analytics in the tags. Sure some analytics providers might recommend you do that, but that is wrong and only serves to A) Slow your site down B) Introduce a single point of failure into your webpage All scripts should be loaded either async or at the end of the dom.

If you load the analytics script anywhere other than the head, you potentially miss user input while the page is loading. For a slow-loading page, this could make you lose out on useful data. I realize that this argument is somewhat circular.

You should avoid including script tags in the head because it introduces single points of failure in your app. Losing a few ms of 'analytics' time is better than providing your users with a broken site because your analytics scripts (or any other hosted JS files) didn't load and waited 5-15s to timeout (depends on browser).

Steve Souders gives a great talk on this: http://www.stevesouders.com/blog/2010/06/01/frontend-spof/

Re: Enough with the JavaScript already

#140
Many sites already use Google's hosted javascript libraries for JQuery, Prototype, etc...

Could Google reduce load time in Chrome by building these into the browser, so that anytime they see the include pointing to Google CDN, they just skip it and let the pre-included library take its place?

Post reply on HN