Earlier quoted context omitted.
Like
Write intelligent comments that advance the discussion in some way. This is not reddit.
I don't even think that would fly on Reddit.
JavaScript is not suitable for large web apps
131–140 of 218 posts
Re: JavaScript is not suitable for large web apps
#132What's funny is I spent last year porting a Flash app to Javascript.
The Flash codebase had become unmanageable. We found that the majority of Flash developers were used to coding up some advertising banner or something of that ilk and that individuals with experience making large applications didn't know Flash. Our team was mainly Ruby and web front-end guys and we had no clue what the Flash guys were up to.
After the change, our web designers could work directly with the markup and CSS in order to make changes, something that was a nightmare before we switched over.
Was it just Flash? No, it wasn't, it was a number of issues, mainly poor architectural decisions and a lack of vision from the technical leads.
All of these issues disappeared mainly because a CTO was brought on who really knew his stuff.
In summary, it's not the tech, it's the people putting the pieces together, and most importantly, knowing how to organize the people who are putting the pieces together.
Re: JavaScript is not suitable for large web apps
#133This 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…
>making the argument that dynamically typed languages are not suitable for large web apps is a difficult (not impossible) one to make
Is it? And even if it is, why? Because dynamically typed languages are in vogue? Java does fine as a server-side webapp language, as does Dart (on the client too!), as does Go, etc.
Re: JavaScript is not suitable for large web apps
#134Is there any credible data on static vs. dynamic typing?
Yes. A couple of weeks back on either hacker news or reddit (I just searched, and could not find it quickly), there was a seemingly well conducted experiment, with a large number of students randomized to static and dynamic languages, that found no statistically significant difference.
If you look at the HN thread where that paper was discussed, people on both sides were shooting holes in it. That's partly why I'm asking, is there anything solid on this out there at all? People are just repeating the same beliefs over and over. We've all heard them a zillion times and we all divide them into two categories: "shit I agree with" and "bullshit".
What experiments could be done to test these beliefs?
Re: JavaScript is not suitable for large web apps
#135Earlier quoted context omitted.
> 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…
>And I want a magic pony; This magic pony exists. That's what the author is trying to say. You can write magic pony code, and it can be run as JavaScript. Magic Pony -> JS Conversion! Also, the OP doesn't have an issue dynamic languages as much as weak typed languages. It just happens that JS is weak and dynamic, while AS is strong and static. Having switched between Java, ActionScript and JavaScript for the last fou…
> but it's not uncommon for a coworker to check in changes to a JavaScript class that completely breaks a part of the application that the dev wasn't thinking about
You don't need to write unit tests to check the type of each value, you just need to have a decent set of integration tests to make sure you aren't breaking other parts of the app. If errors in the browser after a refresh don't help you catch it, failing integration tests will. This is how we do things on my large scale javascript project and it works out just fine; we have development challenges, for sure, but weak/dynamic typing issues is not one of them.
Re: JavaScript is not suitable for large web apps
#136Compile to JavaScript? It's dangerous if you don't know what it really does in the blackbox. I just wrote a article discussing this topic several days ago. http://bit.ly/M9CSXj
Re: JavaScript is not suitable for large web apps
#137There are reasonable objections to JavaScript, but this is inane.
He uses an example of someone committing a classic mistake in software design. This error would be the same in JavaScript or Java. I'd like to see how his ActionScript translation magically fixed it.
However, the remedies for the mistake differ in each language.
It is somewhat difficult to fix it in Java's statically typed straightjacket (which I assume is similar in ActionScript). The easiest answer might involve a Feedable interface. I looked this up and it's not clear if ActionScript classes can implement multiple interfaces. So if you want your Toaster to be both Feedable and Heatable, get ready for interfaces extending each other.
In my experience most Java developers don't even do that. They don't think about revising their approach to the problem. They going to write a method that does what they want in the class that they want, come hell or high water. They'll create the BunnyOrToaster class which has methods which all contain if/else clauses testing if this in 'bunny mode' or 'toaster mode'.
In a language like JavaScript, you have other, simpler options, and often more powerful ones. I don't know for sure, but the mere fact that there are fewer tricks to learn might mean that it's better for naive to intermediate programmers. The typical JS way would be to rely on duck typing. If that disturbs you, you could implement a 'getFeeder' method on both kinds of objects that returns a closure, which can be executed later. That's what Java might call a 'Strategy pattern', but it's baked right into the language in JS.
Re: JavaScript is not suitable for large web apps
#138As 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 switched to coffeescript but I have worked on several coffeescript codebases. Its not the end of the world, but I don't prefer it. It is an unnecessary level of abstraction and is fragmenting js. It also seems the coffeescript users tend to use haml and sass as well. When I am working on those projects I feel like I am drowning in preprocessors and frequently encounter cryptic errors as a result.
I can't speak for haml, but sass is certainly a welcome tool in dealing with CSS, since it mostly uses CSS syntax, with sensible nesting to keep things orderly. sass takes what you already know and kicks it up one notch (perhaps two, if you want to use variables).
Re: JavaScript is not suitable for large web apps
#139"JavaScript is the browser’s assembly language."
This reminds me of a blog post by @izs
http://blog.izs.me/post/10213512387/javascript-is-not-web-as...
Yes, I love Haskell and I do some CoffeeScript but JS is a fairly decent language to me : )
Re: JavaScript is not suitable for large web apps
#140There are reasonable objections to JavaScript, but this is inane. He uses an example of someone committing a classic mistake in software design. This error would be the same in JavaScript or Java. I'd like to see how his ActionScript translation magically fixed it. However, the remedies for the mistake differ in each language. It is somewhat difficult to fix it in Java's statically typed straightjacket (which I assum…
Algebraic data type