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

JavaScript is not suitable for large web apps

blogs.adobe.com

Post reply on HN
Print view View original

61–70 of 218 posts

Re: JavaScript is not suitable for large web apps

#61

Post by pooriaazimi »

jwoah12 wrote: post #3

As I read more of these arguments, it makes me think a lot about whether I should switch to CoffeeScript before my web app gets any larger. Has anyone switched to CS or another language that compiles to JS, and regretted it?

I don't know what this article is about (looks like it's not worth reading), but I've switched to CS (IcedCoffeeScript, to be precise) for my Node.js app (a behemoth of an app!), and am much much happier. Sure, it has problems too, but they are more tolerable than having to do (if typeof(x)=='function' && x!=null) over and over again IMO, and the vast majority of them will be gone when we have SourceMaps (which shouldn't take long, maybe a couple more months).

Re: JavaScript is not suitable for large web apps

#62

Post by MartinCron »

mistercow wrote: post #23
marknutter wrote: post #2

This is more of a rant against dynamically typed languages than against javascript itself, and making the argument that dynamically typed languages are not suitable for large web apps is a difficult (not impossible) one to make. The author also complains about some javascript projects being split up into enough files, which is hardly a side-effect of using javascript. The author inherited what sounds like a pretty di…

I also find objections like the "createBunnyOrToaster" antipattern to be really, really uncompelling. You don't need a static type system to make sure that your functions are sane and consistent, and you don't have to be John Resig either. First of all, put a comment at the top of your function that says what to expect about the return value. You should be doing this anyway because the return type alone is often not…

put a comment at the top of your function that says what to expect about the return value.

Great, so now the documentation for the function will promise to return a motorcycle, but instead return either a bunny or a toaster.

There are lies, damn lies, and boilerplate code comments.

Re: JavaScript is not suitable for large web apps

#63

Post by pooriaazimi »

hellopat wrote: post #13
jwoah12 wrote: post #3

As I read more of these arguments, it makes me think a lot about whether I should switch to CoffeeScript before my web app gets any larger. Has anyone switched to CS or another language that compiles to JS, and regretted it?

I haven't used coffee script myself, but I think you'd be hard pressed to find someone that wrote something in CoffeeScript and regretted it. The biggest arguments against using CoffeeScript (or any language that compiles to JavaScript) that I seem to keep hearing are: 1. JavaScript isn't a very readable language. (I think this is untrue. I've seen some incredibly well written / structured JS) 2. Not everyone knows C…

3. (biggest problem IMO): debugging in CS sucks right now. It would be a no-problem with SourceMap though, so we have to endure it just a few more months.

Re: JavaScript is not suitable for large web apps

#64

Post by kevincennis »

mattdeboard wrote: post #32

>Splitting up the code into multiple files enabled us to scale the project. I really don't get this at all. More files == more scalable? Someone more knowledgeable about ... whatever topic is relevant here care to explain this to me?

I tend to like having discrete modules of code split up into separate files when I'm building large JavaScript apps (which is really all I do). It helps keep me organized. And I think it also makes version control run more smoothly.

Generally, I'll write a little build script in Node that concatenates and minifies all my JS and CSS before actually deploying to production to keep the number of HTTP requests down.

Re: JavaScript is not suitable for large web apps

#65

Post by apl »

Arelius wrote: post #46
dxbydt wrote: post #30

For a certain definition of "large" and for certain domains ( especially finance ) his argument is very, very valid. 200 average developers working with GWT->JS are anyday going to be more productive than coding native JS to get the same functionality. This isn't anti-JS...end of the day if you are on the web your code is JS. Thing is, how do you get there - do you hire 20 pricey smart JQuery guys, or 200 average Jav…

> 200 average developers This is the problem, and as you implicate, the exact sort of thing we need to stop doing.

  > This is the problem, and as you implicate,
  > the exact sort of thing we need to stop doing.
You do see the absurdity here, right? Banking on substantially above-average developers doesn't work at scale, by definition.

Re: JavaScript is not suitable for large web apps

#67

Post by mistercow »

munificent wrote: post #31
mistercow wrote: post #23

