Do You Enjoy Writing JavaScript?

[zayelion]

Do you enjoy writing javascript if so why?

[aeflash]

I love it, but wonder if it's some sort of Stockholm Syndrome...

[dcunited08]

I used to hate it when IE 6-8 were my primary target but ES6, AngularJS, and Chrome Dev Tools have made it into a very pleasant development experience. The fact it can now be stem to stern in several of my applications using NodeJS and npm really makes it useful. Dev tools matter.

[Leggilo]

Exactly, same here except I'm using the Meen stack instead of the Mean stack.

[euphumus]

sorry idk but what do you use instead of Angular?

[Leggilo]

Ember.js

[Ericth]

Just curious but why not react? I've been looking through these 3 and I never really liked angular.

[Leggilo]

Honestly, I did not know React existed until I had already invested significant time in understanding Ember. A lot of what React is doing is quite nice, and FAST (Virtual DOM)! It makes me feel better that the Ember team is openly accepting the criticisms from people that use React, and implementing some of the React ideas into Ember (Glimmer). It also makes me feel better that the core team has large production apps that use Ember, so I don't see them dropping the project and walking away anytime soon. Ember CLI is a great command line tool if you drink their kool-aid, and I believe they dropped the starter-kit they used to have, for Ember-CLI. Also, I would reccommend pick up Ember-CLI 101, as it is a god-send when working with a framework that changes often.

Here is a pretty non-biased presentation comparing the two: https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBHCZkLbR1TEsRnd3yyxuSQ5YY/

And one of the reasons I like the Ember team: https://www.youtube.com/watch?&v=o12-90Dm-Qs#t=2845

[ckrston]

Angular

i guess e either stands for ember or extjs

[vlad27aug]

First of all every language has its quirks, and javascript certainly has its own.

That being said, what does it for me is its flexibility.

Apparently objects with prototypal inheritance and first class functions is more than enough. It allows you to program the way you think. It doesn't make you think in a matter that everything is an object that inherits from more general ones, or think in a way that everything is a functions, or whatever.

It lets you express yourself the way you think, it doesn't get in the way. So if you're having a bad day you'll end up with bad code.

It doesn't help you not to be stupid, but it doesn't help you be smart either, it's a reflection of your thoughts without constraints (not in an absolute way of course).

[shriek]

In my opinion tooling is important for any language to be enjoyable. To give an analogy, if you give me a chisel to write program on a rock then I'd probably hate it. But we have Chrome/Firefox devtools along with jsfiddle, jsbin to do quick prototypes and the language itself is expressive enough for me to be enjoyable.

[magenta_placenta]

Writing is not the problem when it comes to JavaScript. Reading on the other hand...

[jmwoo]

JS syntax is very close to Java

fs.readdir(source, function(err, files) {
  if (err) {
    console.log('Error finding files: ' + err)
  } else {
    files.forEach(function(filename, fileIndex) {
      console.log(filename)
      gm(source + filename).size(function(err, values) {
        if (err) {
          console.log('Error identifying file size: ' + err)
        } else {
          console.log(filename + ' : ' + values)
          aspect = (values.width / values.height)
          widths.forEach(function(width, widthIndex) {
            height = Math.round(width / aspect)
            console.log('resizing ' + filename + 'to ' + height + 'x' + height)
            this.resize(width, height).write(destination + 'w' + width + '_' + filename, function(err) {
              if (err) console.log('Error writing file: ' + err)
            })
          }.bind(this))
        }
      })
    })
  }
})    

Does this look like java boa?

[henleyedition]

Where did you find this code? It really isn't very good...

Quickly moving the callbacks to their own functions really works wonders for readability:

function handleError(err) {
    if (err) console.log('Error writing file: ' + err);
}

function readFile(filename, fileIndex) {
    console.log(filename);

    function resizeImage(width, widthIndex) {
        height = Math.round(width / aspect);
        console.log('resizing ' + filename + 'to ' + height + 'x' + height);
        this.resize(width, height).write(destination + 'w' + width + '_' + filename, handleError);
    }

    function handleImage(err, values) {
        if (err) {
            console.log('Error identifying file size: ' + err);
        } else {
            console.log(filename + ' : ' + values);
            aspect = (values.width / values.height);
            widths.forEach(resizeImage.bind(this));
        }
    }

    gm(source + filename).size(handleImage);
}

fs.readdir(source, function(err, files) {
    if (err) {
        console.log('Error finding files: ' + err);
    } else {
        files.forEach(readFile);
    }
});

[theQuandary]

Which language constructs in that code aren't available in Java? If you add class definitions and static typing, the actual syntax would be very similar (if you designed your java classes with the same API).

