Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The melting pot of JavaScript (2017)

increment.com

Post reply on HN
Print view View original

151–160 of 200 posts

Re: The melting pot of JavaScript (2017)

#151

Post by TeMPOraL »

2trill2spill wrote: post #102
BigJono wrote: post #101

Earlier quoted context omitted.

I know a couple that would tell me to go jump if I suggested they aim for 90% code coverage on a CRUD app. They also write very clean, maintainable code and do it very, very quickly. There's always a trade off.

I'm not writing a CRUD app, I'm writing a program that my company expects to put into production. Writing tests is very much a part of writing production code.

If you're in webdev, CRUD apps is probably 95+% of what gets put into production. CRUD isn't meant as pejorative here, it's just most of the things people do with software fits in the model of Create/Read/Update/Delete access to a DB.

Re: The melting pot of JavaScript (2017)

#152

Post by spricket »

luord wrote: post #130
spricket wrote: post #125

Earlier quoted context omitted.

I don't write many tests. I've found with experience and heavy linting you can avoid the vast majority of bugs. Not much point to spending a ton of time on tests if they hardly ever break for nontrivial reasons. My normal setup for java is: Linters: ErrorProne Checkstyle PMD SpotBugs Nullaway All with highly customized settings All warnings enabled on javac Google-java-format to autoformat everything on build. For ru…

> I've found with experience and heavy linting you can avoid the vast majority of bugs. No, you can't. In fact, I can't even begin to see how "apply this specific standard to the code" (linting) is even remotely related to "know everything about this particular domain so you don't make any mistakes in creating an application for it" or "know everything about this particular system so that a given difference in config…

Linting is about so much more than code style and standards. Since we use auto format I have almost all the style checks off. What it does catch is hundreds of different types of potential bugs. Uninitialized variable. Missing null check. Deprecated or beta marked api used. Improper thread synchronization and double locking. Reassignment of parameters. Conditional check that's always true/false. This list is huge, and in my experience it catches mistakes constantly.

For the average crud app, if you're wrong about the requirements the tests will be wrong anyways. It sounds like you're talking more about TDD which IMO is a cargo cult. And I'm hardly the only one with that opinion. Integration tests are important but that's more about running data through the code all at once than testing each function in isolation.

Also, many open source projects get along with hardly any tests. The Linux kernel is probably the best example, but there's tons of popular projects without good or any tests. Check NPM popular repositories, I'll bet you more than half of the top 500 are under 10% code coverage. Tons of huge apps are doing fine without tests, and many I've worked on with tests are still horrible.

I haven't really noticed any contribution from having lots of tests. IMO what's far more important is linting and maintaining code standards. It's hard to write a function that's horrible to debug when the linter limits you to 300 lines. Or a class that's totally incomprehensibly long when the linter limits you to 1000. All of my debugging nightmare projects have been due to lack of sound OOP principles, huge files of spaghetti. Good linting prevents that from happening.

Besides Java my other big language is TypeScript. Using Mockito in java isn't that bad, and JUnit5 or TestNg are decent. Certainly easier than getting tests working in the garbage fire that is Angular6 + Jasmine + Karma.

Re: The melting pot of JavaScript (2017)

#153

Post by spricket »

adrianN wrote: post #133
spricket wrote: post #125

Earlier quoted context omitted.

I don't write many tests. I've found with experience and heavy linting you can avoid the vast majority of bugs. Not much point to spending a ton of time on tests if they hardly ever break for nontrivial reasons. My normal setup for java is: Linters: ErrorProne Checkstyle PMD SpotBugs Nullaway All with highly customized settings All warnings enabled on javac Google-java-format to autoformat everything on build. For ru…

I don't see how linting and experience prevents logic errors, missed corner cases, or misunderstandings of the requirements. In my experience integration tests are crucial to robust software.

It does nothing for missed requirements, but in my experience the test will be wrong if the requirements are anyways. I don't disagree with integration tests, which are usually just running the software through the motions in a semi automated way. I just think unit tests are pretty useless with good linting.

You might be surprised how much bad logic static analyzers can catch though.

Re: The melting pot of JavaScript (2017)

#154

Post by spricket »

BigJono wrote: post #101
2trill2spill wrote: post #98

Earlier quoted context omitted.

What kind of "good engineer" refuses to write tests?

I know a couple that would tell me to go jump if I suggested they aim for 90% code coverage on a CRUD app. They also write very clean, maintainable code and do it very, very quickly. There's always a trade off.

I'm one of those. Unit tests are a waste of time IMO. It usually takes almost as much code to test logic as it does to write it, so I always wondered why the TDD folks don't just implement the code twice and check the result at the end :)

Re: The melting pot of JavaScript (2017)

#155

Post by joshuamorton »

stickfigure wrote: post #136
hajile wrote: post #128

Earlier quoted context omitted.

That's a solution looking for a problem in JS. You're thinking in types instead of in terms of a dynamic language. You basically HAVE to do this in Java otherwise your program won't work. In JS, you can look everything over at runtime and dispatch from there (made much easier because first-class functions and closures are a thing).

