JavaScript as default language and software stack

http://blog.andreipolmolea.com/you-should-choose-javascript/

by vladaionescu • 11 years ago

55 65 11 years ago

blog.andreipolmolea.com

mercurial2• 11 years ago

It's a matter of opinion. If you get used to strongly typed languages, the idea of having your entire application in something barely typed like Javascript feels horrifying. I may be able to tolerate Javascript-with-a-typesystem (for instance, typescript), but raw JS? I don't see why you'd ever want to do that.

mizzao• 11 years ago

I think you just solved your own problem.

octaveguin2• 11 years ago

TypeScript has a lot of holes.

What I'd like is a language I can use that has optional typing where all the libraries follow a strict type system but the application I put on top of it doesn't care.

That is the exact opposite of what I get with TypeScript. I'm left with a lot of dynamic mess libraries that I build my typed application on top of.

Steel on top of jello.

zaczac2• 11 years ago

if javascript is ok to be primary language, why choose another wrapper language to make it feasible? it is totally a disaster design in Javascript and the wrapper language should not bail out Javascript. Instead, just let javascript die.

jsprogrammer2• 11 years ago

I believe there is already work on type inferers and static analyzers.

Stripped down, functional C with type inference? Yes, please.

kaendfinger4• 11 years ago

All of which are going to be mediocre because JavaScript is a very hard language to simply reason about for machines.

Drup2• 11 years ago

How about a language that is not shit instead ?

Javascript is the C++ of web dev. You bolt a ton of things on top of a shitty language and you hope to obtain a slice of it that is decent in the long run. Except it's still going to be full of terrible quirks and 30 ways to shoot yourself.

I'm sorry, but I don't want this future for programming.

smacktoward2• 11 years ago

I think part of the author's point is that JS has now achieved so much critical mass, so to speak, that in the not too distant future it's just going to be the programming language. Being a programmer will be synonymous with writing JavaScript. So it doesn't really matter how you feel about JS per se; it's the language all the tooling will be built around, it's the language young programmers will have learned in school, it's the language that the people who cut the checks will assume by default you'll be using. So justifying using anything else will be an increasingly difficult uphill struggle as you fight against all these factors.

rjbwork• 11 years ago

Which will be the day I leave the field. It's okay to toy around with, and decent for some DSL type things, but I think it an absolutely insane proposition to write a few million line codebase exclusively in JavaScript, especially when dealing with sensitive data, complex data structures, and complicated algorithms.

vezzy-fnord• 11 years ago

Being a programmer will be synonymous with writing JavaScript.

I think you should start laying off HN, in all honesty.

s_kilk2• 11 years ago

that in the not too distant future it's just going to be the programming language. Being a programmer will be synonymous with writing JavaScript.

chortle

Not so long ago they were saying the same about Ruby, and Java before that, and so on down a long and winding history of ludicrous one-language-swallows-the-world predictions.

kaendfinger4• 11 years ago

I disagree with some of your points. We tried writing a big web app in JavaScript, and we were extremely sad to see how hard it is to maintain JavaScript code. I like IDE support as well, and JavaScript provides terrible type inference, clear defined structures and other things needed to get it right. People argue that there is Definitely Typed and other things that provide type interfaces for libraries, but it kinda reminds me of header files in C/C++, because it's not defined with the code. We ended up using Dart because of it's interesting take on Web Development (It doesn't just give us the DOM APIs, it improves them and does the polyfilling and that stuff for us). We have been doing this for multiple years and have had a great success. Also, I have strong opinions about JavaScript, including that it looks like a monkey made it, and that someone literally took all the bad things from other languages and put them together. All in all, it's a matter of preference. I've always gone against the crowd too (I think React is just meh, which is not popular), so there is that.

arenaninja• 11 years ago

Though I like React, I agree with the rest of your points.

I've done small-ish projects in Node. There's tons of ways to do JavaScript that your IDE's static analyzers will not like. If you use IIFEs extensively, most of it will not be auto-completed for you. Needeless to say, same thing goes for function signatures -- good luck quickly getting through the parameters and their order (note: it's possible this has changed in the last 12 months).

I like JS well enough -- the functional aspect of strings, arrays, etc. But IDE support is lacking and it makes it hard to retain control as the codebase grows.

drinchev• 11 years ago

Yep, I totally agree with you. This changed for me since I switched to TypeScript. It really makes your code "look" and act more professionally.

ghc• 11 years ago

The IOT argument is specious and betrays a lack of understanding the challenges in connecting devices; specifically, the choice of controlling language begins at a lower level of the stack. New languages will arise, but they will be statically typed and speak protocols like LonWorks. Don't confuse hobbyist kits that are well suited to JS for actual, useful-in-production programming stacks for IOT.

kaendfinger4• 11 years ago

My company works on an IoT Platform for connecting services and devices together, and I agree. We have found that JavaScript is a poor choice to target. We focus on a language-independent structure. In the real world, nobody is using JavaScript to power anything useful on small devices, it just doesn't fit well with an embedded system.