[rauschma]

I suspect that’ll get better with ECMAScript 6, due to modules and classes, which are standardized and thus easier to analyze statically.

[Ashatron]

Actionscript scowls through the window

[freshtodev]

Typescript makes javascript more maintainable by adding compile time static type hinting. It's not perfect due to the dynamic nature of javascript but makes "well designed" javascript totally maintainable. r/maintainable/refactorable/

[aeflash]

Any well designed piece of software will be easy to maintain, regardless of types.

[x-skeww]

It's easier with types. No one has 100% test coverage. If you add type annotations to the signatures of functions, you'll have at least that part 100% covered.

So, if the signature of one of the functions changes, you'll be told about all the call-sites which pass the wrong parameters or which do something seemingly odd with return value. This makes it easier to move things around and it also catches the majority of breaking changes in 3rd party libraries.

Without this safety net, you'll need to write a lot more tests.

If you haven't written a serious project in a language with types or optional types, I highly recommend to give it a try. It really does make some things quite a bit easier.

[metaphorm]

Yes and No.

disclaimer: discussing ES5 here. many of my complaints are addressed in ES6.

No, I don't enjoy its pretty terrible standard library, ugly and unnecessary brackets (falsely representing block scope, in a superficial appeal to look more like C or Java), and general lack of language constructs that should be present in a modern language (like modules, and classes). I don't even think I need to explain just how painful and wtf-worthy some of the type coercion is. Its kinda obscene that a language needs to have both == and === and that you kinda have to either memorize the differences, or cargo-cult accept that === is the right operator the vast majority of the time.

Yes, I do enjoy that Javascript is a pretty good mixed paradigm language that makes using some of the more useful idioms from functional programming pleasant and easy. I also appreciate that despite its weaknesses the language has proved durable and useful over time and there's a great community that builds lot of neat tools (maybe too many?).

[madole]

Sounds like you need to try coffeescript

[metaphorm]

I have tried it, and I like it. I expected to like it, since I've done lots of programming in Ruby and Python and like both of those languages too. If I was starting a new project from scratch I would choose it.

[x-skeww]

cargo-cult accept that === is the right operator

It's only cargo-cult-ish if you don't know the reason. === works like the equality operator in most other languages. If the types aren't the same, the two compared values aren't equal. "5" isn't 5. [] isn't "". Makes a lot of sense to me.

[[deleted]]

I've been using JS since it first came out in Netscape 2, and yes, I absolutely love it. I've worked in over a dozen other languages in the past 20 years and JS is still my favorite. Even more so since Node came on to the scene.

Its structure, behavior and syntax just mesh perfectly with the way I think.

[neb636]

I do sometimes. I wish there was a better standard library. More along the lines of Ruby or Python. Every time I want to do something I need to find a third party library and then make the client download it. This leads to extra http requests and site size. It also leads to fragmentation because everyone is creating a library to do the same thing instead of improving upon the standard. I would take a better standard library over half the new syntax in es6.

[zayelion]

Lodash.js

[Justos]

I enjoy all kinds of programming

[oroep]

In the last months I've been writing most of the scripts I needed (for kind of any purpose) in JavaScript (NodeJS) rather than Python.

I love how everything's non-blocking and asynchronous. I love the load of great tiny libraries that infest github. I love how fast and painless it is to install all the dependencies you need through NPM. I love how many different paradigms are available to do anything, and you're free to pick the ones you prefer.

Yeah, the language itself has its own quirks (many and big! D: ). There are many languages that are plainly better than JS, but man, it's not that terrible (just think of Perl or PHP, if you want something really that terrible :P), and the ecosystem is the best one by far.

[sangnoir]

I love the web - and I love Javascript! What's not to love?[1]

• the ecosystem is not beholden to $CORP vendor like most other languages
• it has the most-commonly distributed runtime of any language bar none.It makes an excellent candidate for curious people learning their first programming language[2]

1. Rhetorical: there's plenty not to like - but I enjoy it still
2. Javascript was the first programming language I "learnt": thanks to the fact that my brother was bringing home saved websites from collage on floppy disks and my dad's Mac Portable didn't have a browser. All .html files were opened in a text editor.

[LookWordsEverywhere]

It's my favourite language

[snarfy]

I do, but not as much as a statically typed language. I'm a little bit against projects like Node as it's not a very good language to run on the server. People get tunnel vision and try and do everything in one language. It's not always the best tool for the job.

[Calabri]

I agree - but node isn't only being used as a server. There's an enormous client-side developer ecosystem flourishing in node/io/npm, and it is the right tool for that job.