you can look everything over at runtime Correct, that's what you have to do in dynamic languages - look at what came in from the database and manually validate+convert it into the format you actually want. Also with pretty much every other form of input (JSON bodies, form posts, queue messages, etc). It's a lot of tedium. When working with node/python/ruby, I often find myself wishing I could just declare a type and…

> Well-written Java programs are generally more concise and less verbose than well-written JS/Python/Ruby programs.

This isn't at all true. I can say this from experience using statically typed Python extensively, in an average code base, 80% of your functions, if not more, are already statically correct in Python, one just need add an annotation. Then you're just as "well written" as the Java.

With or without the annotations, the code is still just as "correct".

> BTW absolutely nothing prevents you from building Java apps by declaring everything as Map. Nobody does that because it's a horrible way to program

Yes, but only because you'd need to explicitly cast things everywhere and write out declarations everywhere. If you could always elide casts and type defs, it becomes a lot less horrible.

> Correct, that's what you have to do in dynamic languages - look at what came in from the database and manually validate+convert it into the format you actually want.

You still have to do this in static languages. Maybe a library does it for you, and it gives your an error or something you know is a DbRecordFieldStream or whatever, but dynamic languages can do the same thing. Orms validate input in dynamic languages too. Rails and Django can validate request formats. Protobufs work in every language.

Re: The melting pot of JavaScript (2017)

#156

Post by spricket »

sonnyblarney wrote: post #129
spricket wrote: post #26

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…

Sympathies to your valid concerns ... Though Java was 'designed', it was not 'designed' to be an http/web server. JS, particularly Node.js has really adapted itself to that well. And one small but massive difference: JSON is how data is passed and it fits seamlessly into Javascript, and doing JSON in Java is an ugly, ugly thing. As soon as you compare not JS/Java, but Java/Tomcat vs. JS/NodeJS - then you get a differ…

I actually like gRPC better than JSON these days so it saves me from that pain, code just gets generated for you.

But yeah json is much nicer in JS generally

Re: The melting pot of JavaScript (2017)

#157

Post by pjmlp »

adrianN wrote: post #132
sonnyblarney wrote: post #129

Earlier quoted context omitted.

Sympathies to your valid concerns ... Though Java was 'designed', it was not 'designed' to be an http/web server. JS, particularly Node.js has really adapted itself to that well. And one small but massive difference: JSON is how data is passed and it fits seamlessly into Javascript, and doing JSON in Java is an ugly, ugly thing. As soon as you compare not JS/Java, but Java/Tomcat vs. JS/NodeJS - then you get a differ…

JSON is how some data is passed today. It's certainly not the best way and might go out of style just like XML did a while ago.

It is already on its way out, thanks to gRPC and need for performance instead of parsing text all the time.

It is only a matter of browsers getting native support for gRPC.

Re: The melting pot of JavaScript (2017)

#158

Post by pjmlp »

bryanrasmussen wrote: post #42
spricket wrote: post #26

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…

JS or anything that compiles well to JS has a backend advantage that can be hard to beat for an early stage startup and that is reducing the amount of context switching you have to do in changing between languages (especially if your code is isomorphic). At least, that is how I find it, my productivity shoots up when I don't have to be moving between two imperative languages that most likely share a lot of their synt…

Other than form validation, I never wrote the same code for both sides.

And that is only when not using JSF, Spring, Forms, MVC, Liferay, Sitecore, which generate the JavaScript validators automatically from type annotations anyway.

For my projects, the Web layer is only the View part of MVC.

Re: The melting pot of JavaScript (2017)

#159

Post by bryanrasmussen »

pjmlp wrote: post #158
bryanrasmussen wrote: post #42

Earlier quoted context omitted.

JS or anything that compiles well to JS has a backend advantage that can be hard to beat for an early stage startup and that is reducing the amount of context switching you have to do in changing between languages (especially if your code is isomorphic). At least, that is how I find it, my productivity shoots up when I don't have to be moving between two imperative languages that most likely share a lot of their synt…

Other than form validation, I never wrote the same code for both sides. And that is only when not using JSF, Spring, Forms, MVC, Liferay, Sitecore, which generate the JavaScript validators automatically from type annotations anyway. For my projects, the Web layer is only the View part of MVC.

For a few things I've worked on Views can be rendered client side or server side.

Aside from form validation I find I might have a number of utility functions that are used on both layers.

I find there are a few other edge cases, but those are the most common situations where reuse is nice (on the other hand what I often do for personal projects is just build the server side and client side code from a gulp pipeline and not worry about needing 'isomorphic' code reuse, but often teams on paid for projects find this approach confusing)

Re: The melting pot of JavaScript (2017)

#160

Post by z3t4 »

me551ah wrote: post #67
spricket wrote: post #26

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…

You never really learn javascript, you learn frameworks. I was a js developer about 7-8 years ago and dabbled with jQuery , dojo and the likes and then moved over to backend and mobile development. I tried getting back into javascript again and realized that I just could not get in and start coding. There are a lot more frameworks now that I have to learn to get started and I'm sure that a few years down the line, th…

Highly recommend vanilla JavaScript. With vanilla JavaScript you do not need any build tools. Instead of buying many different kitchen cutting and slicing tools - learn to use a knife.
Post reply on HN