Discussion:
LINTing Javascript in a Java WebApp
(too old to reply)
Steve
2013-02-11 17:26:55 UTC
Permalink
Hi,

I have a number a Java webapp with a number of embedded ( in JSPs )
Javascripts and straight *.js files.

More than few times I've built the webapp and deployed it only to find
I've made a trivial error, like forgetting a semicolon in the Javascript.

I've seen that there are some Javascript LINT tools out there.

Is there any particular tool or combination of tools that will highlight
Javascript errors as I go ( similar to what spellchecks do these days by
putting squiggly red line underneath ) or give me error messages at
compile time ( for my Java webapp )?

Thanks either way

Steve
Roedy Green
2013-02-11 19:42:58 UTC
Permalink
Post by Steve
Hi,
I have a number a Java webapp with a number of embedded ( in JSPs )
Javascripts and straight *.js files.
More than few times I've built the webapp and deployed it only to find
I've made a trivial error, like forgetting a semicolon in the Javascript.
I've seen that there are some Javascript LINT tools out there.
Is there any particular tool or combination of tools that will highlight
Javascript errors as I go ( similar to what spellchecks do these days by
putting squiggly red line underneath ) or give me error messages at
compile time ( for my Java webapp )?
I have not used it, but I have seen the JavaScript lint tools in
IntelliJ.
See http://mindprod.com/jgloss/intellij.html

There are also so primitive ones in
http://mindprod.com/jgloss/htmlvalidator that work on html with
embedded JavaScript.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law
Steve
2013-02-12 13:40:54 UTC
Permalink
Post by Roedy Green
I have not used it, but I have seen the JavaScript lint tools in
IntelliJ.
See http://mindprod.com/jgloss/intellij.html
There are also so primitive ones in
http://mindprod.com/jgloss/htmlvalidator that work on html with
embedded JavaScript.
Thank you!
Lew
2013-02-11 20:45:21 UTC
Permalink
Post by Steve
I have a number a Java webapp with a number of embedded ( in JSPs )
Javascripts and straight *.js files.
Hmm. Not a good clean separation there.
Post by Steve
More than few times I've built the webapp and deployed it only to find
I've made a trivial error, like forgetting a semicolon in the Javascript.
Why do you need so much Javascript?
Post by Steve
I've seen that there are some Javascript LINT tools out there.
Is there any particular tool or combination of tools that will highlight
Javascript errors as I go ( similar to what spellchecks do these days by
putting squiggly red line underneath ) or give me error messages at
compile time ( for my Java webapp )?
The Aptana plugin for Eclipse
www.aptana.org
provides more advance Javascript editing.

It seems wrong to put a lot of JS into a JSP. Or any, really.

I've seen it done in some projects and that consistently caused unholy messes.

But you might try using static pages with the same Javascript and debug the JS that way.
Freeze one possible output that the JSP might generate and try to use its Javascript.
--
Lew
Steve
2013-02-12 13:40:19 UTC
Permalink
Post by Lew
Post by Steve
I have a number a Java webapp with a number of embedded ( in JSPs )
Javascripts and straight *.js files.
Hmm. Not a good clean separation there.
Post by Steve
More than few times I've built the webapp and deployed it only to find
I've made a trivial error, like forgetting a semicolon in the Javascript.
Why do you need so much Javascript?
Some of it client side data validation that was done a long time ago
before frameworks made server side data validation less of a PITA.
Some of it is to enforce rules the users asked for ( example, if check
box A is selected client side, disable textfield B, etc, etc ). Some of
it is AJAX used to decrease the number of screens the user has to
submit. Some of is gluing in various JQuery features, like a pop-up
calendar for picking dates ( not something I asked for, the users love it ).
Post by Lew
The Aptana plugin for Eclipse
www.aptana.org
provides more advance Javascript editing.
Awesome, thank you.
Post by Lew
It seems wrong to put a lot of JS into a JSP. Or any, really.
I've been hearing that since the year 2,000. I would still love for it
to be true :)
Post by Lew
But you might try using static pages with the same Javascript and debug the JS that way.
Freeze one possible output that the JSP might generate and try to use its Javascript.
That is pretty much what I have been doing. I was hoping for the
convenience of type as you go error highlighting like I can get with Java.

