JavaScript for Line of Business Applications
504.1K views | +216 today
JavaScript for Line of Business Applications
Keeping track of current JavaScript Frameworks that help design your clientside Business Logic Layers.
Curated by Jan Hesse
Beam to my Inbox:
Your new post is loading...
Your new post is loading...!

The Hitchhiker's Guide to Modern JavaScript Tooling

The Hitchhiker's Guide to Modern JavaScript Tooling | JavaScript for Line of Business Applications |

A lot of developers coming to JavaScript world attracted by React.js are confused with the tooling used to produce modern JavaScript code. Webpack, Babel, ESLint, Mocha, Karma, Grunt... what should I use and which tool is doing what?

No comment yet.!

Eliminate JavaScript Code Smells

Eliminate JavaScript Code Smells | JavaScript for Line of Business Applications |
  • Easy to lint, Common rules
  • Easy to lint, Fresh rules
  • Easy to lint, No rules
  • Hard to lint, Subjective rules
No comment yet.!

A Case Study in JavaScript Code Improvement

A Case Study in JavaScript Code Improvement | JavaScript for Line of Business Applications |
Raymond Camden shares how a recent project led him to integrate some workflow tools that helped him improve the quality of his JavaScript code.
  • While writing the JavaScript, I ran into a few bits of code that felt repetitive and seemed ripe for optimization. I intentionally ignored those thoughts and focused on getting the code working. Premature optimization is frowned upon for a reason. Now that the code is released though, I think it makes sense to go back through and look for improvements to the code base.
  • Obviously – and probably more sensible before the optimization, would be the use of unit tests. As this relies upon a remote service, writing tests could be problematic, but even a test that assumes that remote service is running perfectly would be better than no tests. Plus, if I write these tests first, I can then look into code changes and feel secure that I’ve not broken anything.
  • I’m a big fan of JSHint and would like to run it over the code base and make sure it passes that test as well.
  • I’d also like to ship a minified version of the library. To be honest, I’ve never done that before, but if I had to guess, I’d bet there is a command line program I could run to generate that.
  • Finally, I bet I can handle running the unit tests, JSHint checking, and the minification, automatically via a tool like Grunt or Gulp.
No comment yet.!

JSCS — JavaScript Code Style.

JSCS — JavaScript Code Style. | JavaScript for Line of Business Applications |

jscs is a code style checker. jscs can check cases, which are not implemeted in jshint, but it does not duplicate jshint functionality, so you should use jscs and jshint together.


* requireCurlyBraces
* requireSpaceAfterKeywords
* disallowSpaceAfterKeywords
* requireParenthesesAroundIIFE
* requireSpacesInFunctionExpression
* disallowSpacesInFunctionExpression
* disallowMultipleVarDecl
* requireMultipleVarDecl
* disallowEmptyBlocks
* disallowSpacesInsideObjectBrackets
* disallowSpacesInsideArrayBrackets
* disallowSpacesInsideParentheses
* requireSpacesInsideObjectBrackets
* requireSpacesInsideArrayBrackets
* disallowQuotedKeysInObjects
* disallowDanglingUnderscores
* disallowSpaceAfterObjectKeys
* requireSpaceAfterObjectKeys
* disallowCommaBeforeLineBreak
* requireCommaBeforeLineBreak
* requireAlignedObjectValues
* requireOperatorBeforeLineBreak
* disallowLeftStickedOperators
* requireRightStickedOperators
* disallowRightStickedOperators
* requireLeftStickedOperators
* disallowSpaceAfterPrefixUnaryOperators
* requireSpaceAfterPrefixUnaryOperators
* disallowSpaceBeforePostfixUnaryOperators
* requireSpaceBeforePostfixUnaryOperators
* disallowSpaceBeforeBinaryOperators
* requireSpaceBeforeBinaryOperators
* disallowSpaceAfterBinaryOperators
* requireSpaceAfterBinaryOperators
* disallowImplicitTypeConversion
* requireCamelCaseOrUpperCaseIdentifiers
* disallowKeywords
* disallowMultipleLineStrings
* disallowMultipleLineBreaks
* validateLineBreaks
* validateQuoteMarks
* validateIndentation
* disallowMixedSpacesAndTabs
* disallowTrailingWhitespace
* disallowKeywordsOnNewLine
* requireKeywordsOnNewLine
* requireLineFeedAtFileEnd
* maximumLineLength
* requireCapitalizedConstructors
* safeContextKeyword
* requireDotNotation
* validateJSDoc

No comment yet.!

Now available: ESLint v0.1.0

Today I’m excited to announce version 0.1.0 is available. This is the first alpha version that is ready for people to start using and give us feedback on. Up until this point, the tool was in a state of constant flux and I didn’t feel comfortable recommending anyone use it. I wanted to get ESLint as close to the ruleset of JSHint before deeming it ready for use, and we are finally there. We have (as best we can tell), nearly 100% coverage of the JSHint rules that don’t apply to formatting (white space and other code convention rules).

Here’s what this release gives you:
* Most of the JSHint rules (that don’t apply to formatting issues)
* New rules can be loaded at runtime
* Specification of shared settings using .eslintrc files
* Configure rules as disabled, warnings, or errors
* Output results as Checkstyle, compact, JSLint-XML, or JUnit formats
* 95% or higher code coverage for statements, branches, functions, and lines

