Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enough with the JavaScript already

fr.slideshare.net

Post reply on HN
Print view View original

101–110 of 231 posts

Re: Enough with the JavaScript already

#101

Post by flyinRyan »

cliveowen wrote: post #11

I wonder if there'll ever be an alternative to Javascript. I'm not talking about those things that eventually get translated to Javascript, I'm talking about a native platform well thought-through and based on a typed language that isn't a mess. Yeah, I know: it's not Javascript that's broken, it's the DOM. I'd argue that both should be replaced by something else, otherwise the future will be 90% native mobile apps,…

>Yeah, I know: it's not Javascript that's broken, it's the DOM.

No, JavaScript itself is a ridiculous language. Every time I have to deal with it I grit my teeth. Right now I'm dealing with dates. Luckily JS has a built in Date class! Which, of course, does nearly nothing. If you call "getDay" you get a zero indexed number representing the day of the week. So since there's no formatting functions to print out dates, how do you get the month-day number? Oh, right, you call getDate...

If I didn't know better I would think this abomination were created by someone who thought the secret of PHP's success was being horribly defined.

Re: Enough with the JavaScript already

#102

Post by youngtaff »

d4vlx wrote: post #85

To bad you have to pay $399 to watch the videos. http://velocityconf.com/velocity2013/public/sv/q/479 I realize it costs money to run a conference but that seems excessive.

Here's the version from SF Web Perf - http://www.ustream.tv/channel/sf-web-performance-group-meetu...

Re: Enough with the JavaScript already

#103

Post by weland »

w1ntermute wrote: post #22
weland wrote: post #18

Earlier quoted context omitted.

Objective-C is really nice. I don't like Apple, but their development tools are actually fairly good, and the whole API in iOS is, if not necessarily a beautiful piece of engineering (which is subjective), at least thoroughly-documented and easy enough to learn and use. Android is terribly documented and very messy to develop on. But yeah, it sucks that you can't do cross-platform development unless you like to be ti…

> Android is terribly documented and very messy to develop on. I keep hearing this FUD, but I have no idea where it's coming from. I've never had any problems with the Android documentation. The most annoying part of Android development is probably Eclipse, but I'd rather have a resource intensive IDE that's cross platform than one that only runs on OS X. In fact, the Android platform has some amazing opportunities f…

> I keep hearing this FUD, but I have no idea where it's coming from. I've never had any problems with the Android documentation.

Let's take just one example from literally hundreds that are scattered all over the API reference alone. The delete() method in SQLiteDatabase -- arguably, a mature part of the Android API, considering it's been there ever since version 1 and is something that almost every application uses. Here: https://developer.android.com/reference/android/database/sql..., java.lang.String, java.lang.String[])

The method takes three arguments, but only two are documented. The description of the whereClause states that "Passing null will delete all rows", while the function description says "To remove all rows and get a count pass "1" ass the whereClause". I presume the difference between the two cases is that passing null as the whereClause will delete all rows without giving a count of how many, but that's really poor taste in describing what the function returns.

This simply isn't ok. It's barely enough for internal use, where you'd probably Skype the guy who wrote it, ask for clarification, and kindly ask that they fix it when/if they have time (or you fix it yourself if possible), but this is very far away from what you want from a serious framework. Let's not even stick iOS here. Look at Qt -- which optimistically would have, what, 10% of the users Android has, and a lot fewer developers -- and their documentation is at the very least complete.

Edit:

> The most annoying part of Android development is probably Eclipse, but I'd rather have a resource intensive IDE that's cross platform than one that only runs on OS X

It's definitely Eclipse, but in its description don't forget "unstable" and "still lacking a decent UI builder".

Re: Enough with the JavaScript already

#104

Post by [deleted] »

krosaen wrote: post #28

It's not really an either or thing. You can go too far with client side rendering. But progressive enhancement can only bring you so far in delivering an interactive experience - it's typical that his example is a simple tabs implementation - of course that's easy to do without much js. That's why I like knockoutjs - it makes it easier to sprinkle in the data-bound rich interactive UI to the pieces of your page that…

[deleted]

Re: Enough with the JavaScript already

#106

Post by protonfish »

chii wrote: post #24
cliveowen wrote: post #11

I wonder if there'll ever be an alternative to Javascript. I'm not talking about those things that eventually get translated to Javascript, I'm talking about a native platform well thought-through and based on a typed language that isn't a mess. Yeah, I know: it's not Javascript that's broken, it's the DOM. I'd argue that both should be replaced by something else, otherwise the future will be 90% native mobile apps,…

The mistake, perhaps, is that people (us) are trying to shoe horn an application into a Document object model - its in the name for christ sakes! Document! Not application object model!

Document = application interface. It's a great way to abstract the back end from the front end. Unless of course you mush your business logic in with your interface code.

Re: Enough with the JavaScript already

#107

Post by quacker »

nbevans wrote: post #62
pjmlp wrote: post #37

Earlier quoted context omitted.

I rather use those 5 MB for my application.

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 apps in native code.[1] The killer quote:

"I think the biggest mistake we made as a company was betting on HTML5 instead of native," Zuckerberg said...[2]

Granted, this was a different situation. They were using HTML5, and it looks like Xamarin compiles to native code. You mentioned slightly larger executable sizes, so I'm curious about the performance.

1: https://www.facebook.com/notes/facebook-engineering/under-th...

2: http://www.computerworld.com/s/article/9234695/Facebook_debu...

Re: Enough with the JavaScript already

#108

Post by msluyter »

ebbv wrote: post #71
chewxy wrote: post #53

Earlier quoted context omitted.

I like to think of it this way: Some languages allow you to shoot yourself in the foot easier than other languages, given the context and environment. Abuses and problems precisely show Javascript's defects. The more easily abusable a language is, the more defective it is. A lot can be said about familiarity with the language. Many examples in wtfjs.com boils down to (mis)understanding the language itself. Let's call…

You are 100% wrong. C allows you to shoot yourself in the foot much more easily and much worse than JavaScript. JS is a far more "safe" language to code in. No pointers, no memory allocation. Yeah JS isn't typed but the problems that you get into with that are nothing by comparison. And again, I'm not saying JS doesn't have problems, it does. But the problems this presentation is complaining about are not results of…

The parent probably shouldn't have included C and Python in the same list but if you apply the principle of charity[1] and choose Python as the point of comparison rather than C, then his argument is somewhat stronger.

[1] http://en.wikipedia.org/wiki/Principle_of_charity

Re: Enough with the JavaScript already

#109

Post by eagsalazar2 »

chewxy wrote: post #47
ebbv wrote: 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…

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 that has little to do with JS since you can fall into those pitfalls in any language.

I'm not attached to JS and have pretty much switched to CoffeeScript. I like CS better but that doesn't mean JS is anywhere near as bad as you make it out to be.

Re: Enough with the JavaScript already

#110

Post by nbevans »

quacker wrote: post #107
nbevans wrote: post #62

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

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 that goes on in .NET and Mono land is largely ignored or just swept under the carpet by the hipster community.

The larger executables is because it has to embed the Mono VM, and some base class libraries. I've not really looked into performance versus Davlik; probably because I've not yet encountered any show-stopping performance issues.

Post reply on HN