lojack2• 11 years ago

This starts with the blanket statement that you should always use javascript when starting a new web project and then follows up with two examples of using javascript in non-web environments.

While I agree that Javascript has matured a lot, and it has its place in the backend, I strongly disagree that it should always be used. We need to give thought about why we're using it and make it a conscious choice. It can be that its a single language on the frontend and backend. It can be the abundance of developers. It can be it's evented nature. But blindly making a choice without thought leads to a cargo cult mentality.

Additionally, there is no replacement to backend code. We may one day have good enough abstractions to allow us to mostly forget about the backend, but it will still be there. Bugs will arise where we need to understand how it works, and there will always be some sort of API (whether hidden or not) that we need to be mindful of. The web is a client-server system, and we can't forget that.

erikpukinskis• 11 years ago

"Default to JavaScript" is not "use JavaScript".

lojack2• 11 years ago

Yes, I agree, if I "Default to javascript" then I'm evaluating options and picking Javascript in the absence of a clear choice.

However, if I "Always default to javascript" then I'm picking Javascript without evaluating any other options.

phaedryx3• 11 years ago

"This is not likely to change in the next couple of years while waters still settle. But generally the downsides of using JavaScript are fewer and fewer."

"Give the community time, and they will come up with solutions to most things that are considered impossible today."

Okay, so JavaScript will be better/awesome in the future. I still don't see why my next project should be in JavaScript.

Every time I try to get into full Javascript, I come across so many things that feel half-baked that I decide to wait it out some more and go back to the tried-and-true tools.

notNow3• 11 years ago

Can you please enlighten us and name some of those "half-baked" features you frequently encounter in the language?

phaedryx3• 11 years ago

It isn't the language itself. I actually like ES2015 and I'm looking forward to improvements. It is digging through NPM trying to find a decent library. It is trying to reconcile versions of node. It is the feeling that everyone it trying to follow the latest hotness.

I think that there will eventually be an abandoned javascript library for every noun, verb, and adjective in the English language.

Dirlewanger• 11 years ago

I love when the satire just beats you over the head.

omouse• 11 years ago

The hard part isn't implementation or building; it's requirements and design. If JavaScript as a default language and software stack gives me more time to design and gather requirements, then hell yes let's do more of it. If it doesn't, well it's about as good as other languages and possibly more dangerous (yay for lack of types -_-)

interdrift• 11 years ago

C# dev here. Coming from statically typed language + dynamic support it just doesn't make any sense to switch to full dynamic.

octaveguin2• 11 years ago

My latest project has been in C# (unity) and it's the first time I've used the language.

It's a breath of fresh air even coming off of using python/django for the last few years.

Types are amazing.

Touche5• 11 years ago

Back when I did C# I found trying to do functional stuff painful. Maybe it's gotten a bit better, but I recall creating functions being something like

  new Func<int> => { stuff here .. }

Or something like that. I found moving to dynamic languages to be a breath of fresh air. I never cared too much about code completion and stuff like that.

douche3• 11 years ago

Lambdas and LINQ has made this much simpler:

var foo = (param, anotherParam)=>{ /* do stuff */};

bratsche• 11 years ago

If pain is measured in keystrokes, then yeah.. functional C# might be somewhat painful.

If you haven't tried it you might consider using F#. It seems to have the best of both worlds. It's got a static type system with functional features, but also a very lightweight and beautiful syntax (heavily influenced by OCaml, fwiw).

TheCoelacanth• 11 years ago

That's one way to do it, but the typical way is identical to ES6: `() => expression` or `() => { statements }`

vans4• 11 years ago

Ahah, nice joke :)

wslh• 11 years ago

It seems the author forgot to mention one area where server side (read NodeJS/io.js) JavaScript really sucks: debugging.

It's incredible slow to start a debugging session, making you feel miserable. See open issues like https://github.com/nodejs/node/issues/877

Instead of arguing in favor of JavaScript as the default language and software stack we should focus on a standard VM to use the language and libraries we prefer.

nstart• 11 years ago

Not sure if trolling but... If not trolling, you should always learn how to evaluate what language will be the best tool for the job. If anyone's choice of what language to use is based on a blog post that says "You should use JS" then language choice might be the least of your worries. I'm aware of core contributors of one of the hot new JS frameworks that are swapping out pieces of the back end JS tech for Golang because it makes sense! So this isn't just me pulling nonsense out of a hat.

That said, should you learn JS? Hell. Yes!

eterpstra• 11 years ago

Which hot new JS framework, and what part?

mwcampbell• 11 years ago

it will be the standard language for mobile apps.

For second-class mobile web apps, maybe. But for high-performance native mobile apps that don't waste battery life on interpretation or JIT compilation, plus the overhead of bridging to the native APIs, a dynamically typed language like JavaScript is a bad fit. On iOS, Objective-C has always been compiled ahead-of-time to native code, and so is Swift. Android 5.0 introduced AOT compilation with the Android Runtime. And Windows Mobile has it too, with both C++/CX and .NET Native. Conclusion: All three major mobile platforms prefer AOT compilation, which AFAIK isn't feasible with JavaScript.

