3 ms·
> I'd actually say for someone completely new (e.g. locked in a basement doing C or Java for the last 20 years), learning Erlang would be far easier than learni
by 59nadir 10y ago
> I'd actually say for someone completely new (e.g. locked in a basement doing C or Java for the last 20 years), learning Erlang would be far easier than learning modern JavaScript and Angular2.
I suppose that might be the case. It feels incredibly counter-intuitive, but it's not inconceivable that the JS frameworks stray that far from "normal JS".
Were I in this situation as a employer (and co-worker, necessarily, not only in a managerial position), I would probably make the decision to use other technologies and compile to JS, in that case. There's very little to gain from using a framework that by necessity is tied to a crummy language if I can skip using that as a source language anyway, and then I'd just go with something sane like Elm instead.
(Bear in mind, this is coming from someone who doesn't actually work with front-end development, so take it with a grain of salt.)
- mattmanser 10y agoYeah, you can really tell you don't work in front-end development from that insane suggestion. What you're suggesting simply isn't practical.
- 59nadir 10y agoImpractical how? I'm curious. Writing JS strikes me as impractical from the get-go. Writing in a managed language that will compile down to JS and give you an escape hatch for when you really need it strikes me as far more practical in the long run. To clarify, what I mean is that someone who can't learn Elm, PureScript, Bucklescript or the like, very likely isn't a very inquisitive person and isn't someone I'd like to work with. On top of that, someone who can't see why you'd want to write in any of those languages instead of JS very likely isn't someone who I would want to work with, for fairly obvious reasons.
- rpeden 10y agoThe AdWords team could have chosen any of a fairly large number of technologies to develop their new front end, but they chose the Dart version of Angular 2 to do so. CircleCI chose to use ClojureScript and Om instead of using React directly. NoRedInk chose to use Elm instead of writing JavaScript directly. Others have chosen ScalaJS. It's not popular in the startup world, but plenty of companies chose (and continue to choose) to use GWT to build their in-browser user interfaces. I worked at one of them back in 2010. I had huge doubts about the Java-to-JS compilation process. I'd mostly only seen ugly GWT apps cobboled together from the UGLY base components GWT shipped with. As it turned out, we were able to created our own good looking components quite easily. So long before Angular or React existed, we were able to create a nice an easy to understand component based web app, with business logic split out into services and wired together with dependency injection. It ended up being a sane choice that enabled us to continue developing safely and sanely as the app became larger, and it performed very well on both desktop and mobile browsers. GWT wouldn't be my first choice (or second, or third) in 2016, but it ended up being a pretty good one in 2010. I'm not saying that choosing a compile-to-JS language that has very different semantics than JS is necessarily sane and practical. But I think that plenty of real world successes demonstrate that this choice can be simultaneously sane, practical, and successful.