Why do people post such rubbish and how the hell does this get 100 points? This kind of content can damage young minds.
It should have the HN equivalent of reddit's NSFW tag..
JavaScript is not suitable for large web apps
101–110 of 218 posts
Re: JavaScript is not suitable for large web apps
#102Earlier quoted context omitted.
So so true. If you are hiring "pricey smart [sic] jQuery guys" then you're probably doing it wrong. You need to be looking for solid software engineers that know javascript well. If the developers you are hiring think (jQuery === javascript) and can't explain the difference between classical and prototypal inheritance , then you're screwed before you even begin.
Good to know somebody understood what I was talking about. This is why I don't ask for a "jQuery" guy, I ask for a frontend engineer who's a solid programmer and likes working on interesting products.
I dislike the term frontend engineer or frontend anything because people use it to mean a whole range of things between JavaScript programmer, web designer, and HTML/CSS scripter. And while some people possess all three of those very different skills they are not at all the same thing.
Re: JavaScript is not suitable for large web apps
#103Earlier quoted context omitted.
Good to know somebody understood what I was talking about. This is why I don't ask for a "jQuery" guy, I ask for a frontend engineer who's a solid programmer and likes working on interesting products.
I dislike the term frontend engineer or frontend anything because people use it to mean a whole range of things between JavaScript programmer, web designer, and HTML/CSS scripter. And while some people possess all three of those very different skills they are not at all the same thing.
[deleted]
Re: JavaScript is not suitable for large web apps
#104"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.
Big surprise: junior developers who've only been taught to architect for statically typed language are lost in dynamic languages.
Re: JavaScript is not suitable for large web apps
#105Though I understand what the author meant, I had to giggle a by when I read "don't use JavaScript... Use a high level language"
Re: JavaScript is not suitable for large web apps
#106Re: JavaScript is not suitable for large web apps
#107Earlier quoted context omitted.
> 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 dis…
> declaring the return type doesn't tell users anywhere near all they need to know in many cases.
It doesn't declare all they need to know, but it covers a good fraction of it. As a really nice bonus, it's machine checkable.
> And since you can't usefully discuss the return value without implicitly disclosing its type in the comments
I don't seem to have this problem. I have lots of comments that are like:
// Copies [from] to [to].
copyFile(File from, String to) { ... }
> 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.
I actually get to perform this experiment all the time. I work on Dart. Dart has fully dynamically-typed runtime semantics, but also an optional static type checker that the Dart Editor uses to give you static warnings.
Up until recently, I've mostly write my code in a plain text editor. I do write type annotations, but I get no static checking whatsoever. They're basically comments.
Now that I'm using the Editor more, I can open up codebases I've written that were blind to static type checking and see what kinds of warnings it finds. I get some false positives (i.e. the bug is in the type annotation, not the code), but I also find a disheartening number of legit bugs, and this is in code with good test coverage.
I like dynamically-typed languages, but it turns out the static typing people aren't crazy: it really does find bugs.
Re: JavaScript is not suitable for large web apps
#108For 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.
I'm not happy that the top reply to the top comment on this post is a blatant ad hominem.
What's your point about JavaScript?
Re: JavaScript is not suitable for large web apps
#109Earlier quoted context omitted.
> 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…
Unfortunately static typing doesn't really fix the automation problems that are most common in software development any better than anything else. I wouldn't mistake a personal preference for static type systems and large complex IDEs for superiority of language or productivity.
I wouldn't mistake an appreciation for static types with a preference for large complex IDEs or a statement of language superiority. I work mostly in a text editor in a language whose static type system is far from mandatory.
Re: JavaScript is not suitable for large web apps
#110This is utter tripe. It goes from saying don't use javascript to use a high level language that translates down to javascript. His main example of why javascript isn't suitable is an anecdote about a badly developed code base written in javascript. Seriously?
Don't write programs in assembly. Use a high level language that translates down to assembly. Yknow, most every language ever. If you had read the article, you'd see that the author made this comparison.
It's a false analogy. Javascript is just as high level as Java or CoffeeScript.
Sure, it's the "assembly language of the web," but Javascript certainly cannot be compared to assembly language in this way.