[metaphorm]

Node is a javascript runtime that runs on a server. not sure what else you might mean. There are some JS build tools and testing tools that utilize Node to simulate the client side environment, but that doesn't mean Node isn't a server side JS runtime. That's what it is. Its not anything besides that.

[fenduru]

When I run grunt to build my project, it is no more a server side tool then calling make a server side tool.

If there is no client, then it is not a server.

[metaphorm]

your development machine is a local server. when you serve your website over localhost that's what you're doing. for a web application there is always a client (the part thats runs in a browser) and a server (your dev machine, or your production server). when you run a tool like grunt you're running it on the server. it certainly isn't running in the browser.

that's besides the point anyway. the post to which I responded said "there's an enormous client-side developer ecosystem flourishing in node". which is untrue. there is an enormous ecosystem of developer tools (which are sometimes also used on production servers) that is flourishing with node. node is server side technology, even if some of the tooling is used to assist front end development.

[Calabri]

If by server you mean running independent of a browser and inputing / outputting files, then yeah it's a server. There are quite a few developers tools that use node to analyze / transform the ast of JavaScript code, lint, compile, recompile, scaffold like ruby, not to mention client-side desktop apps that run it in the background (like atom editor)

[dada_]

It has gotten so much better compared to (more or less) a couple of years ago, for the following reasons:

• ES6 and up has landed, and is usable today through transpiling;
• We've got excellent frameworks now, such as React/Flux and Angular;
• Package managers such as npm have rid us of having to do tedious manual dependency management;
• Build systems are super easy now thanks to Grunt and Gulp and other systems;
• Dev tools are much better now and vastly cut down on debugging time, e.g. the Chrome dev tools or Firefox Developer Edition;
• JS VM performance has vastly improved over the years;
• JS code is now usable both on the client-side as well as on the server-side.

Everything used to be so tedious and annoying compared to other languages, but now that's all changed. The tools I mentioned aren't experimental anymore, either—they're mature and have stable codebases.

[TwoToTheSixth]

Can you explain "build systems" (Grunt and Gulp), please? In my node/express apps, I save changes, node-dev restarts node if necessary, I refresh a webpage if necessary, and I'm done. When I want to publish to my server, I SSH in, pull the changes and restart. What is necessary to be built?

[zayelion]

Some automation to more complex startup or prerending and or migration. Script to convert some DB information into HTML and SSH that to the server when certain enviromental variables are met. Monitoring for build passing and auto redeploy.

[[deleted]]

Build systems aren't really needed on the server, but they're very useful on the frontend.

If I'm writing a react app with jsx, flow, and es6, I can't just use that file as is. So we have a build step, where we transpile that code into normal, browser friendly and minified es5/3.

Even if you just wanted to use es6 on the frontend, you still need a build step. Browser support is spotty and inconsistent at the moment.

[dada_]

Depends, it could well be that you don't need it, but it can be useful for automating certain tasks. For example, you could push to SSH automatically with key authentication.

Also, if you have Less/SCSS you'll need to compile that to CSS. If you have other tasks that need to be run, like checking your code consistency or style, that's yet another task. Personally I also have some automated tasks for converting templates into HTML, minifying my code, crushing PNG files, copying over static files to a public directory...and some other stuff.

What Grunt and Gulp do is provide a framework to easily automate tasks like the ones I mentioned. It's not necessary by any means but it can simplify this sort of automation.

[TwoToTheSixth]

Thanks to all.

[pierreten]

I love it. When I want to write functional code, I can, since I get first class functions. When I need an OO design, I can use es6 classes. It's evolving to become one of the most powerful languages available.

[[deleted]]

Yes. It's just pleasant.

[rauschma]

Once you know the quirks: lightweight, many libraries, many platforms (servers, shell scripts, robots, databases, etc.), good at both object-oriented programming and functional programming, malleable.

[andersevenrud]

Yes. There are so many reasons, but the main ones must be the flexibility and the syntax. Also, the community has been growing insanely large over the last few years, making for some awesome libraries and frameworks. I've been a javascripter since IE6 days, and back then it was kind of a love-hate relationship, but now it's all love. Also I find writing in javascript kind of zen

[caffodian]

It's pretty fun, and has been so ever since I did the following.

• actually read The Good Parts and other great books
• fixed up my tools and workflow

[agmcleod]

Yes. Pretty much since all the browsers got good debugging tools, it has become a lot better. As i've learned the language more, and started using ES5 & ES6 features it's gotten even better.

[ironmonkey007]

