Willing to relocate: Probably not, would consider doing offset hours
Technologies: Javascript/Typescript, Angular, React, Node.js, GraphQL, SQL, AWS + lots of other web related things
Full stack developer with ~9 years experience. Mostly experienced with web related technologies but always interested to learn new stuff. I like making things efficient and helping people solve problems.
I could be wrong but I think it is used to alert you when you have incompatible dependencies.
For example if you have a dependency with a peerDependency `something: 2.x.x` and you currently have `something: 1.0.0` installed as a direct dependency, it will fail rather than allowing multiple versions to be run.
I like Javascript (mainly Typescript) and use it quite a lot. If you aren't a fan, I completely understand. However I don't understand why people feel the need to discredit something that they don't like.
It honestly makes me not want to open HN threads about JS as I know I will be met with a barrage of negative comments about something that I enjoy. I'm all for open discussion of the downsides of the JS ecosystem but that is rarely what these comments are.
There is a special issue for JavaScript, and that's monopoly. If you want internet service and don't like your ISP, you'll be a lot more critical if you can't realistically switch to a different ISP. If you want the world-changing reach of the web and don't like JavaScript, you may be a lot more critical of it than you are of some server-side language that you don't like either (as long as you get to choose your server-side stack).
Using languages that don't come with the platform SDK, or aren't used to build the underlying platform, always add development costs with additional FFI, debugging tools, binding libraries,....
> There is a special issue for JavaScript, and that's monopoly
There are languages that treat javascript as a compilation target. Purescript, Elm, Closurescript, Rescript, Scalajs, etc. So if you really dislike javascript, you are still free to pick something else.
That just hides the lack of choice with another layer of complexity. A script language is not the best compilation target, but Web Assembly probably would be.
> A script language is not the best compilation target
Performance-wise, sure. But the parent commenters were not complaining about performance; they were upset about javascript's syntax, or lack of type guarantees, or typecasting, and so on. Well, all of this can be taken care of by the compiler, if the developer dislikes javascript itself so much.
Why are you so emotionally invested in whether other people like JS? Languages are tools -- not part of your identity.
Also what languages do you like less than JS? A lot of people think working with a certain tool is "as good as it's going to get" until they try something better.
Of course! People are free to dislike languages as much as they want. But is that something that is worthwhile discussing on HN?
I don't dislike any language in that sense, every language has pros and cons. Different tools for different jobs, some I enjoy more than others. But that wasn't the point.
> But is that something that is worthwhile discussing on HN?
This thread is about improving JavaScript tooling. It seems like a very appropriate place to discuss things you dislike about JavaScript.
> I don't dislike any language in that sense, every language has pros and cons. Different tools for different jobs, some I enjoy more than others.
The problem with JavaScript is that it wasn't designed for the job it's doing and (until recently) we really had no other options. We still don't have another language that is browser-native, unless you count Web Assembly.
So some of the JavaScript hatred is due to the fact that 100% of web developers have to use it whether they like it or not.
> I don't dislike any language in that sense, every language has pros and cons. Different tools for different jobs, some I enjoy more than others. But that wasn't the point.
I dislike this overly positive attitude: responding to criticism of a language being worse than others by saying "every language has pros and cons" avoids addressing the criticisms and seems to imply that there are no bad languages.
It is possible to design a bad language for complex projects.
It is very well possible to like working in a language and to have a sincere dislike for its shortcomings. Language shortcomings are those things that repeatedly bite you in the backside or require work-arounds when there would have been alternatives known at the time of language design that would have avoided those particular pitfalls.
I completely agree with that, there are some things that would be nice to change that are unlikely ever to be changed due to the goal of being backwards compatible. But a lot of the OP's comment was unrelated to the language itself.
> browser incompatibilities are still prevalent
It's true, browser difference are a pain to work with. But what is the alternative, to only support a single browser engine? Note that this has improved a lot in recent years. As long as you don't need to support IE11 or below then you shouldn't come across many issues. You can find browser support using caniuse.com or looking at MDN docs.
> even popular libraries are barely documented and you regularly have to wade through hundreds of wannabe tutorials on Medium/Hackernoon/...
I don't think that incomplete documentation is is exclusive to Javascript by any means. It is quite possible that the standard for packages and articles is lower due to Javascript having a lower entry level. I think we saw a similar thing with PHP.
> one compiler/transpiler, no, there are several...
I personally don't see a problem with this? Usually they have different goals, pros and cons. Do we think that it would be beneficial to not create competing solutions? For example would it be beneficial to only have React and not have Angular, Vue, Svelte? Agreed that multiple solutions can be confusing for new users and generally I would direct new developers to all-in-one solutions so they don't need to deal with these things.
> some things like imports might work in completely different ways
I'm not quite sure what is being referred to here, maybe the difference between commonjs and es imports? I personally haven't encountered any issues but they are completely different. I might be able to point someone in the right direction if they clarify.
Again I understand if you don't like having to deal with these things, but there are reasons for them that can't just be glossed over. Discussions are great! But I find it hard to have them when developers ignore the nuances and insist on approaching them from a negative angle.
Location: New Zealand
Remote: Yes
Willing to relocate: Probably not, would consider doing offset hours
Technologies: Javascript/Typescript, Angular, React, Node.js, SQL, AWS + lots of other web related things
Full stack developer with ~8 years experience. Mostly experienced with web related technologies but always interested to learn new stuff. I like making things efficient and helping people solve problems.
Working on my CV, feel free to send me an email if you are after more details.
One example would be a food critic. They give an honest description of a restaurant so readers can decide if they want to go there. The article doesn't need to be helpful for the restaurant.
But I can't think of an example where a company keeps unconstructive critics on the payroll.
Food critic is a third party. If the description is honest and contains reasoning it can be constructive to readers (potential/current customer(s) and/or the restaurant(s)). Something along the line of "sucked, bad taste" contains no substance whereas "food was burned and flavor X and Y was a bad combination" does contain substance.
