Maintainable JavaScript (2014) • Hacker News Board

Re: Maintainable JavaScript (2014)

#11

Post by blubbi2 » Sat, Jul 16, 2016, 10:25 AM UTC

benjoffe wrote: post #10

He uses the following example for when to throw your own errors: var Controller = { addClass: function(element, className) { if (!element) { throw new Error("addClass: 1st argument missing."); } element.className += " " + className; } }; I don't think this is a very good as a native error will have all this information already in a stacktrace, and if you're running Chrome dev tools with 'Pause on exceptions' then you…

Probably easier to just use an assertion library here. E.g.

  assert.ok(element)

Re: Maintainable JavaScript (2014)

#12

Post by pzh » Sat, Jul 16, 2016, 10:33 AM UTC

Maintainable JS? Har har har

Re: Maintainable JavaScript (2014)

#13

Post by kimshibal » Sat, Jul 16, 2016, 10:45 AM UTC

I handle a big React app at my job. It's messy as fuck with JSX. We made a transition to Vue. Couldn't be happier.

Re: Maintainable JavaScript (2014)

#14

Post by deevus » Sat, Jul 16, 2016, 11:03 AM UTC

Do people still use Grunt these days?

Re: Maintainable JavaScript (2014)

#15

Post by woah » Sat, Jul 16, 2016, 11:42 AM UTC

blubbi2 wrote: post #11

benjoffe wrote: post #10

He uses the following example for when to throw your own errors: var Controller = { addClass: function(element, className) { if (!element) { throw new Error("addClass: 1st argument missing."); } element.className += " " + className; } }; I don't think this is a very good as a native error will have all this information already in a stacktrace, and if you're running Chrome dev tools with 'Pause on exceptions' then you…

Probably easier to just use an assertion library here. E.g. assert.ok(element)

Even easier- typescript or flow

Re: Maintainable JavaScript (2014)

#16

Post by Touche » Sat, Jul 16, 2016, 11:57 AM UTC

woah wrote: post #15

blubbi2 wrote: post #11

Earlier quoted context omitted.

Probably easier to just use an assertion library here. E.g. assert.ok(element)

Even easier- typescript or flow

Adding a build step adds complexity.

Re: Maintainable JavaScript (2014)

#17

Post by gcanti » Sat, Jul 16, 2016, 12:01 PM UTC

blubbi2 wrote: post #11

benjoffe wrote: post #10

He uses the following example for when to throw your own errors: var Controller = { addClass: function(element, className) { if (!element) { throw new Error("addClass: 1st argument missing."); } element.className += " " + className; } }; I don't think this is a very good as a native error will have all this information already in a stacktrace, and if you're running Chrome dev tools with 'Pause on exceptions' then you…

Probably easier to just use an assertion library here. E.g. assert.ok(element)

I wrote a library [1] and a babel plugin [2] (bonus point: is Flow compatible) in order to deal with those cumbersome runtime type checks.

[1] https://github.com/gcanti/tcomb [2] https://github.com/gcanti/babel-plugin-tcomb

Re: Maintainable JavaScript (2014)

#18

Post by malcolmgreaves » Sat, Jul 16, 2016, 12:17 PM UTC

Touche wrote: post #16

woah wrote: post #15

Earlier quoted context omitted.

Even easier- typescript or flow

Adding a build step adds complexity.

No. Using a weak, dynamically typed language adds complexity. Using a compiler isn't adding complexity.

Re: Maintainable JavaScript (2014)

#19

Post by nittr » Sat, Jul 16, 2016, 12:24 PM UTC

can someone summarize it in like 100 words or so

Re: Maintainable JavaScript (2014)

#20

Post by oever » Sat, Jul 16, 2016, 1:27 PM UTC

The code examples use ==, which does lossy comparison. Using === is much safer. The tools section mentions JSLint which flags any use of == as an error.

JavaScript is such a quirky language that I always want the code to pass JSLint and Closure Compiler with 100% type annotation. I simply do not feel confident about the code otherwise.

I'm surprised about the lack of space after 'if'. 'if' is not a function so 'if(' looks weird.