ChicagoDave• 11 years ago

TypeScript is probably a better long-term programming tool and is aligned with future EMCA Script specifications.

Back-end I'm torn. I love Restify (Express without the web parts and just the api parts). But I also like ASP.NET Web API a lot too. They both have sizable benefits.

I think it's less about language though than architecture. Microservices and user-driven UX is the future along with stakeholder-driven agile project management.

zaczac2• 11 years ago

don't waste your time doing thing big in javascript.

voidr• 11 years ago

Turns out, the amount of work that has gone into making JavaScript awesome surpasses every other language.

I still don't see a Ruby on Rails, Symfony, Spring etc.-like framework for JavaScript in terms of maturity. Sure they are some frameworks, however most of them crash and burn when you want to upload a 1GB file or parse large JSON data arriving via HTTP... or try to extend it.

And I didn't even mention NodeJS's multiple loading and memory limit problem.

scandox• 11 years ago

Hi, my name is __________ and I'm a mediocre programmer.

I've just kicked off the first 2 weeks of a significant project using only Javascript. This was entirely my own choice. I knew I'd have to write a lot of JS in the browser. So it made sense for me to bite the bullet and try to become as good as I could at JS. Equally I had to make a choice that I believed would work for my client in the medium-term, especially if I was not able to continue with the project at a future date.

This is my perspective (from the intellectual gutter): Javascript is hard to read and hard to reason about. It's also hard to achieve a style that I am entirely comfortable with. It's changing very fast. You learn things on the backend that are years from being universally useable on the frontend. Also: I seem to write so many lines of code.

That said I think I made the right choice. Ultimately the isomorphism argument is correct: at least I'm reasoning about the same kinds of things every day. I just came off 6 months of programming only Elixir and I could have used Phoenix for the backend, but I think I would have found the constant shifts in perspective very disruptive.

Which leads me to my main point: It isn't about the language.

After all, multi-threaded programs in a more conventional language are also very hard to reason about. Shared data is hard to reason about. Immutable data is also hard to reason about (or rather its consequences are hard to reason about). Message passing can also become hard to reason about. Pointers are hard to reason about. Functional composition starts out simple and then...you guessed it: it gets hard to reason about. Once things get to a certain level of complexity, once you get using anything to its full potential you find the place in which it's going to make your head hurt.

And for the plodders among us the answer is: libraries and patterns. Specifically, other people's libraries and other people's patterns.

So my recommendation to anyone that doesn't like Javascript: if you don't have to JS, don't. If you do, at least enjoy the good things:

* Promises: One of those things you only appreciate by trying to do it the other way: http://callbackhell.com/ * ES6: a lot of great features here. Makes an Elixirite feel almost at home: destructuring(pattern matching), arrow functions, generators and iterators * Libraries: Amazing number of libraries. I have barely had to code one really smart thing myself. * JSON: Think in JSON all day - now that's nice. Serializing things to Lists, Maps, Tuples and what have you gets old.

And also read books:

* David Herman: Effective Javascript * Marijn Haverbeke: Eloquent Javascript * Daniel Parker: Javascript with Promises * Douglas Crockford: Javascript, The Good Parts (well actually I found this one hard to reason about :) )...

vans4• 11 years ago

Nice ending ;-)

adamwong246• 11 years ago

Everybody's fighting about why JS sucks... We know JS sucks. We've ALWAYS known JS sucks. It's not a good language. It's the new PHP. And it will never be good enough to make us all happy.

But you know what? It works... well enough. It's fast... enough. It's simple enough that mere mortals can use it. (Which is a strength, not a weakness!) And now, it works EVERYWHERE. You can get shit done with JS and having good JS experience means you can always find work. Maybe one day I'll work on a magnum opus requiring a "real" language but for now, I'll stick with what gets the work done. Because I'm not a rocket scientist, I'm more like a computer plumber. And I bet most of us fall into that category.

I don't have to like it. But I do have to get stuff done. So I use JS.

yongelee• 11 years ago

I want to enjoy the programming language im working with though. I don't enjoy js, but thats where all the work is! makes me sad

vans4• 11 years ago

Using the right tool is an inportant skill. And if you're using javascript on the server side and feel it's right, you dont have this important skill.

carsongross• 11 years ago

I do not agree.

1) Web Assembly will make the programming language you use on the front-end an open choice in web development (and, eventually, mobile). Javascript has very poor support for disciplined management of large codebases, and will eventually be abandoned for more sane languages.

2) Technologies like intercooler.js (http://intercoolerjs.org) will minimize the amount of javascript necessary for the majority of web development (and, eventually, mobile) which will allow you to simply choose the best back end technology for your project without concern for matching a front-end language.

JavaScript as default language and software stack

Related Stories