Earlier quoted context omitted.

I also find objections like the "createBunnyOrToaster" antipattern to be really, really uncompelling. You don't need a static type system to make sure that your functions are sane and consistent, and you don't have to be John Resig either. First of all, put a comment at the top of your function that says what to expect about the return value. You should be doing this anyway because the return type alone is often not…

> You don't need a static type system to make sure that your functions are sane and consistent, and you don't have to be John Resig either. Right, and you can do structured programming in assembly. But when the language or tools don't help you do that, there are examples like the one the author points out where developers don't. Don't mistake utility (what can be done) for usability (what is easy to do). Usability al…

> First of all, put a comment at the top of your function that says what to expect about the return value.

I want a language that gives me a nice pleasant syntax for doing that.

And I want a magic pony; but as I said, declaring the return type doesn't tell users anywhere near all they need to know in many cases. Truly self documenting code doesn't exist, and will probably never exist. And since you can't usefully discuss the return value without implicitly disclosing its type in the comments, declaring the type in the code is redundant.

Now granted, there are a few nice features that you get in terms of debugging by declaring the type in a way that the computer can read. But I don't think I have personally ever actually run into a bug in a dynamically typed language that would have been avoided by a static type system.

Conversely, there are some nice things you can do when the compiler isn't breathing down your neck to make sure that all of your types are consistent. If we had a static type system that allowed me to do elegant, type-agnostic things without getting in my way, that would be lovely. Haskell comes close, but even it falls short of the ideal. Ultimately I have never found the trade off to be worthwhile.

As a programmer, you should be trained that when you see "every time", you think "automate this".

I think that's pretty specious. You do need to consistently check to make sure that your code matches your comments and documentation. You simply can't automate that because humans and computers do not speak the same language.

Re: JavaScript is not suitable for large web apps

#68

Post by Zimahl »

orthecreedence wrote: post #40

"Help! I don't know how to organize code in intelligent ways! This is the fault of the language we originally decided to use!" I have to say after writing "large" web apps in PHP and also in 100% JS, I much prefer JS for front-facing stuff. I've not found organization to be a big issue...but maybe this is due to the fact that I use a JS framework for most of my larger apps (but then again, I did in PHP as well). Like…

"Help! I don't know how to organize code in intelligent ways! This is the fault of the language we originally decided to use!"

The problem might not be you. Once you are done with your organized code and are moved to another project, some 'junior' dev gets a hold of your stuff and makes simple mistakes that static-typed languages could've avoided.

I'm not anti-JS btw, just throwing out one possibility.

Re: JavaScript is not suitable for large web apps

#69

Post by heretohelp »

dxbydt wrote: post #30

For a certain definition of "large" and for certain domains ( especially finance ) his argument is very, very valid. 200 average developers working with GWT->JS are anyday going to be more productive than coding native JS to get the same functionality. This isn't anti-JS...end of the day if you are on the web your code is JS. Thing is, how do you get there - do you hire 20 pricey smart JQuery guys, or 200 average Jav…

>20 pricey smart JQuery guys

See, this is how I knew you knew nothing about JavaScript.

My bets, you're a manager that manages shitty Java coders who "used to code" and is an obnoxious know-it-all.

Scale of 1-10, how close am I?

Edit:

From your website: "currentlly: BofA" (sic).

Feeling pretty warm on my bet so far.

Re: JavaScript is not suitable for large web apps

#70

Post by mixitup12 »

_delirium wrote: post #11
marknutter wrote: post #2

This is more of a rant against dynamically typed languages than against javascript itself, and making the argument that dynamically typed languages are not suitable for large web apps is a difficult (not impossible) one to make. The author also complains about some javascript projects being split up into enough files, which is hardly a side-effect of using javascript. The author inherited what sounds like a pretty di…

Yeah, this doesn't add a whole lot to the debate imo. I'm vaguely sympathetic to the argument that languages with more/better static analysis are better for large-scale development, but that particular argument has a whole lot written about it, and is probably still inconclusive.

Also, define large scale. Plenty of large scale applications can and are written in languages like Python.
Post reply on HN