Steve
Lew
2013-02-12 17:45:45 UTC
Permalink
Post by Steve
Post by Lew
Post by Steve
I have a number a Java webapp with a number of embedded ( in JSPs )
Javascripts and straight *.js files.
Hmm. Not a good clean separation there.
Post by Steve
More than few times I've built the webapp and deployed it only to find
I've made a trivial error, like forgetting a semicolon in the Javascript.
Why do you need so much Javascript?
Some of it client side data validation that was done a long time ago
before frameworks made server side data validation less of a PITA.
Some of it is to enforce rules the users asked for ( example, if check
box A is selected client side, disable textfield B, etc, etc ). Some of
it is AJAX used to decrease the number of screens the user has to
submit. Some of is gluing in various JQuery features, like a pop-up
calendar for picking dates ( not something I asked for, the users love it ).
I've worked on projects like this. Never mind the JSP, all these Javascript
frameworks tend to interfere with each other and cause more bugs than they
help with.

Are you familiar with "technical debt"? It sounds like you're paying a lot just
in interest.

I recommend that you gradually (since management won't buy in or give you time)
refactor the JS to make sense. Dump old, unsupported versions of any frameworks
you're using, and clean up the separation just between the JS parts.

Consider using Facelets/XHTML with new stuff. Make sure your changes remain
compatible with existing code and you won't need to make sweeping, all-at-once
revolutionary upheavals.

But if you do nothing, this system will creak until it cracks.

... [snip] ...
Post by Steve
Post by Lew
It seems wrong to put a lot of JS into a JSP. Or any, really.
I've been hearing that since the year 2,000. I would still love for it
to be true :)
Congratulations. It is true. Sort of.

Hand-coded Javascript is what I was talking about. Even auto-generated
Javascript can be dangerous, but not all APIs are equally guilty.
Post by Steve
Post by Lew
But you might try using static pages
with the same Javascript and debug the JS that way.
Freeze one possible output that the JSP
might generate and try to use its Javascript.
That is pretty much what I have been doing. I was hoping for the
convenience of type as you go error highlighting like I can get with Java.
Hope away.
--
Lew
Steve
2013-02-13 19:26:05 UTC
Permalink
Post by Lew
Are you familiar with "technical debt"? It sounds like you're paying a lot just
in interest.
I haven't heard the term before. Does it mean a lot PITAs from legacy
code? The javascripts aren't bad. My problem with them are my own
typos when I get change requests. I don't have a way to find out about
them before I test the WAR that takes less time than doing just that.
Post by Lew
I recommend that you gradually (since management won't buy in or give you time)
refactor the JS to make sense. Dump old, unsupported versions of any frameworks
you're using, and clean up the separation just between the JS parts.
Consider using Facelets/XHTML with new stuff. Make sure your changes remain
compatible with existing code and you won't need to make sweeping, all-at-once
revolutionary upheavals.
I have read those terms, haven't used them yet. It didn't occur to me
that those things could be used to reduce/eliminate javascript. Can
you check for simple syntax errors with these technologies before you
run your app? That is my problem with javascript so far.

Steve
Lew
2013-02-13 22:56:08 UTC
Permalink
Post by Steve
Post by Lew
Are you familiar with "technical debt"? It sounds like you're paying a lot just
in interest.
I haven't heard the term before. Does it mean a lot PITAs from legacy
That's about the best definition I've ever heard.
Post by Steve
code? The javascripts aren't bad. My problem with them are my own
typos when I get change requests. I don't have a way to find out about
them before I test the WAR that takes less time than doing just that.
If they can run standalone maybe you can run them on node.js. I'm reaching.
Post by Steve
Post by Lew
I recommend that you gradually (since management won't buy in or give you time)
refactor the JS to make sense. Dump old, unsupported versions of any frameworks
you're using, and clean up the separation just between the JS parts.
Consider using Facelets/XHTML with new stuff. Make sure your changes remain
compatible with existing code and you won't need to make sweeping, all-at-once
revolutionary upheavals.
I have read those terms, haven't used them yet. It didn't occur to me
that those things could be used to reduce/eliminate javascript. Can
Not to reduce it, but to reduce your direct involvement with it. These things have JS
already built in and you treat it like a black box.
Post by Steve
you check for simple syntax errors with these technologies before you
run your app? That is my problem with javascript so far.
No.
--
Lew
Roedy Green
2013-02-14 02:43:50 UTC
Permalink
Post by Lew
I've seen it done in some projects and that consistently caused unholy messes.
The big problem is the code often works on only one browser. It is
quite a trick to write code that works on even half a dozen browsers.

Dealing with those differences is largely what Ajax is for.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law
Loading...