loading...
re: Yes, for example: myFunc() { setState({ "number" : 1 }); alert(this.state.number) } The code is right, it compiles but it ignores the...

Lolx rules are rules we didnt make em so we gotta follow em... I think what you might be embarking is creation if a new language above a language...

The evolution of assembly to java and beyond now

Yes, although it's mostly a front-end issue. On the back-end if you try to access DB data in a non-async way you'll quickly realize that the data is simply not there. I've been handed large amounts of amateur JS and there was MANY issue but not really that one.

The kind of issues that PHP enables are more like "let's execute this unfiltered user input" which is way more dramatic than a randomly-bugged front-end component.

The kind of issues that PHP enables are more like "let's execute this unfiltered user input" which is way more dramatic than a randomly-bugged front-end component.

Validating the user input is anything but trivial. But I don't think Javascript is doing it better. AFAIK, MVC c# it does it right, we could validate the type, the long, if it is present or not and such.

There are some libraries that do this job but natively both languages don't do their duties.

req.param('name')

$_GET['name']

Oh well, I assumed that frameworks would make sure that req.param('name') is a valid unicode string while $_GET['name'] can be any string of bytes but maybe I'm expecting too much?

In any case, you can write stupid code in all languages. But to be specific to the $_GET issue, it's so easy to break encapsulation using it (because it's global). Same thing with $_REQUEST, what is the point of this except getting X-whatever-scripting attacks from all sides?

PHP is just next-level compared to anything else in terms of possible misuses.

Code of Conduct Report abuse