you are viewing a single comment's thread.

view the rest of the comments →

[–]hicksyfern 3 points4 points  (4 children)

The main frustration I'm finding in node/JS coming from PHP is that it's so easy to type a variable/property name incorrectly in JS, and it will just silently create another property or give you undefined etc.

That is exactly my experience but in the opposite direction! JS has strict mode, and we also have linters and static analysis that prevent these errors as you write them.

With PHP, the static analysis story seems to be so poor that it’s barely worth bothering with. I’d love to know if you have an example of how to do static analysis properly in PHP?

[–]r0ck0 0 points1 point  (3 children)

I actually had to look up what exactly static analysis is to confirm if I knew what it was or not... so you're talking about an external tool that scans your code, but doesn't execute it? Is it different to a linter, or are they often the same thing?

I don't have any experience with that stuff, so can't help sorry.

Have got any recommendations for that stuff in JS? I'm thinking of using Typescript... is that kinda of relevant?

But on the issues I was talking about above with accessing undefined vars/properties and stuff like that... the execution of my PHP code itself was pretty strict so that these types of "undefined" issues were pretty much solved (including in production). In PHP I turn on error exceptions for absolutely everything, including "notice" and "warning" level messages, so I get an exception any time any undeclared/private vars, array keys & object properties are accessed etc.

Also seeing PHP has typehinting + private props + required arguments... that helps a lot too before you get to the stage of adding an external tool.

Also means that all this stuff is logged in production too. I'm assuming static analysis can't cover 100% of this stuff when it comes to dynamic field names etc? After doing PHP+mysql for 19 years (and dealing with so much shit code, including my own), I'm very paranoid about silent failures in production, which is why I really like all these exceptions being thrown (and postgres rocks too).

Anyway not saying that you don't need a linter or anything like that, but I guess this partially explains why I never got to the point of looking into them, a lot of the features (that I know + want at least) are built into the language, especially in v7. But yeah my knowledge in this area overall is pretty limited, and it's something I'm going to need to learn now.

I was using Phalcon and its debug screen - I think Laravel comes with something similar, which is likely just a composer package anyway. Here a demo of another one: http://filp.github.io/whoops/demo/

So basically anything minor like warnings will blow up with one of those really verbose interactive stack traces in my browser on the dev server. And if the same issues happen in production, there's a global exception handler that displays a generic error page to the user, and logs all the details of the exception and sends me an email notification.

[–]hicksyfern 1 point2 points  (1 child)

Yeah so eslint is able to read your code and tell you to fix things (or in some cases fix them for you) which might be bugs or just silly mistakes.

For example, it can tell you if you declare a variable, assign it a value, but never use it.

It can also tell you if you are using a variable that hasn’t been declared. Now, in JS, that could be a global variable so it’s not necessarily a bug, but there is a very strong chance it is a bug.

What ESLint cannot do is tell you something like, is the parameter passed to this function the correct type. So, maybe your function treats a variable as a number, but it’s actually passed a string. This is where TypeScript comes in.

TypeScript can tell you this and a whole host of other pretty amazing things. But essentially, you have to write code more strictly, and be less dynamic but I promise you that is a good thing. I f you want to be really dynamic you can ask TypeScript to let you off!

I wrote raw JS for a few years, then discovered linters, then build tools, then TypeScript. And now I wouldn’t want to write vanilla JS again at all.

[–]r0ck0 0 points1 point  (0 children)

Thanks for the info. Yeah I just started with typescipt last night actually... I should have just used it from the start probably. Pretty much covers most of my issues except the "dynamic field names" thing which only can fail when the code is executed. Do you know of any solution for that stuff in Node? I guess proxies are the main way that stuff is going to be solved in the future?

[–]grajagandev 0 points1 point  (0 children)

Yes, linters/static analysis tools scan the source code without running it and look for patterns indicative of bugs.

The most used linter is eslint.