Mickael Ruau's curator insight, November 14, 2013 5:51 PM

Un vérificateur de code javascript.!

Better JavaScript with Strict Mode and JSHint

With great flexibility comes great responsibility… and JavaScript is very flexible.  Too flexible, some might argue.  There are many “features” of JavaScript that result in code that is hard to read, dangerous or buggy to execute, and in some cases creates performance issues.  In 2008, Douglas Crockford wrote a fantastic book called “JavaScript: The Good Parts” that described the features he found problematic: global variables, the assignment of ‘this’ to the global object, misuse of eval, etc.  If you write JavaScript, it’s a must read.

Several of the “bad” features Crockford identified have been mitigated with “Strict Mode.”  This was added to version 5 of ECMAScript (the JavaScript standard; supported by most popular web browsers).  Strict mode throws exceptions or prevent behavior when “bad” features or common coding errors are evaluated.  A couple of examples…

No comment yet.!

JSCS: JavaScript Code Style checker

JSCS: JavaScript Code Style checker | JavaScript for Line of Business Applications |

JSCS is a code style linter for programmatically enforcing your style guide. You can configure JSCS for your project in detail using over 90 validation rules, including presets from popular style guides like jQuery, Airbnb, Google, and more.

No comment yet.!

Lint Like It’s 2015

Lint Like It’s 2015 | JavaScript for Line of Business Applications |
If you write ES6 with Babel but JSHint holds you back, I have some good news!

In early 2015, I switched from React’s JSX compiler to Babel in order to use ES6 (and some ES7) syntax freely. It’s a tad slower but …rest assured, it’s the future. I never regretted switching to Babel for a moment, and I only have the highest praise for its authors and contributors. My only pain was getting Babel code to lint.

No comment yet.!

Explorations In Automatically Fixing JavaScript Linting-errors

Explorations In Automatically Fixing JavaScript Linting-errors | JavaScript for Line of Business Applications |

FixMyJS (by Josh Perez) was created to try solving this problem. It aims to automatically fix linting errors in a non-destructive way. To an extent, it achieves this goal.

Under the hood the module uses Esprima for source parsing and Escodegen (from the Mozilla Parser API AST) to generate it back. While any form of automation code transformation should be approached with a healthy dose of skepticism, FixMyJS is able to handle fixing basic JSHint errors fairly well. Some of what it supports includes:

  • Adding missing semicolons
  • Enforcing camelCase and snake_case conventions
  • Adding curly braces to statements
  • Removing debugger statements
  • Enforcing single and double quite styles
  • Adding the radix parameter to parseInt
  • Dot notation conversion
  • Handling extra trailing commas

and a few other common linting issues.

No comment yet.!

Eliminating Code Smell With Grunt

I love clean code. There, I said it. I pride myself on passing strict linting standards and keeping my code easy to read. It's not just a personal proclivity, but a choice I hope benefits other developers.

My general experience with teams has been that code style is something people care about and have strong personal preferences. Typically, at some point people get tired of dealing with inconsistency and a standardization meeting is called. This is, of course, an important discussion to have. The problem that tends to occur is either lack of documentation or lack of enforcement of the agreed upon style. Additionally, new team members or contributors may not have access to a clear set of rules.

Beyond the challenge of defining rules lies the supreme annoyance of enforcing them. Code reviews become cluttered with nits to be picked. Time is wasted. The solution I settled on was simply automating the conformance process.

I set forth to solve this problem:

Establish coding standards that are clearly defined and automatically verifiable.

Jan Hesse's insight:

No comment yet.!

Testable & Tested Client-side Code

Testable & Tested Client-side Code | JavaScript for Line of Business Applications |

Testing (i.e. linting, unit tests, integration testing etc..) client-side code is not done as commonly as it should be. The reason it is so commonly not done, besides lack of know-how, is that it is presupposed that it will take time away from other more productive development tasks.

This fallacious notion is, of course, wrong. The repeatable successes in software engineering based on testable (i.e. modular, loosely coupled, small, simple units of code) and tested code has proven again and again to be a time-saver and part of creating maintainable and understandable code. At a minimum, if code is not unit tested it is only a matter of time before it is burnt down and re-written, or abandoned altogether because it becomes unmaintainable and incomprehensible.

In this article, I am going to defend and talk about testing client-side code. It is my intention that the information in this article will give those among us who do not test, the desire and some initial testing knowledge to test, along with the ability to defend its necessity from any agent that might deter testing.

No comment yet.!

Introducing ESLint

A long time ago, JSLint was the state of the art in JavaScript linting technology. Then JSHint came along as a fork and took over due to increased flexibility. I welcomed JSHint as my linter of choice and used it everywhere, happily submitting patches and customizing which rules to apply based on the project. At some point I started to feel stifled and frustrated by JSHint as well. There’s no easy way to add additional rules or to create your own that may be project-specific.

After talking with Anton about the possibilities available with JSHint, we both came to the conclusion that it wouldn’t be possible to do what I wanted. I really wanted an AST to evaluate for context and to be able to dynamically plug in new rules at any time, including run time.

ESLint is a JavaScript linting tool built on top of Esprima. The goal of the project is to create a linting tool where all rules are pluggable. This is achieved by having one rule per file and allowing each rules to inspect the AST at the points it wants.

No comment yet.