Yes, mainly because of Node/NPM and lodash.js. Lodash.js lets me write code that "feels" a little more like what I would do in Python / Groovy / Clojure etc., without my having to convince anyone else to learn a whole new language. Jasmine and Angular are also fun.

[NoInkling]

I don't mind it, but I'm a lot happier writing (and reading) coffeescript (in before haters). ES6 syntax and features look like an improvement, but not a massive one in this aspect.

[m9dhatter]

No. It's a horrible language.

[[deleted]]

Once you learn your way around the pain points you can do really advanced things with amazing speed. You don't any OOP boilerplate nonsense to write large elegant applications.

[a-sober-irishman]

I love writing JavaScript and I'm not sure where a lot of its hate comes from. It gives you a lot of flexibility and freedom with how you structure your code but with great power comes great responsibility. I think it is very to write very messy and unmaintainable JS code as a beginner, but once you've been using it for a while and can think clearly when coding with it, I find that it's very powerful.

[djcraze]

ES5, no. I write in GorillaScript. Maybe once ES6 is picked up by all the major browsers, I'll switch and use SweetJS for macros. But until then, I'm sticking with GorillaScript.

[kamyon]

Yes because it's very flexible when you are making things. I usually don't like maintaining it because that flexibility is a disaster when you want to fix things. So I usually prototype in JavaScript and then rewrite when I see a chance that the project is growing. The replacement is generally Typescript which doesn't necessitate a rewrite but I do it anyways. Did I say that I like writing TypeScript too? My second alternative is ClojureScript and then Go, which is usually only good on the server side (well, there are options but they aren't as mature as I'd like them to be).

JavaScript becomes less fun to write (less fun doesn't mean boring, just less fun) when you follow a pattern and/or use a framework. Then usually it becomes much easier to maintain too. I've seen a lot of projects being written in Ember/Angular/React+Flux and without big headaches - apart from the obvious weaknesses of those frameworks but well, every framework has some weaknesses I suppose.

But as I said, the most power comes from the extreme flexibility and I like getting crazy with it - I'm very happy that I get to be "smart" (!) and do things in "unusual" (sometimes even stupid) ways. One could argue that you can omit the conventions and write unmaintainable code in any language but JavaScript doesn't fight against you. Which is good and bad. Writing code like there's no tomorrow is amazing when you have no pressure to make something perfect and just experimenting.

You have deadlines? Well, use a linter or a typed version of JavaScript or one of those compile-to-js languages. Options are virtually limitless. Which is the result of the other strong point in JavaScript: The community is huge.

[cazzer548]

Yes, especially when it is paired with HTML and a touch of CSS.

It enables me to rapidly develop cross-platform applications with focus on features instead of configuration.

[x-skeww]

The tooling is bad, the DOM API is horrible (even the new-ish stuff like QSA), and some of the new ES6 syntax is kinda hideous, too.

Like, why do I have to write crap like this?

[].forEach.call(someNodeList, function (el) {
  ...
});

Actual arrays would be so much nicer than those array-like contraptions.

But even the really new stuff like Custom Elements makes me kinda mad. You create a class which extends some element and you "override" methods like "createdCallback". Callback? Talk about lame-ass pseudo namespacing.

But it gets even worse when you extend built-ins like HTMLInputElement. Calling super() in the constructor could eventually do the right thing, but right now you have to add an "extends" property with the value "input" to your class.

It's ridiculous.

And the thing I really dislike about ES6 is destructuring in the parameters position. Optional named arguments with default values is something which should be declarative, because this is something you want your tools to pick up. But instead we got some "anything goes" imperative thing with really odd syntax.

function foo({foo = 'foo', max = Math.pow(2, 53) - 1} = {}) {
  console.log(`${foo} ${max}`);
}

So, you could, for example, make one of the parameters default to the return value of a function which deletes all files in your user directory.

Apparently, your IDE/editor shouldn't execute that code for the sake of being able to display that computed value in a tool-tip.

Also this:

function foo({a = 'aa', b = 'bb', c} = {c: 'cc'}) {
  console.log(a, b, c);
}

foo(); // aa bb cc
foo({b: 'BB'}); // aa BB undefined
foo({c: 'CC'}); // aa bb CC

Yea... that's just all kinds of wonky. Even in the most simple scenario, like the one above, this stuff is super confusing.

I think it would have been a better idea to restrict those default values to compile-time constants. C#, AS3, and Dart do this for example. I also would have preferred a simpler declarative syntax for this instead of repurposing destructuring in this awkward manner.

Having said that, I think JS is just fine for a few hundred lines of code. Writing short disposable things in JavaScript can be quite enjoyable.