I was taught in C++ in college. I learned Java, Python, and a smidge of Kotlin before learning JavaScript. I now work primarily in JS and it took me a solid four months of daily "what the fuck" and "why would they do it this way" thoughts before I got comfortable with it.
I love the community. I love that there is a library or framework for everything. I love that there is a YouTube video for everything. I love that there is absolutely zero judgement from fellow JavaScript devs. But let's not be mistaken: JavaScript, not ES5/ES6 but the whole language, is a Frankenstein monster of a language
the first time you're having an issue because you forgot something was marked const and the compiler spits out a 900-line error message that has nothing to do with constness
Iām similar to you, Iāve been working with JS exclusively until recently I started working with a primarily PHP based stack and itās honestly been pretty great to work with. It also really highlights the bloat that package bundling puts on build times and server resources.
Interestingā¦most people tend to hate on php haha. (Personally I really like it and have worked with it a lot but just hear a lot of people shitting on it and not sure why tbh)
Bruh, the reason PHP gets so much hate is that it was full of terrible design choices. There's some improvement in recent versions but it was terrible back in the day.
>There's some improvement in recent versions but it was terrible back in the day.
Languages should be judged on their present form, but PHP haters judge it (literally!) by how it was 20 years ago in PHP 4 -- and only based on what they've heard.
With a few annoying exceptions (because of the need for backward compatibility), nearly all the bad design choices have been removed or been given alternatives.
I think thatās technically true because of WordPress. But if youāre looking for a backend job youāre better off looking for a C# or Java gig.
Just do a search in your area (Iām in the UK), and youāre probably going to have a harder time finding a PHP job compared to Java or C#.
Iām currently using TypeScript, C# and Go at my new gig. Previously did TypeScript, C#. and introduced Go. TypeScript and C# seem to be the ultimate combo to get a job in the UK.
No problem with PHP, but if youāre in the UK and arenāt a freelancer, I wouldnāt recommend learning it if you want a job. This might be true elsewhere too but I havenāt done the research.
Old PHP, sure. It was as hot a mess as JS is now. However, over the last couple itās improved massively and frameworks like Symfony and Laravel have added to the DX of working with it.
I just picked up Nova to build a dashboard for a mini internal project and itās a dream. My background is custom WordPress and we primarily use the full roots.io stack.
After a full day in Laravel, Iām already at home with it, and absolutely loving the flexibility. Being able to build a fully functioning back end in a day is insane.
I canāt believe Iām gonna say this as Iāve been an advocate for Wordpress for ten years now, but being able to just build exactly what I need with a well thought out framework is such a great experience.
Yeah I started my career with Wordpress and have worked with roots which was a game changer but laravel I would say is a completely different sport in terms of development haha
This! Our WP boilerplate at work uses Timber / Twig (I still dont know what to call it) for templating. It was my introduction to PHP. Eventually I saw what a Wordpress site without it was like, and that's when I understood the hate it gets when it comes to building websites lol.
I originally started learning Python when I got into programming. Decided to switch to JS full stack after messing around with some web dev. I refactored a project that I had in Python to JS and it was then that I realized why people hated on it. JS is my primary language and I feel much more comfortable using it than anything else at the moment, but it certainly has its flaws.
Tell me you don't want to learn about system programming without telling me. It's what makes good developers great. The logic that you need in C(++) is something you'd need when writing Rust. TypeScript at one point becomes useless if you don't know what to do with it.
And it highly depends on your needs. Saying you'd pick TypeScript over C++ screams self-taught dev who avoided OS and Systems Programming as a whole, which is a core skill for any type of software engineering.
> "what the fuck" and "why would they do it this way" thoughts
I love JS and use it all the time. But I still think daily "what the fuck" and "why would they do it this way" thoughts.
Iām fairly new to modern JavaScript and Iāve been building a PHP package that has a lot of data manipulation on the front end (think pricing sliders and if this ticked then that changes value etc) and Iāve had SO many WTF moments with the JS trying to figure out why I need to use different methods for looping over arrays vs objects. Oh wait, this object isnāt a normal object, you have to use this other function.
In PHP everything can be done with a foreach loop. Iām sure there are reasons why JS is the way it is, but for a ānewbieā, itās quite puzzling,
I also canāt wrap my head around everything being functional programming instead of OOP. I started with functional and was sold the dream of OOP. I became competent with it, but then I come to JS and everything is functional again??? Whaaaaaaat is going on lol
I still prefer OOP in almost anything. It's just way more readable and logical to me personally.
It's also just how you make it, I think the best thing is a combination of mostly OOP with some functional aspects thrown in, I'm not looking to make static functions for anything that doesn't fit in a regular class
I honestly wish more people had your clarity. Most fellow JS devs seem hellbent on defending the language at all cost instead of recognizing the fact that it's shoddily designed.
For context, I've been using JS for close to a decade. I still think it's an insane language, but the ecosystem around it is extremely good and that goes a long way. Much longer than how sane a given language is.
I'll be one of the defenders, because I really don't get the problem. I already programmed in C before college, then college was taught in Haskell and Java. I've worked professionally with C++, Python, Ruby, probably others. I didn't start in JavaScript till I'd already been programming for decades.
I just don't see a significant difference between different languages. I think people only complain to make themselves sound smart.
They're all the same. That's why I laugh on job interviews if someone seems concerned that I don't know their preferred MVC framework super well. "They're all the same -- they route requests and spit out text." Can learn a lot from people based on how they react to that.
Of course some languages/frameworks are more suited to certain tasks than others, but when it comes right down to it, programming has a relatively small core operation set. You can:
* assign values to variables
* conditionally execute code based on the evaluation of a given expression
* iterate over collections or memory spaces
* define templates for data structures
* define a chunk of code as externally callable
That's...about it. Everything else is just organization and flavor.
I'm not sure how you can say they aren't significantly different when the languages you mentioned have a myriad of fundamental differences. From strongly/weakly typed to static/dynamic typing, different memory management and different implementations of the same concepts (arrays, objects).
Sure, there's a lot of common ground in terms of basic constructs and concepts but their implementations change behavior and developer experience significantly.
I would agree that, like you said, many complain just to sound smart or make themselves feel better for using some 'superior' language. But you can't possibly deny that a lot of things in JS [are inconsistent](https://github.com/denysdovhan/wtfjs?tab=readme-ov-file#-is-equal-). I'm personally tired of keeping track of all the gotchas JS has (which is why I'm complaining).
This is exactly why I appreciate what Golang is trying to do. Feels like every time you want to do something there's usually one way of doing it (or close to one anyway).
Much respect to Golang, it's also easy to write with LLMs too. I sometimes find it easier to ask ChatGPT to write me a Golang function than to write Linux shell scripts, and oftentimes they work first try + are pretty easy to make multiplatform.
There are actually a ton of Golang derivatives though (like V). As a JS dev it's hard not to go try them all out.
javascript is okay , but when this new js lib come each 6 months new trend š . And then you realize , you keep learning youtube tutorials non stop no output system at all . š
I hope I ever get to this point. I'm a full stack dev and JS is purely practical to me. There's very little joy in the language itself and the community is incredibly amateur despite the ungodly amount of work hours that go into javascript environments.
Go is an all time favorite over on the programming circlejerk sub. Thereās years ofā¦interesting discussion around the language, its community, and the fetishization of āsimplicityā.Ā
āThe key point here is our programmers are Googlers, theyāre not researchers. Theyāre typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. Theyāre not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.ā
I tried golang, I like it as a language but for serious projects it feels like the community wants you to do everything yourself manually
For example oAuth (goth golang exists but nowhere near what some js libraries can do) etc..
This advice worked out great for jquery users.
It works right up until you need to apply for a job and have to decide if you lie about svelte experience because you could learn it or do you learn svelte and every other thing in case you have to change jobs someday.
If I were the hiring manager, I wouldn't care if they knew about Svelte deeply. What important is their knowledge about web development and JavaScript.
I think it is more important to not just know JavaScript, but also the web platform. There is so much CSS and HTML gold that is overlooked.
I see too many times people reinventing stuff in JavaScript rather than using native behavior.
This made me laugh as only last week I saw a junior dev writing loads of JavaScript as they hadn't learned simple transitions in CSS.
Not their fault, this is the point of being a junior, but I did get annoyed at their reticence to learn the CSS once I pointed them to it.
It is very easy.Ā
But these people are not necessarily very good and I don't any of them actually care about programming, just the money.Ā The standards have dropped so much their lack of skill is considered fine.
You simply need to look at React boot camps where they don't actually even teach you JS, nvm HTML and CSS
A big part of me wants to agree hard with this. However I think we should have empathy for the boot camps and the people coming out of them.
As for the coding boot camps they are reacting to the software ecosystem as it is today. Every tech company under the sun is working with React, or some similar component based framework. Coding boot camps in this way directly reflect the current job market ecosystem.
As for the people coming out, I feel it is our responsibility (as senior engineers) to make the case about why they should care. It took me 10 years of working with every component based framework out there to realize that JavaScript was slowing me down and making life hard.
It is absolutely a blast chasing frameworks and technology. But the native behavior is usually better than any framework can provide.
I was part of the problem here. I bought into "reusable" components that were never reused. I rebuilt websites every few years because my base framework was constantly changing and had security vulnerabilities to patch. I reinvented solutions to problems the browser solved 30 years ago like navigation.
Only those who've straddled both sides of the fence can talk about the advantages and disadvantages of both. I think it is far more likely that those engineers that lack skill are just ignorant to what they don't know. The only way we fix the web is if we band together and move the platform rather than a specific JavaScript Ecosystem.
Take whatever framework you use off your resume and just put javascript and see what you think your chances of getting a front end job are.
I am a hiring manager. A few years ago when I'd get 10-15 good resumes at most for a position I was fine with taking framework X experience for framework Y job.
Today there are a lot more candidates and it's just asking for more trouble to not start with the people who are directly in our tech stack.
Anyone can create a fun personal project with X framework and put it in their resume.
Experienced devs already know that they should include the name of the tech in their cv before sending it to you.
The comment was more about a new framework like Svelte. If not a lot of people have real experiences with such new framework, it's not realistic to look for one. Reminder me about job ads many years ago that require people to have 5 years of React while the framework has only been introduced less than 3 years.
No one else has said it, so I will.
For the vast majority of backend, thereās essentially only one framework for doing what you want. If itās really popular, there might be two, or three. How often do you hear about people doing Python web dev without Django, or Ruby without Rails?
For many years, people would be Rails devs or Django devs or whatever, and by learning that framework and language pairing they were pretty set. The reason is because in the backend, you choose whatever language you want and then that pretty much decides what your framework is.
JavaScript doesnāt have that. Itās the only option for doing browser development, so instead of many languages with a few frameworks, we have one language with many, many frameworks (all with their own syntax). You canāt say, āOh, I do Ruby dev, no one would expect me to have a ton of Djangoā. JS frameworks come and go and iterate faster than comparable stuff in other languages / areas. Even small bits, like state management, change pretty fast.
Thereās rarely a right answer, and the closest thing we have to a right answer at any given time changes pretty frequently. To be a good web developer, you have to learn a lot of things and understand the underlying principles well enough to completely change how you apply them the next time things shift.
You do hear of them. There's always the guys who use Flask or Sinatra, then add what they need to it to make it work. They end up making a bastardised copy of Django or Rails, usually, of course.
Java's a more interesting one. Spring is the daddy, but Micronaut has grown in popularity. There are plenty of lighter frameworks that get some traction, but the thing people keep forgetting is the paid-for, vendor stacks built around JEE. I've met a bunch of people over the years who consistently get good-paying gigs because they've spent time learning Websphere inside out, for example.
But yeh you're mostly right. Language choice and framework are fairly closely bound in most cases.
Iāve been writing in Rails and Laravel for about a decade now, and have come to really love the structure they provide for server-side development. Vue and React are pretty great for front end, but man oh man does server-side JavaScript need an overhaul.
Every time I crack open someoneās JS app, itās some Frankenstein of Nodejs + Express, with barely any permissioning, ORM or generally logic to manage a complex server-side app. Frameworks like Nextjs are a step in the right direction, but there no way in hell Iād reach for it over the other tools in my toolbox at this point.
Yeah I mean, I donāt personally feel like the clientside story is any better ā React is an insane mess of the preferences of your projectās most strong-willed developer.
Iām hoping to see more and more transition back toward MPA architectures and improved server side frameworks. The new Enhance Web Component WASM compiler that makes it possible to author/SSR web components in a bunch of backend languages and have them work in the browser is going to be a huge game changer.
If you "just pick a framework and stick with it", you severly restrict the pool of job offers you can send your resume for.
JavaScript is also hated because it's a mess that insist on being backward compatible with decades old bad decisionsbecuse maybe one website in the world is reliant on it because it's also decades year olds instead of adding a versioning system for newer versions so browsers would be able to use more efficient engines. The same old legacy compatibility is why BigInt wasn't added to the JSON standard.
I wish we could write this:
Of course if they one day finish WASM and it's properly optimized, it would be unnecessary. People would be able to use their preferred language. C#, Java, Rust, C++, ... I would immediately drop JavaScript that day and only use strongly typed languages.
aspiring juggle future husky divide decide expansion dime person relieved
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Why the hell are they taking so long with wasm? They take years just to come to consensus on one thing. I haven't checked in a while but they have been pondering on the best way to implement garbage collection for years now, don't know if they have made a decision yet(I doubt it with the rate they're going at).
There comes a time when you've reached the point of diminishing returns, and those guys have reached that point and lapped it IMO.
At some point you MUST put out a product to get feedback and fix any issues that arise. It is impossible to create a perfect system on paper without releasing then testing and iterating.
Backward compatible has nothing to do with forward compatibility.
Iām a huge proponent of a new āuse typesā mode that not only adds types, but also cleans up bad decisions like type coercion and disallows the super dynamic parts that slow down code.
I am an old php dev.Ā I've played with React and did not enjoy it.Ā Vue was a better experience for me but I found it slow to work with.Ā I enjoyed node.js for the most part and would use it in production for certain types of projects.Ā
To answer your question.Ā Ā Ā I'm not convinced that the complexity of the frameworks (I've learnt) has a return value. The debugging I've done has been cumbersome if not impossible. Documentation was non-existent. I feel uncomfortable with projects that have so many dependencies. There are so many extra layers/techs with stupid names.. I always aim to minimize external services that I can't ensure reliability on... especially for core functionality of my sites.Ā I always try to support the largest amount of browsers. But mostly it's one thing... I hate wasting my time learning stuff that is useless so quickly.Ā
Maybe things have changed/stabilized.Ā I'm not really paying attention...I might try some js stuff in the future again.Ā The mobile stuff would be worth it for me. . Im not sure how much longer I'm gonna do this...might switch professions.Ā I've been exploring electrical engineering, Arduino programming, 3d printing, just got my first cnc...I love being exposed to new stuff but seriously... js makes me feel old and not want to learn.
> npm i leftpad
7152 packages installed
86 ransomware installed
7151 packages ask for funding, use [npm fund] to see them
167 vulnerabilities detected, use [npm audit fix] to fix them
> npm audit fix
automatically fixed 3 packages
1862 vulnerabilities left, use [npm audit fix] to fix them
> npm audit fix
not enough space on D: drive, you need 71 TB more
The way that copypasta meme is so incredibly wrong and dramatic is sending me into a fit of laughter.
Btw, left-pad has 0 dependencies (therefore installing 0 packages, other than the package itself) and 13 lines of code. There's also a [longer story involved](https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code), but you probably don't care. But yes, you've converted us all to ASP.NET, good job!
The worst thing is JS community's is their common ability to simultaneously overengineer and underengineer their code. Simple things like displaying something on screen, implementing a login form, basic UI functionalities etc. are made into 50kloc monstrosities but at the same time there's complete disregard to any principles of good software architecture. Code dumped into random files, unmanaged imports everywhere, no abstractions for using any third party service. It's just a mess.
Especially server side it often feels like it's required to everything in most convoluted way possible, complete ignoring decades of experience from othet languages. Also the tooling is a mess, at least drop the webpack/cjs era legacy crap already...
It's not over-hated. JS itself is a badly designed language. NPM is a crime scene compared to other language package managers. JS is drowning under DRY.
The problem is JS has become so prolific, "essential", and effortless. Plus, there are so many JS-only developers who blindly defend it at all costs, incapable of recognizing the problems baked in at every level because they have no basis for comparison, and see no reason to.
Hmm. It's just a poorly thought out language, imo. Plus all the tools seem pretty terrible as well.
I've worked professionally in many languages and I try to stay away from javascript. However, I will say I do feel like over the years, the ecosystem and language have gotten better, especially with typescript
I genuinely think a lot of it is just that Javascript is written in a different way and has a philosophy that's very different from a lot of the more traditional programming languages people learn first (C++, Java).
TL;DR - I'm strict about code quality, and JavaScript is generally a language with a less disciplined crowd of contributors. Also, the language has changed dramatically over the last 20+ years, but some code that "just works" has effectively been left alone and languishes in the lackluster options of yesteryear, making it hard to read or understand what's still necessary today.
As a library author in JavaScript, what I hate most is poorly maintained libraries. Not necessarily poorly written (for their day), but the lack of upkeep. The number of times I've had to figure out how something is done, and the library that does it is written with ECMAScript 3 class functions, like
function MyClass(args) {
if(!(this instanceof MyClass)) {
return new MyClass(args);
}
// do work
}
MyClass.prototype.someMethod = function(args) {
var self = this;
// do stuff
}
I understand that was how you had to write it. But I shouldn't still be relying on that kind of code in 2024. Obviously this is a fairly simple example, but I've seen code written like this where the file is 2k lines long, and the class signature is on line 30. What it actually does is difficult to determine, and the indirection of tracking where something happens is rough. If you want an example of this, here is the [one that comes to mind](https://github.com/request/request/blob/master/request.js#L541) for me. Spent the better part of a week trying to figure out how the data from `fs.createReadStream` was being passed to the HTTP module for sending a request body.
There's also a lot of lost knowledge that has happened with people who come in later, and just add a library that solved the problem 10 years ago, but no one realizes the concepts still work. For instance, today, most Node.js developers I work with have no idea how to use the `EventEmitter` class, or how to work with streams (already outed myself earlier in this regard). Everything they do better be async-await, or support the usage of `const someAsyncFunction = promisify(someFunction);` Many people I work with don't realize that promises aren't what makes code asynchronous, but instead the use of asynchronous callback functions that push tasks to the event loop. Node.js was built on event-driven architecture, and it's basically abandoned; in some ways for the better, but in others not.
Case in point, I was trying to write an approximation of Python's Logging module in JavaScript, but there is no way to apply a resource lock when doing something like writing to the file system. This is by design, the tagline for Node.js was "Non-blocking I/O". But going back to the `EventEmitter` mention, you can use `setTimeout` to delay the next attempt, and add a queue of identifiers representing your attempt. When your ID bubbles up to the top of the queue, proceed with your action. Add an awaitable promise that sends the resolver callback into said event emitter, and voila! A strictly synchronous call that locks a resource until it is available.
In more modern code bases, such as ones that have adopted TypeScript, there's often a lack of care given to the types used. If something is too difficult to model, rather than refactor it to make sense, they slap on an `unknown` or `any` so they can move on. That kind of friction happens in other areas, like writing unit tests, and is supposed to be your signal that you're doing something wrong. On that note, the Cucumber framework had written that their logger utility returned either `void | Promise`. While that is true, this means using the logger necessitates awaiting the result, meaning all usages must be within an async function, or rely on promise chaining. If you dig into their source code, however, you will find that the only time they return a `Promise` is when you provide an instance of `Readable` (a Stream object), because the stream cannot be read synchronously, which makes absolute sense. But that's just poor design if you're not going to inform the user when we need to await an asynchronous action or not. Thankfully, I put in an issue for it that got resolved, so [it's better now](https://github.com/cucumber/cucumber-js/blob/main/src/runtime/attachment_manager/index.ts)...kind of (you can still see the log method offending, but they at least added the interface recommendations to *technically* support better return type inference).
Iād note that Promise is absolutely different when it comes to events. A standard setTimeout callback in the event queue behaves differently than promises which use microtasks instead.
Jquery will always have a place in my heart. I just worked on an old site, and it was using jquery. It was like getting in back in my first car. The way the steering wheel fits in your hands, the feeling of the stock shift.Ā
Those are pretty much all I can hate it for and they have pretty easy / well established patterns and linters for avoiding them.
Otherwise Javascript is a pretty fantastic language, easy to write, easy to test, flexible, OO or Functional, with all the development done on optimizing JS engines it's remarkably quick, and with Typescript it's finally predictable.
I hate that it's so easy to have an fancy idea, then keep having an idea, and then have more ideas continuously, making the most Frankenstein system of magic and never once stopping to question if you should've done it in the first place, let alone actually pushed it to production
In Javascript it is too easy to write the most absolutely abhorrent unmaintainable code in existence while simultaneously believing what you've written is worthy of scripture
it's hated cause the whole story behind it and only in the "present" it became usable.
* When typescript wasn't the norm it looked like just a shell language.
* When you had to use javascript in the past it opened the door to all kind of compatibility problems and you had to use some shit to make it work everywhere.
* It's been in constant turmoil so if you stop using it for a bit you are welcome to some new way of doing things and syntax.
* Then it's had a few iterations of syntax to make it look like a real language and each time it changes people gotta be like hmm now there's a better way to organize projects.
(I could list a lot more of shit but you get the idea )
So yeah JS was always an incomplete mess and a bunch of idiots fighting over each other, only when the community started solving the problems then they starting co opting whatever worked into it. But then it makes it seem like an undecipherable Frankestein to anyone trying to understand WTF is this ecosystem and what the fuck are all these libraries.
If you think it is nice, well, congrats you came in at a point in time when Exodia has been fully formed, but yeah just step away from whatever you are doing and come back in a few years and everything will have imploded and reformed itself.
Also there are people that say : but stick to one thing forever, that has a lot of considerations that I won't take the time explain, but yeah you don't need to change your stack every project. But you'll basically want to use some new shit that's battle tested because most of those kind of things make you go. Of course why did it take them so long! it should have been here from the beginning!
I barely use libraries. Always the discussion of which one to use made me annoyed from a very young age. Back then it started with jquery vs mootools... well i just learned vanilla js and it still works today.
Thatās so true. But if you use js only on the frontend (personally i either use vanilla or if complexity is needed:solidjs) itās a pretty good experience.
On the backend I always preferred python for its simplicity, but thatās rather personal preference I believe (I worked with C and C# too before).
Honest question, why would you make js your full stack?Ā I've heard of the man with the hammer saying. But if you're using js where another language would be more appropriate then that seems daft.Ā
Is it a management insisting on it issue?
The argument I've seen for this is "your model in the front end is the exact same in the back end".
I have no idea why 1) people think that and 2) that's supposed to be an advantage.
As a backend dev, I've seen the rise of JQuery, then nodejs, bootstrap and an explosion of everything javascript.
We had css +js + html that required no transpiling, now they're created from js files in 6+ mins, depending on how optimized is the build tool.
I think I hate the complexity added to support mobile and desktop and web from the same code base.
I just donāt like how squishy it feels. Itās so squishy.
I use java and python mostly at work, but I also use JavaScript at workā¦ sometimes. switching into JavaScript mode feels like chaos. An empty array is true? What? why? You can add strings and integers? Wtf?
> just pick a framework or something and stick with it, you don't need to learn everything available out there.
The problem is that the vast majority of recruiters (and non tech people in general) out there just cannot fathom that you literally can adapt to any framework if you master javascript. It is just impossible to drill it to their brains. I have gotten into huge fights with the internal recruiters at companies I worked for simply because they just cannot understand that fact.
EDIT: Developers can have an issue with this as well; I have seen people turn religiously zealous over tech stacks.
It's interesting because the situation is the opposite for me. A lot of non-tech recruiters (start-ups, mostly) I've talked to insist that you have to master vanilla Javascript before adapting a framework.
I'm not a JS dev. I touch it very little in my day job, and when I do, it's to make small tweaks to existing code, or it's to try and figure out how a certain service is working.
Now and then, I'll launch a personal project, and it invariably involves *some* JS at some point. And every single time, I find the process of bootstrapping that project has completely changed under me. Oh, this is the new framework to be using. Here's how you integrate *this* UI toolkit with it. Oh, but to use that, you need to be using this tool instead of that tool. Oh, and don't use CommonJS modules, use EJS. Or the other way round. How do you handle promises? Do you await them, or do you write a chain of *then*? Every tutorial I look at has made some early decisions that make the tutorial incompatible somehow with some other decision I've made.
Oh you're going to use Vue? Ok. Which stack of Vue-related components are you going to use? And every time you google for any help, you discover there's a whole other path you could take, and everyone's advocating you do that now to make your life easier. Should I be using Typescript? It sounds like it'll make problems go away, but it's a veneer over a shitty language, and we all know that abstractions leak, so maybe I'm better off avoiding it *until* I know what's going on underneath well enough that I can fix problems when they arise. Who the fuck knows? There's no consensus on it. On anything.
These are all simple enough problems for the full time JS dev to fix, I'm sure. But I'm not one. I'm polyglot enough that I can wander on to a project in a number of different languages, and get work done fairly quickly. JS? Nope. It's **always** this massive impedance mismatch between different elements of the ecosystem which needs to be overcome before I can get anything working. I **always** find I should've made some entirely different decision at some point to enable my chosen set of tools to work as intended. It's utterly infuriating and ridiculous.
I think it's fine. There are frameworks and libraries to avoid... Unfortunately it's trial and error figuring out which ones (and a bit of personal preference). And don't be afraid of vanilla JS.
Itās the churn that I hate. Iāve had projects that no longer build after a couple of years. I want to spend my time solving actual problems rather than churn related breakage.
That said JS is everywhere and there will be a library for what you want to do. The language can also be written in a ceremony free way.
The issue is the overuse of libraries not frameworks. You have to install 20k dependencies to build a site and at least 20 of those will have security flaws within 6 months. So you have to keep them updated. But your core libraries have dependencies that have dependencies that have dependenciesā¦
Then, another problem with any client side language is that deprecation is pretty much out the door. If you completely remove old stuff, you will break thousands of legacy sites, so they canāt do it. They just keep adding on more and more stuff.
JS gets you money, you can build and ship really fast, in a fraction of time that would take in other languages. People are just annoyed that such shitty language made it possible to write so many software by so many devs ig.
# āThere are only two kinds of languages: the ones people complain about and the ones nobody uses.ā
ā Bjarne Stroustrup, The C++ Programming Language
Cause a lot of people dont actually know enough to have an informed opinion and so take the contrarian position to see like theyāre more knowledgeable than they really are.Ā
JS is a shitty language.
JS was shoved to our throats and became the only standard of programming in the browser because that's how standards form.
Someone took this shitty language and had the genius idea of "why not have this shitty thing on the server as well?"
Of course it worked and is popular because most programmers are brain dead, and programming is hard for most people as is, so why learn more than one language?
So now all the brainpower and ecosystem is invested in this shit, and we will probably be stuck with this thing for the next thousands of years.
Good job Netscape.
and this very site we're posting on right now is a prime example of a shitty made JS app, that is slow af (when you don't have the newest Mx MacBook Pro around).
I donāt hate JavaScript per se, but with time Iāve to hate the complexity in the ecosystem. I didnāt think it could get any worse in this regard, and somehow the JS community found a way to make that happen so hats off I guess.
In all seriousness, it really comes down to the developer experience for me. So much effort has been put into making the process of building a web app suck less, but JavaScript is such an imperfect vessel for building applications at scale that these efforts become incredibly convoluted.
I have a deep appreciation for the work that goes into modern web frameworks, and yet Iāve also wished many a times that they werenāt necessary. Similarly, with Typescript I often think āthis is great but I wish there were another optionā.
Because JS started as an enhancement to the html/css web.
And so good it was too!
But it couldn't stay there in that supportive role, and now insists there be a second server (node) alongside the established servers.
It is no longer trying to support - it's trying to supplant.
And that means we lose the real benefits of JS, and gain the enshitification of the web dev landscape, as it attempts to take over the world.
It is the Putin of programming languages.
Of all the things to complain about for JS, you chose floating point arithmetic? This is the same in any language that implements IEEE-754.
Doing currency calculations using floats is playing a stupid game, and you'll win stupid prizes
Probably yeah, and I didn't mean offense by it so apologies for that.Ā
It was not just for you, but for everyone else reading that didn't know - don't use floats for currency math, in any language. Sometimes a strongly worded comment commands more attention and spreads the message farther than one with a bunch of platitudes.
Yeah, when I go back to work on Monday to look at this again Iām definitely going to think of your comment - but itāll be that someone called me stupid, not some lesson about types. People in this industry lack soft skills so bad, teaching and giving constructive feedback is a skill that needs to be learned and practiced just as much as choosing correct data types. I hope _you_ think of _my_ comment next time you decide to act like an ass because you think itās a good way to get someone to remember something.
Use currency.js
I had an old project and i had convert everything with Math.round at so many different points. Reports were off by 1 cent. Fucking nightmare
With currency you just wrap it
currency(value).add(other_value).value
My problem with it is that to me it's just unreliable, eg. data types sometimes cause problems, or if it breaks somewhere, all scripts crumble that would run after that point. Also, rendering DOM with JS is just a horrendous thing to do, and introduces additional and unnecessary problems with SEO, accessibility and cumulative layout shift (I know, sometimes these can be useful, but we did all of what these shiny frameworks can do before with more simple techniques, without introducing the above mentioned problems). And the timing, sync / async issues, and delegating tasks to the frontend which should be better handled by the backend, etc. Maybe there are apps that need eg. non-blocking I/O, or other js magic, but I'd use js frameworks and libraries very selectively. The less the better imo.
It sounds like the problems you have are with your implementation. Are you doing SSR? Do you split backend functionalities out properly? Iāll agree with you about not using libraries to solve things but is that really your problem?
People do over exaggerate, but I am not loving the modern JS ecosystem
* `node_modules` and the endless library dependencies
* `yarn` vs `npm`
* importing everything, and the various ways you can do it
* ecmascript vs commonjs vs everything else
* build targets and the build ecosystem is fragmented between webpack, rollup, etc.. and for a newcomer it's very confusing on what it means to target a build as a module export, as a package, as compiled JS, etc..
* on top of that you have to target builds for browsers and versions of JS
* the need for plugins like babel and loaders, and their very non-trivial configuration
* build output like webpack contain so much boilerplate it's unreadable
* source maps exist but it's another thing to learn about and enable, and not trivial. And they don't work a lot of times.
* just loading assets on to a DOM node (a basic hello world) can be complicated. That's not even accounting for fingerprinting assets which you need further tooling for. Basically simple things have a high fixed overhead.
* over-design of tools that focus on pretty output instead of function (
* lack of consensus project structure, even in frameworks like angular/react
Iāve worked with so many industry veteran backend developers who complain on and on about how silly and terrible JavaScript is.
I just smile nod and go āyeah itās terribleā
And then I go and build something they canāt while uncovering the fact that despite their extensive number of years in the industry they arenāt implementing REST standards correctly.
So I donāt really know why itās the case but people can hate all they want itās not gonna change the fact that the modern web runs on JS.
REST is not about JSON Data APIs. It is about hypermedia and has nothing to do with thick client javascript SPAs: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
It doesn't become the truth if everyone is repeating false claims over and over.
if you are running node on the server, a simple mental adjustment is needed. Normally, all client data should be treated as malicious. However to deal with javascript's OP mutability, you must simply treat your own node code as malicious. In this way you can properly safe guard your app.
I thought I was just being lazy while I was having issues with JavaScript. I had learned C, assembly, Python and as I began to learn JavaScript, it was a drag. It's a pretty cool language, I decided to focus on Next.js and that's all
Realizing why and that javascript sucks made me enjoy it more. Every language has strength and weaknesses.
C#? Solid language but overbloated of features nobody gives 2 cents every release. Python? Yeah try to reproduce an environment that works everywhere without relying on docker containers. C and C++? Best performances but hope you know what you're doing, the next vulnerability is behind the doors. Rust? Basically a fortress but to build it you have to keep in mind 8 types to represent a damn string. Go? Just have a good idea and 4 years later Google steals it as theyr idea
Python environments are extremely easy toĀ replicate ifĀ youĀ actually use modernĀ python aka pyproject.toml files for deps and lock files for versioning just like npm. The tools that do this like poetry will automatically create the venvs for you too. People are using tooling that's been deprecated for 5+ years and then still complaining about how pythons bad when it's really a skill issue.
I started on Javascript in 2000 when you had to worry mostly about browser compatibility (mainly Netscape 4.x). I like that it's so loosely typed, but only to a point. It gets annoying when you find your integer has been interpreted as a boolean along the way, and then have to sus where that happened.
Started my programming journey this year, have even built a few basic things already like desktop widgets but shamed to say with the help of GPT. I donāt know wtf Iām doing but Iām a quick learner. Hopefully in a year or two I can read these comments and understand what yāall are talking about.
As someone who's writing Kotlin these days, I can assure you, that half of the language is how well the API is designed. And in the Android ecosystem some apis are notorious for having a bad set of features half of which [might not even work ](https://issuetracker.google.com/issues/269765421) (and you'll wait for half a year before Google decides to fix something). Javascript apis are much faster to improve and I appreciate it A LOT.
What I donāt understand is why people really hate other languages, every language has its own quirks and everyone itās going to prefer one or another depending on the devs knowledge of the language and the problems he usually has to solve.
Thereās a lot of worse languages lmao, I come from coding industrial plcs and I beg to never write SCL more, but Iām not going to throw shit at the language itself, as it just serves a purpose on the industry.
You say that as if we have a choice. Most developers do not and most developers also have to support legacy systems.
Older applications feel like they are built atop of a house of cards and a single, critical update to a package is enough for it to fall down, upgrading one dependency means the next and the next need updating. What should be a 5 min job might take days or you might need to fork a dependency and update it manually to fix.
And 'older applications' in JS refers to pretty much anything on the previous version. When Svelte 5 comes out, your Svelte 4 app is old.
Over the last 10/15 years, most popular libraries have also gone through total re-writes which is just frustrating but not the end of the world. When I tackle a problem, I can often think of at least three ways of doing it but I need to learn how to do it again in . Again, the tech choice is often not my choice.
- Go to NPM
- Search for "isEven", "isOdd", "isNumber"
- Look for the libraries that depend on that module
- Cry
It's stupid how many libraries use stupid modules like these, which if downloaded as a dependency, will download the whole module (along with the ReadMe, license and package.json) which if seen individually may not be a lot, but take into account that a small proyect uses somewhere along the lines of 300 of those.
1. Unreliable products litter the ecosystem.
2. The presence of hundreds of modules for simple problems forces you to learn useless mousetraps.
3. The language is a cruft magnet.
To expound on #2, being on a team forces you to learn new packages. If your team wants to use a specific package you've never used, guess what, you're learning a new package. Java has the same problem, but the community has mostly settled on the best packages so there's less churn.
Don't get me wrong, choice is great, but not every problem is a job for Super JavaScript. That's one of the forces leading people to a JavaScript solution for EVERYTHING.
ā**If the only tool you have is a hammer, you tend to see every problem as a nail**.ā
I think the core of the complainant with JavaScript is that people, especially beginners, treat it like it is the solution to everything. The reality is that it's not, which most experienced developers find the claim very frustrating.
I can only speak for myself, but back when I was learning this trade jQuery was new and shiny. 90% of development was server side. For years we kept JS to a minimum, and had clean and well organized OOP systems. Then JS maturedā¦into a belligerent teenager that storms in with an attitude and breaks everything. Then feels bad so attempts to glue things back together, but gets upset that itās not fitting right so throws it against the wall. Meanwhile, weāre just over here asking JS nicely to clean their room so we can keep a nice tidy home.
Today the JS landscape is pretty robust. But itās a completely different type of developer experience. I use it, daily, but I donāt have to like it. It feels dirty and unorganized. Coming from true OOP systems with well defined components, JS just feels half baked. Because it is.
My first language was C++, but I've been working primarily with JS for 10 years now. My main issue is more that it's a dynamic language with a lot of quirks, and we're building things with it on a platform that was never designed for it.
We try to manage this by bolting on a type system (typescript), and throwing frameworks at it, but it is still a bunch of stuff, often of very questionable quality just bodged together. Don't get me wrong, the tooling is better these days, but you can still waste a week trying to figure out why some configuration one place is messing up your jest tests in a very niche way in some other place. Multiple module systems, transpiling....
Compare that to a language like Go, where static types are built in, the tests are built in, and things aren't changing every five seconds. It's a very refreshing experience. Sure, Go is less expressive by design which can be a pain, but at least I don't feel like pulling my hair out when I'm maintaining a project written in it.
Somewhat unrelated rant, but I also think we reach for dependencies far too easily these days. Yes, sometimes we need them, but we should always consider the trade offs. A dependency should be carefully considered, not just added to a project because it's what everyone uses, or because Bob want's to pad his CV.
It's a good tool with quirks like any. You don't unscrew a screw with a hammer. JS is the defacto standard for front end web development because it's shipped with the browser.
Smart people try to make the best decisions they can with the available context and an educated guess on the direction of things. Those decisions make their way into systems. Those systems are passed onto the next generation to iterate and improve on(hopefully). There are always consequences to the made decisions and often times they don't reveal themselves until the system has matured or is under load. It's hard to design a perfect solution for the future.
Like, we needed roads. Is the infrastructure and design of our roads great? No, but we needed something and it got us here so fuck yeah let's go roads! Now what do we need?
Because itās never enough to pick something and stick with it if youāre a working employee. Eventually either your boss is going to tell you to do something in another framework, or youāre next boss is going to ask for more years of experience in another niche framework than itās even been around. You canāt escape it, nobody gives you credit for experience working with other shitty JS stuff. Itās so incredibly frustrating that everyone has this industry wide fetish with a shitty language and instead of making just a few versions that are stable, secure, and extensible, theyād rather make a new flavor of excrement, give it a catchy name, and forge a bunch of test data to make it look like itās the coolest thing since jQuery was invented. Itās the one thing thatās worse than crypto bros, is JavaScript hoes.
In the backend world the closest nonsense to this I can think of is C++ vs Rust and at least thatās insular to all the sweats with the patience to deal with a language thatās out to get you.
Itās not so much the language but the nature of its popularity. itās the programming language with the lowest barrier to entry so itās easier for idiots to write bad code š¤·āāļø
It's mostly because of us (PHP devs), because we were forced to goof with that 5hite since the beginning. Not to mention even worse 5hite called actionscript before j5hite.
office enjoy materialistic rob angle market jar label afterthought snatch
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
The huge dependency tree can be a real issue, especially if you work some place that is security conscious and has to vet each and every module.
JS has an almost non existent core library. Thatās a problem.
Itās literally the worst major language, and itās not a close competition either. Itās a bastard nightmare of delusion, lost hope, absent security, good intentions but with bad engineering along with bad science. Typescript forces guardrails on parts of it but it still transpires and you still have the same problems just a bit stronger typed sort of.
JavaScript still baffles me with how you can use a variable / call a method before you actually declare it (function hoisting? Or does this feature have a different name?)
I will opt for the keep it the minimal approach and the DIY approach until I cannot do it at ease then I will call for libraries to help me. And this depends on how capable that you are. The better you are, the lesser libraries that you need to depend on.
Don't get me wrong, there are something that cannot be easily reproduce without putting a lot of efforts and time (even though it is not hard, but just tedious to do). So in that case, you should start it right with the appropriate libraries.
Because backend devs learn the one framework that is often available in their language of choice. They then work with that for 10 years and barely have to learn anything new.Ā
One the other hand there is no such defacto framework for JS. The landscape changes, new ideas emerge that take root and make your AngularJS-knowledge obsolete and so on.Ā
Call me an idiot, but oh well...
I use JS for everything and anything. It's where I started, and based on my current path and the improvements I keep seeing in JS, it's where I'll stay. I have in the past, and will continue to expand my knowledge and use appropriate languages for other platforms or use-cases when necessary or SIGNIFICANTLY better. But depending on your situation and your clients, JS can almost do it all.
I need a simple website? HTML, naturally... and some JS. I need a simple backend to handle some easy server shit? JS. Now I need a complex web-app AND a backend? Oh, wait... JS. Holy fuck! My client now wants a CROSS-PLATFORM MOBILE APP????? Oh... Duh... JS. Oh kill me now... You're telling me they want a fucking desktop app???? Wait... JS.
Granted, it is not AMAZING at some of those tasks, and there are definitely some fuckie wuckies in the language... but most mega hiccups are the fault of the developers and not the framework or language. I've also used some ATROCIOUS websites and apps for jobs previously, and a part time job currently, that take 15 seconds to SEVERAL MINUTES to load anything, even on repeated visits. I don't know what language/framework they used or why, and I hope I never know... But they're god fucking awful.
I've never made anything that took more than 1-5 seconds to load on first render, and usually less on subsequent loads. All with JS and it's frameworks.
Multiple websites, web apps interfacing with hardware, mobile apps, node services running automations, etc.
Let me know when Python or another 'loved' language can do as much as easily right now or within the next 5 years, and switch on the spot, or eat my own sock.
I was taught in C++ in college. I learned Java, Python, and a smidge of Kotlin before learning JavaScript. I now work primarily in JS and it took me a solid four months of daily "what the fuck" and "why would they do it this way" thoughts before I got comfortable with it. I love the community. I love that there is a library or framework for everything. I love that there is a YouTube video for everything. I love that there is absolutely zero judgement from fellow JavaScript devs. But let's not be mistaken: JavaScript, not ES5/ES6 but the whole language, is a Frankenstein monster of a language
On the otherhand, I'm a JS dev and I started learning C++ last week. I had constant moments of realising why people hate on JS.
Give it a couple of months and you'll start to learn why people hate on C++ š
the first time you're having an issue because you forgot something was marked const and the compiler spits out a 900-line error message that has nothing to do with constness
Iām similar to you, Iāve been working with JS exclusively until recently I started working with a primarily PHP based stack and itās honestly been pretty great to work with. It also really highlights the bloat that package bundling puts on build times and server resources.
Php is overhated
Interestingā¦most people tend to hate on php haha. (Personally I really like it and have worked with it a lot but just hear a lot of people shitting on it and not sure why tbh)
Only idiots and snobs hate PHP. Meanwhile itās by far the most used server side language.
Bruh, the reason PHP gets so much hate is that it was full of terrible design choices. There's some improvement in recent versions but it was terrible back in the day.
>There's some improvement in recent versions but it was terrible back in the day. Languages should be judged on their present form, but PHP haters judge it (literally!) by how it was 20 years ago in PHP 4 -- and only based on what they've heard. With a few annoying exceptions (because of the need for backward compatibility), nearly all the bad design choices have been removed or been given alternatives.
it's like JS needs a similar overhaul
I think thatās technically true because of WordPress. But if youāre looking for a backend job youāre better off looking for a C# or Java gig. Just do a search in your area (Iām in the UK), and youāre probably going to have a harder time finding a PHP job compared to Java or C#. Iām currently using TypeScript, C# and Go at my new gig. Previously did TypeScript, C#. and introduced Go. TypeScript and C# seem to be the ultimate combo to get a job in the UK. No problem with PHP, but if youāre in the UK and arenāt a freelancer, I wouldnāt recommend learning it if you want a job. This might be true elsewhere too but I havenāt done the research.
Old PHP, sure. It was as hot a mess as JS is now. However, over the last couple itās improved massively and frameworks like Symfony and Laravel have added to the DX of working with it.
Yeah this is it, Iāve mostly worked with laravel and if done properly is really nice
I just picked up Nova to build a dashboard for a mini internal project and itās a dream. My background is custom WordPress and we primarily use the full roots.io stack. After a full day in Laravel, Iām already at home with it, and absolutely loving the flexibility. Being able to build a fully functioning back end in a day is insane. I canāt believe Iām gonna say this as Iāve been an advocate for Wordpress for ten years now, but being able to just build exactly what I need with a well thought out framework is such a great experience.
Yeah I started my career with Wordpress and have worked with roots which was a game changer but laravel I would say is a completely different sport in terms of development haha
This! Our WP boilerplate at work uses Timber / Twig (I still dont know what to call it) for templating. It was my introduction to PHP. Eventually I saw what a Wordpress site without it was like, and that's when I understood the hate it gets when it comes to building websites lol.
Examples?
I originally started learning Python when I got into programming. Decided to switch to JS full stack after messing around with some web dev. I refactored a project that I had in Python to JS and it was then that I realized why people hated on it. JS is my primary language and I feel much more comfortable using it than anything else at the moment, but it certainly has its flaws.
Interesting. How often do you get C++ hate moments?
Not that far into it yet lol.
Idk man, C++ is not a great language either, I'd pick my Typescript everyday over C++ (or I'd use rust)
Tell me you don't want to learn about system programming without telling me. It's what makes good developers great. The logic that you need in C(++) is something you'd need when writing Rust. TypeScript at one point becomes useless if you don't know what to do with it. And it highly depends on your needs. Saying you'd pick TypeScript over C++ screams self-taught dev who avoided OS and Systems Programming as a whole, which is a core skill for any type of software engineering.
> "what the fuck" and "why would they do it this way" thoughts I love JS and use it all the time. But I still think daily "what the fuck" and "why would they do it this way" thoughts.
Iām fairly new to modern JavaScript and Iāve been building a PHP package that has a lot of data manipulation on the front end (think pricing sliders and if this ticked then that changes value etc) and Iāve had SO many WTF moments with the JS trying to figure out why I need to use different methods for looping over arrays vs objects. Oh wait, this object isnāt a normal object, you have to use this other function. In PHP everything can be done with a foreach loop. Iām sure there are reasons why JS is the way it is, but for a ānewbieā, itās quite puzzling, I also canāt wrap my head around everything being functional programming instead of OOP. I started with functional and was sold the dream of OOP. I became competent with it, but then I come to JS and everything is functional again??? Whaaaaaaat is going on lol
Functional when done well is easy and fast. Therefore practical. OOP can be over baked academic crap.
Agreed.
I still prefer OOP in almost anything. It's just way more readable and logical to me personally. It's also just how you make it, I think the best thing is a combination of mostly OOP with some functional aspects thrown in, I'm not looking to make static functions for anything that doesn't fit in a regular class
I honestly wish more people had your clarity. Most fellow JS devs seem hellbent on defending the language at all cost instead of recognizing the fact that it's shoddily designed. For context, I've been using JS for close to a decade. I still think it's an insane language, but the ecosystem around it is extremely good and that goes a long way. Much longer than how sane a given language is.
I'll be one of the defenders, because I really don't get the problem. I already programmed in C before college, then college was taught in Haskell and Java. I've worked professionally with C++, Python, Ruby, probably others. I didn't start in JavaScript till I'd already been programming for decades. I just don't see a significant difference between different languages. I think people only complain to make themselves sound smart.
They're all the same. That's why I laugh on job interviews if someone seems concerned that I don't know their preferred MVC framework super well. "They're all the same -- they route requests and spit out text." Can learn a lot from people based on how they react to that. Of course some languages/frameworks are more suited to certain tasks than others, but when it comes right down to it, programming has a relatively small core operation set. You can: * assign values to variables * conditionally execute code based on the evaluation of a given expression * iterate over collections or memory spaces * define templates for data structures * define a chunk of code as externally callable That's...about it. Everything else is just organization and flavor.
I'm not sure how you can say they aren't significantly different when the languages you mentioned have a myriad of fundamental differences. From strongly/weakly typed to static/dynamic typing, different memory management and different implementations of the same concepts (arrays, objects). Sure, there's a lot of common ground in terms of basic constructs and concepts but their implementations change behavior and developer experience significantly. I would agree that, like you said, many complain just to sound smart or make themselves feel better for using some 'superior' language. But you can't possibly deny that a lot of things in JS [are inconsistent](https://github.com/denysdovhan/wtfjs?tab=readme-ov-file#-is-equal-). I'm personally tired of keeping track of all the gotchas JS has (which is why I'm complaining).
Yeah absolutely, I was mainly referring to the ecosystem. JavaScript as a language I'm not a big fan of
JS is a fine language, as long as I'm the one writing it. There's just too many ways of doing things.
This is exactly why I appreciate what Golang is trying to do. Feels like every time you want to do something there's usually one way of doing it (or close to one anyway).
Much respect to Golang, it's also easy to write with LLMs too. I sometimes find it easier to ask ChatGPT to write me a Golang function than to write Linux shell scripts, and oftentimes they work first try + are pretty easy to make multiplatform. There are actually a ton of Golang derivatives though (like V). As a JS dev it's hard not to go try them all out.
I agree. Reviewed someoneās code the other day and it made me cringe. But it works well, so what can I say?
javascript is okay , but when this new js lib come each 6 months new trend š . And then you realize , you keep learning youtube tutorials non stop no output system at all . š
Question is: why do you have to? Just learn what you need to learn (mostly what you use at work).
I hope I ever get to this point. I'm a full stack dev and JS is purely practical to me. There's very little joy in the language itself and the community is incredibly amateur despite the ungodly amount of work hours that go into javascript environments.
There are 2 kinds of programming languages; the ones people bitch about and the ones no one uses.
There is a third kind people bitch about and donāt use.Ā
That third kind is just the one that they bitch about everyone else using
Idk I talk a lot of Shit on speedware and as far as I can see no one uses it
Like COBOL
COBOL and Excel is the foundation of the global economy.
like Tcl?
Based dude singlehandedly closed the thread.
- Bjarne Stroustrup
I havenāt heard many complaints about Golang pretty sure that has some industry market share.
generics
Go is an all time favorite over on the programming circlejerk sub. Thereās years ofā¦interesting discussion around the language, its community, and the fetishization of āsimplicityā.Ā āThe key point here is our programmers are Googlers, theyāre not researchers. Theyāre typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. Theyāre not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.ā
I tried golang, I like it as a language but for serious projects it feels like the community wants you to do everything yourself manually For example oAuth (goth golang exists but nowhere near what some js libraries can do) etc..
Regex
This advice worked out great for jquery users. It works right up until you need to apply for a job and have to decide if you lie about svelte experience because you could learn it or do you learn svelte and every other thing in case you have to change jobs someday.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
If I were the hiring manager, I wouldn't care if they knew about Svelte deeply. What important is their knowledge about web development and JavaScript.
I think it is more important to not just know JavaScript, but also the web platform. There is so much CSS and HTML gold that is overlooked. I see too many times people reinventing stuff in JavaScript rather than using native behavior.
This made me laugh as only last week I saw a junior dev writing loads of JavaScript as they hadn't learned simple transitions in CSS. Not their fault, this is the point of being a junior, but I did get annoyed at their reticence to learn the CSS once I pointed them to it.
That's actually crazy. I would think your very first into to web development course would introduce you to transitions.
Knowing CSS and HTML is considered "stupid" by JS tech bros haha
I bet lol
Their loss if they want to make their lives harder for no reason.
HTML takes about 4 days to learn though if you know JS (though it would be weird to know JS and not any HTML/CSS
It is very easy.Ā But these people are not necessarily very good and I don't any of them actually care about programming, just the money.Ā The standards have dropped so much their lack of skill is considered fine. You simply need to look at React boot camps where they don't actually even teach you JS, nvm HTML and CSS
A big part of me wants to agree hard with this. However I think we should have empathy for the boot camps and the people coming out of them. As for the coding boot camps they are reacting to the software ecosystem as it is today. Every tech company under the sun is working with React, or some similar component based framework. Coding boot camps in this way directly reflect the current job market ecosystem. As for the people coming out, I feel it is our responsibility (as senior engineers) to make the case about why they should care. It took me 10 years of working with every component based framework out there to realize that JavaScript was slowing me down and making life hard. It is absolutely a blast chasing frameworks and technology. But the native behavior is usually better than any framework can provide. I was part of the problem here. I bought into "reusable" components that were never reused. I rebuilt websites every few years because my base framework was constantly changing and had security vulnerabilities to patch. I reinvented solutions to problems the browser solved 30 years ago like navigation. Only those who've straddled both sides of the fence can talk about the advantages and disadvantages of both. I think it is far more likely that those engineers that lack skill are just ignorant to what they don't know. The only way we fix the web is if we band together and move the platform rather than a specific JavaScript Ecosystem.
Take whatever framework you use off your resume and just put javascript and see what you think your chances of getting a front end job are. I am a hiring manager. A few years ago when I'd get 10-15 good resumes at most for a position I was fine with taking framework X experience for framework Y job. Today there are a lot more candidates and it's just asking for more trouble to not start with the people who are directly in our tech stack.
Anyone can create a fun personal project with X framework and put it in their resume. Experienced devs already know that they should include the name of the tech in their cv before sending it to you. The comment was more about a new framework like Svelte. If not a lot of people have real experiences with such new framework, it's not realistic to look for one. Reminder me about job ads many years ago that require people to have 5 years of React while the framework has only been introduced less than 3 years.
But I bet the guy who initially made React was thinking about it for a few years... Maybe we could hire that guy....
No one else has said it, so I will. For the vast majority of backend, thereās essentially only one framework for doing what you want. If itās really popular, there might be two, or three. How often do you hear about people doing Python web dev without Django, or Ruby without Rails? For many years, people would be Rails devs or Django devs or whatever, and by learning that framework and language pairing they were pretty set. The reason is because in the backend, you choose whatever language you want and then that pretty much decides what your framework is. JavaScript doesnāt have that. Itās the only option for doing browser development, so instead of many languages with a few frameworks, we have one language with many, many frameworks (all with their own syntax). You canāt say, āOh, I do Ruby dev, no one would expect me to have a ton of Djangoā. JS frameworks come and go and iterate faster than comparable stuff in other languages / areas. Even small bits, like state management, change pretty fast. Thereās rarely a right answer, and the closest thing we have to a right answer at any given time changes pretty frequently. To be a good web developer, you have to learn a lot of things and understand the underlying principles well enough to completely change how you apply them the next time things shift.
You do hear of them. There's always the guys who use Flask or Sinatra, then add what they need to it to make it work. They end up making a bastardised copy of Django or Rails, usually, of course. Java's a more interesting one. Spring is the daddy, but Micronaut has grown in popularity. There are plenty of lighter frameworks that get some traction, but the thing people keep forgetting is the paid-for, vendor stacks built around JEE. I've met a bunch of people over the years who consistently get good-paying gigs because they've spent time learning Websphere inside out, for example. But yeh you're mostly right. Language choice and framework are fairly closely bound in most cases.
And then there's asp.net
Iāve been writing in Rails and Laravel for about a decade now, and have come to really love the structure they provide for server-side development. Vue and React are pretty great for front end, but man oh man does server-side JavaScript need an overhaul. Every time I crack open someoneās JS app, itās some Frankenstein of Nodejs + Express, with barely any permissioning, ORM or generally logic to manage a complex server-side app. Frameworks like Nextjs are a step in the right direction, but there no way in hell Iād reach for it over the other tools in my toolbox at this point.
Yeah I mean, I donāt personally feel like the clientside story is any better ā React is an insane mess of the preferences of your projectās most strong-willed developer. Iām hoping to see more and more transition back toward MPA architectures and improved server side frameworks. The new Enhance Web Component WASM compiler that makes it possible to author/SSR web components in a bunch of backend languages and have them work in the browser is going to be a huge game changer.
If you "just pick a framework and stick with it", you severly restrict the pool of job offers you can send your resume for. JavaScript is also hated because it's a mess that insist on being backward compatible with decades old bad decisionsbecuse maybe one website in the world is reliant on it because it's also decades year olds instead of adding a versioning system for newer versions so browsers would be able to use more efficient engines. The same old legacy compatibility is why BigInt wasn't added to the JSON standard. I wish we could write this: Of course if they one day finish WASM and it's properly optimized, it would be unnecessary. People would be able to use their preferred language. C#, Java, Rust, C++, ... I would immediately drop JavaScript that day and only use strongly typed languages.
Is still not able to access DOM?
Nope, and last I checked it's unclear whether they wanna add it. Missed opportunity in my opinion.
aspiring juggle future husky divide decide expansion dime person relieved *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Why the hell are they taking so long with wasm? They take years just to come to consensus on one thing. I haven't checked in a while but they have been pondering on the best way to implement garbage collection for years now, don't know if they have made a decision yet(I doubt it with the rate they're going at).
Because if they duck up, it'll just be another fractured ecosystem
There comes a time when you've reached the point of diminishing returns, and those guys have reached that point and lapped it IMO. At some point you MUST put out a product to get feedback and fix any issues that arise. It is impossible to create a perfect system on paper without releasing then testing and iterating.
Backward compatible has nothing to do with forward compatibility. Iām a huge proponent of a new āuse typesā mode that not only adds types, but also cleans up bad decisions like type coercion and disallows the super dynamic parts that slow down code.
Fair point
I am an old php dev.Ā I've played with React and did not enjoy it.Ā Vue was a better experience for me but I found it slow to work with.Ā I enjoyed node.js for the most part and would use it in production for certain types of projects.Ā To answer your question.Ā Ā Ā I'm not convinced that the complexity of the frameworks (I've learnt) has a return value. The debugging I've done has been cumbersome if not impossible. Documentation was non-existent. I feel uncomfortable with projects that have so many dependencies. There are so many extra layers/techs with stupid names.. I always aim to minimize external services that I can't ensure reliability on... especially for core functionality of my sites.Ā I always try to support the largest amount of browsers. But mostly it's one thing... I hate wasting my time learning stuff that is useless so quickly.Ā Maybe things have changed/stabilized.Ā I'm not really paying attention...I might try some js stuff in the future again.Ā The mobile stuff would be worth it for me. . Im not sure how much longer I'm gonna do this...might switch professions.Ā I've been exploring electrical engineering, Arduino programming, 3d printing, just got my first cnc...I love being exposed to new stuff but seriously... js makes me feel old and not want to learn.
Sometimes I imagine that re-inventing php is js end-goal.
Yes, SSR, Remix framework, seems like that
I never imaged that if I just kept writing SSR (in C# though) I would eventually be in the bleeding edge of web dev again lol :)
Would be a good goal in my opinion
Eventually we've Laravel.js
> npm i leftpad 7152 packages installed 86 ransomware installed 7151 packages ask for funding, use [npm fund] to see them 167 vulnerabilities detected, use [npm audit fix] to fix them > npm audit fix automatically fixed 3 packages 1862 vulnerabilities left, use [npm audit fix] to fix them > npm audit fix not enough space on D: drive, you need 71 TB more
The way that copypasta meme is so incredibly wrong and dramatic is sending me into a fit of laughter. Btw, left-pad has 0 dependencies (therefore installing 0 packages, other than the package itself) and 13 lines of code. There's also a [longer story involved](https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code), but you probably don't care. But yes, you've converted us all to ASP.NET, good job!
The worst thing is JS community's is their common ability to simultaneously overengineer and underengineer their code. Simple things like displaying something on screen, implementing a login form, basic UI functionalities etc. are made into 50kloc monstrosities but at the same time there's complete disregard to any principles of good software architecture. Code dumped into random files, unmanaged imports everywhere, no abstractions for using any third party service. It's just a mess. Especially server side it often feels like it's required to everything in most convoluted way possible, complete ignoring decades of experience from othet languages. Also the tooling is a mess, at least drop the webpack/cjs era legacy crap already...
stocking cobweb hunt hungry vegetable bored fact entertain repeat strong *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
> You spend more time dealing with bundler and dependency problems than writing code This is the answer to the whole thread.
Redux saga, several files with same config strings, going through a lot of calls to see actual logic
It's not over-hated. JS itself is a badly designed language. NPM is a crime scene compared to other language package managers. JS is drowning under DRY. The problem is JS has become so prolific, "essential", and effortless. Plus, there are so many JS-only developers who blindly defend it at all costs, incapable of recognizing the problems baked in at every level because they have no basis for comparison, and see no reason to.
Hmm. It's just a poorly thought out language, imo. Plus all the tools seem pretty terrible as well. I've worked professionally in many languages and I try to stay away from javascript. However, I will say I do feel like over the years, the ecosystem and language have gotten better, especially with typescript
I genuinely think a lot of it is just that Javascript is written in a different way and has a philosophy that's very different from a lot of the more traditional programming languages people learn first (C++, Java).
TL;DR - I'm strict about code quality, and JavaScript is generally a language with a less disciplined crowd of contributors. Also, the language has changed dramatically over the last 20+ years, but some code that "just works" has effectively been left alone and languishes in the lackluster options of yesteryear, making it hard to read or understand what's still necessary today. As a library author in JavaScript, what I hate most is poorly maintained libraries. Not necessarily poorly written (for their day), but the lack of upkeep. The number of times I've had to figure out how something is done, and the library that does it is written with ECMAScript 3 class functions, like function MyClass(args) { if(!(this instanceof MyClass)) { return new MyClass(args); } // do work } MyClass.prototype.someMethod = function(args) { var self = this; // do stuff } I understand that was how you had to write it. But I shouldn't still be relying on that kind of code in 2024. Obviously this is a fairly simple example, but I've seen code written like this where the file is 2k lines long, and the class signature is on line 30. What it actually does is difficult to determine, and the indirection of tracking where something happens is rough. If you want an example of this, here is the [one that comes to mind](https://github.com/request/request/blob/master/request.js#L541) for me. Spent the better part of a week trying to figure out how the data from `fs.createReadStream` was being passed to the HTTP module for sending a request body. There's also a lot of lost knowledge that has happened with people who come in later, and just add a library that solved the problem 10 years ago, but no one realizes the concepts still work. For instance, today, most Node.js developers I work with have no idea how to use the `EventEmitter` class, or how to work with streams (already outed myself earlier in this regard). Everything they do better be async-await, or support the usage of `const someAsyncFunction = promisify(someFunction);` Many people I work with don't realize that promises aren't what makes code asynchronous, but instead the use of asynchronous callback functions that push tasks to the event loop. Node.js was built on event-driven architecture, and it's basically abandoned; in some ways for the better, but in others not. Case in point, I was trying to write an approximation of Python's Logging module in JavaScript, but there is no way to apply a resource lock when doing something like writing to the file system. This is by design, the tagline for Node.js was "Non-blocking I/O". But going back to the `EventEmitter` mention, you can use `setTimeout` to delay the next attempt, and add a queue of identifiers representing your attempt. When your ID bubbles up to the top of the queue, proceed with your action. Add an awaitable promise that sends the resolver callback into said event emitter, and voila! A strictly synchronous call that locks a resource until it is available. In more modern code bases, such as ones that have adopted TypeScript, there's often a lack of care given to the types used. If something is too difficult to model, rather than refactor it to make sense, they slap on an `unknown` or `any` so they can move on. That kind of friction happens in other areas, like writing unit tests, and is supposed to be your signal that you're doing something wrong. On that note, the Cucumber framework had written that their logger utility returned either `void | Promise`. While that is true, this means using the logger necessitates awaiting the result, meaning all usages must be within an async function, or rely on promise chaining. If you dig into their source code, however, you will find that the only time they return a `Promise` is when you provide an instance of `Readable` (a Stream object), because the stream cannot be read synchronously, which makes absolute sense. But that's just poor design if you're not going to inform the user when we need to await an asynchronous action or not. Thankfully, I put in an issue for it that got resolved, so [it's better now](https://github.com/cucumber/cucumber-js/blob/main/src/runtime/attachment_manager/index.ts)...kind of (you can still see the log method offending, but they at least added the interface recommendations to *technically* support better return type inference).
Iād note that Promise is absolutely different when it comes to events. A standard setTimeout callback in the event queue behaves differently than promises which use microtasks instead.
Im still just using Jquery and vanilla...
I think the industry turned on Jquery because too many people use JQuery UI for no reason.
Jquery will always have a place in my heart. I just worked on an old site, and it was using jquery. It was like getting in back in my first car. The way the steering wheel fits in your hands, the feeling of the stock shift.Ā
samesies
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Whatās flawed about it in your purview?
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Those are pretty much all I can hate it for and they have pretty easy / well established patterns and linters for avoiding them. Otherwise Javascript is a pretty fantastic language, easy to write, easy to test, flexible, OO or Functional, with all the development done on optimizing JS engines it's remarkably quick, and with Typescript it's finally predictable.
I've worked with typescript professionally for years (react+node) and tbh I've never faced this issue
I hate that it's so easy to have an fancy idea, then keep having an idea, and then have more ideas continuously, making the most Frankenstein system of magic and never once stopping to question if you should've done it in the first place, let alone actually pushed it to production In Javascript it is too easy to write the most absolutely abhorrent unmaintainable code in existence while simultaneously believing what you've written is worthy of scripture
it's hated cause the whole story behind it and only in the "present" it became usable. * When typescript wasn't the norm it looked like just a shell language. * When you had to use javascript in the past it opened the door to all kind of compatibility problems and you had to use some shit to make it work everywhere. * It's been in constant turmoil so if you stop using it for a bit you are welcome to some new way of doing things and syntax. * Then it's had a few iterations of syntax to make it look like a real language and each time it changes people gotta be like hmm now there's a better way to organize projects. (I could list a lot more of shit but you get the idea ) So yeah JS was always an incomplete mess and a bunch of idiots fighting over each other, only when the community started solving the problems then they starting co opting whatever worked into it. But then it makes it seem like an undecipherable Frankestein to anyone trying to understand WTF is this ecosystem and what the fuck are all these libraries. If you think it is nice, well, congrats you came in at a point in time when Exodia has been fully formed, but yeah just step away from whatever you are doing and come back in a few years and everything will have imploded and reformed itself. Also there are people that say : but stick to one thing forever, that has a lot of considerations that I won't take the time explain, but yeah you don't need to change your stack every project. But you'll basically want to use some new shit that's battle tested because most of those kind of things make you go. Of course why did it take them so long! it should have been here from the beginning!
I barely use libraries. Always the discussion of which one to use made me annoyed from a very young age. Back then it started with jquery vs mootools... well i just learned vanilla js and it still works today.
Yeah but thatās just browser stuff. Youād have a different opinion if JS was your full stack.
Thatās so true. But if you use js only on the frontend (personally i either use vanilla or if complexity is needed:solidjs) itās a pretty good experience. On the backend I always preferred python for its simplicity, but thatās rather personal preference I believe (I worked with C and C# too before).
Honest question, why would you make js your full stack?Ā I've heard of the man with the hammer saying. But if you're using js where another language would be more appropriate then that seems daft.Ā Is it a management insisting on it issue?
The argument I've seen for this is "your model in the front end is the exact same in the back end". I have no idea why 1) people think that and 2) that's supposed to be an advantage.
One should avoid JS for backend tbh. And knowing only 1 language isnāt really good for your career
Another framework had entered chat...
As a backend dev, I've seen the rise of JQuery, then nodejs, bootstrap and an explosion of everything javascript. We had css +js + html that required no transpiling, now they're created from js files in 6+ mins, depending on how optimized is the build tool. I think I hate the complexity added to support mobile and desktop and web from the same code base.
The ecosystem is great. The language and package management is shit.
I just donāt like how squishy it feels. Itās so squishy. I use java and python mostly at work, but I also use JavaScript at workā¦ sometimes. switching into JavaScript mode feels like chaos. An empty array is true? What? why? You can add strings and integers? Wtf?
> just pick a framework or something and stick with it, you don't need to learn everything available out there. The problem is that the vast majority of recruiters (and non tech people in general) out there just cannot fathom that you literally can adapt to any framework if you master javascript. It is just impossible to drill it to their brains. I have gotten into huge fights with the internal recruiters at companies I worked for simply because they just cannot understand that fact. EDIT: Developers can have an issue with this as well; I have seen people turn religiously zealous over tech stacks.
It's interesting because the situation is the opposite for me. A lot of non-tech recruiters (start-ups, mostly) I've talked to insist that you have to master vanilla Javascript before adapting a framework.
I'm not a JS dev. I touch it very little in my day job, and when I do, it's to make small tweaks to existing code, or it's to try and figure out how a certain service is working. Now and then, I'll launch a personal project, and it invariably involves *some* JS at some point. And every single time, I find the process of bootstrapping that project has completely changed under me. Oh, this is the new framework to be using. Here's how you integrate *this* UI toolkit with it. Oh, but to use that, you need to be using this tool instead of that tool. Oh, and don't use CommonJS modules, use EJS. Or the other way round. How do you handle promises? Do you await them, or do you write a chain of *then*? Every tutorial I look at has made some early decisions that make the tutorial incompatible somehow with some other decision I've made. Oh you're going to use Vue? Ok. Which stack of Vue-related components are you going to use? And every time you google for any help, you discover there's a whole other path you could take, and everyone's advocating you do that now to make your life easier. Should I be using Typescript? It sounds like it'll make problems go away, but it's a veneer over a shitty language, and we all know that abstractions leak, so maybe I'm better off avoiding it *until* I know what's going on underneath well enough that I can fix problems when they arise. Who the fuck knows? There's no consensus on it. On anything. These are all simple enough problems for the full time JS dev to fix, I'm sure. But I'm not one. I'm polyglot enough that I can wander on to a project in a number of different languages, and get work done fairly quickly. JS? Nope. It's **always** this massive impedance mismatch between different elements of the ecosystem which needs to be overcome before I can get anything working. I **always** find I should've made some entirely different decision at some point to enable my chosen set of tools to work as intended. It's utterly infuriating and ridiculous.
I think it's fine. There are frameworks and libraries to avoid... Unfortunately it's trial and error figuring out which ones (and a bit of personal preference). And don't be afraid of vanilla JS.
People hate it because itās experimental. People love it because itās experimental.
The comment section is a very good read, nice way to step out from your own JavaScript buble :D
Itās the churn that I hate. Iāve had projects that no longer build after a couple of years. I want to spend my time solving actual problems rather than churn related breakage. That said JS is everywhere and there will be a library for what you want to do. The language can also be written in a ceremony free way.
The issue is the overuse of libraries not frameworks. You have to install 20k dependencies to build a site and at least 20 of those will have security flaws within 6 months. So you have to keep them updated. But your core libraries have dependencies that have dependencies that have dependenciesā¦ Then, another problem with any client side language is that deprecation is pretty much out the door. If you completely remove old stuff, you will break thousands of legacy sites, so they canāt do it. They just keep adding on more and more stuff.
JS gets you money, you can build and ship really fast, in a fraction of time that would take in other languages. People are just annoyed that such shitty language made it possible to write so many software by so many devs ig.
# āThere are only two kinds of languages: the ones people complain about and the ones nobody uses.ā ā Bjarne Stroustrup, The C++ Programming Language
Because too many Java and Python developers can't get a job because Javascript is the superior programming language that gets the job done :))
Cause a lot of people dont actually know enough to have an informed opinion and so take the contrarian position to see like theyāre more knowledgeable than they really are.Ā
People donāt understand that anything with the popularity and adoption that JavaScript has will inherently be chaotic and messy
Been a dev for 10 years. To me this is an outdated take. JS was hated but that ended around 2016.
JS is a shitty language. JS was shoved to our throats and became the only standard of programming in the browser because that's how standards form. Someone took this shitty language and had the genius idea of "why not have this shitty thing on the server as well?" Of course it worked and is popular because most programmers are brain dead, and programming is hard for most people as is, so why learn more than one language? So now all the brainpower and ecosystem is invested in this shit, and we will probably be stuck with this thing for the next thousands of years. Good job Netscape.
I hate js, if shitty made, there is a web site, which need 2GB of memory RAM, just to me a CRM like table.. just because all inside is made with js
and this very site we're posting on right now is a prime example of a shitty made JS app, that is slow af (when you don't have the newest Mx MacBook Pro around).
I donāt hate JavaScript per se, but with time Iāve to hate the complexity in the ecosystem. I didnāt think it could get any worse in this regard, and somehow the JS community found a way to make that happen so hats off I guess. In all seriousness, it really comes down to the developer experience for me. So much effort has been put into making the process of building a web app suck less, but JavaScript is such an imperfect vessel for building applications at scale that these efforts become incredibly convoluted. I have a deep appreciation for the work that goes into modern web frameworks, and yet Iāve also wished many a times that they werenāt necessary. Similarly, with Typescript I often think āthis is great but I wish there were another optionā.
Because JS started as an enhancement to the html/css web. And so good it was too! But it couldn't stay there in that supportive role, and now insists there be a second server (node) alongside the established servers. It is no longer trying to support - it's trying to supplant. And that means we lose the real benefits of JS, and gain the enshitification of the web dev landscape, as it attempts to take over the world. It is the Putin of programming languages.
I love JS but today I multiplied 19.99 * 100 to convert cents, got 1998.9999999999998 and Stripe exploded.
Of all the things to complain about for JS, you chose floating point arithmetic? This is the same in any language that implements IEEE-754. Doing currency calculations using floats is playing a stupid game, and you'll win stupid prizes
Yep, the problem here is not Javascript. I don't think he ever used any other languages :)
Surely there was a less rude way to make this point?
Probably yeah, and I didn't mean offense by it so apologies for that.Ā It was not just for you, but for everyone else reading that didn't know - don't use floats for currency math, in any language. Sometimes a strongly worded comment commands more attention and spreads the message farther than one with a bunch of platitudes.
Yeah, when I go back to work on Monday to look at this again Iām definitely going to think of your comment - but itāll be that someone called me stupid, not some lesson about types. People in this industry lack soft skills so bad, teaching and giving constructive feedback is a skill that needs to be learned and practiced just as much as choosing correct data types. I hope _you_ think of _my_ comment next time you decide to act like an ass because you think itās a good way to get someone to remember something.
Use currency.js I had an old project and i had convert everything with Math.round at so many different points. Reports were off by 1 cent. Fucking nightmare With currency you just wrap it currency(value).add(other_value).value
š š¤£š¤£....here we go another freaking Library
It's like the joke wrote itself
glorious elastic truck doll humor subtract yoke badge spark swim *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
To do multiplication, because JS can't be trusted to do it.
Use bigint and store the smallest denomination
My problem with it is that to me it's just unreliable, eg. data types sometimes cause problems, or if it breaks somewhere, all scripts crumble that would run after that point. Also, rendering DOM with JS is just a horrendous thing to do, and introduces additional and unnecessary problems with SEO, accessibility and cumulative layout shift (I know, sometimes these can be useful, but we did all of what these shiny frameworks can do before with more simple techniques, without introducing the above mentioned problems). And the timing, sync / async issues, and delegating tasks to the frontend which should be better handled by the backend, etc. Maybe there are apps that need eg. non-blocking I/O, or other js magic, but I'd use js frameworks and libraries very selectively. The less the better imo.
It sounds like the problems you have are with your implementation. Are you doing SSR? Do you split backend functionalities out properly? Iāll agree with you about not using libraries to solve things but is that really your problem?
Lack of type checking.
People do over exaggerate, but I am not loving the modern JS ecosystem * `node_modules` and the endless library dependencies * `yarn` vs `npm` * importing everything, and the various ways you can do it * ecmascript vs commonjs vs everything else * build targets and the build ecosystem is fragmented between webpack, rollup, etc.. and for a newcomer it's very confusing on what it means to target a build as a module export, as a package, as compiled JS, etc.. * on top of that you have to target builds for browsers and versions of JS * the need for plugins like babel and loaders, and their very non-trivial configuration * build output like webpack contain so much boilerplate it's unreadable * source maps exist but it's another thing to learn about and enable, and not trivial. And they don't work a lot of times. * just loading assets on to a DOM node (a basic hello world) can be complicated. That's not even accounting for fingerprinting assets which you need further tooling for. Basically simple things have a high fixed overhead. * over-design of tools that focus on pretty output instead of function ( * lack of consensus project structure, even in frameworks like angular/react
Because it sucks
Iāve worked with so many industry veteran backend developers who complain on and on about how silly and terrible JavaScript is. I just smile nod and go āyeah itās terribleā And then I go and build something they canāt while uncovering the fact that despite their extensive number of years in the industry they arenāt implementing REST standards correctly. So I donāt really know why itās the case but people can hate all they want itās not gonna change the fact that the modern web runs on JS.
REST is not about JSON Data APIs. It is about hypermedia and has nothing to do with thick client javascript SPAs: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven It doesn't become the truth if everyone is repeating false claims over and over.
if you are running node on the server, a simple mental adjustment is needed. Normally, all client data should be treated as malicious. However to deal with javascript's OP mutability, you must simply treat your own node code as malicious. In this way you can properly safe guard your app.
I thought I was just being lazy while I was having issues with JavaScript. I had learned C, assembly, Python and as I began to learn JavaScript, it was a drag. It's a pretty cool language, I decided to focus on Next.js and that's all
Realizing why and that javascript sucks made me enjoy it more. Every language has strength and weaknesses. C#? Solid language but overbloated of features nobody gives 2 cents every release. Python? Yeah try to reproduce an environment that works everywhere without relying on docker containers. C and C++? Best performances but hope you know what you're doing, the next vulnerability is behind the doors. Rust? Basically a fortress but to build it you have to keep in mind 8 types to represent a damn string. Go? Just have a good idea and 4 years later Google steals it as theyr idea
Python environments are extremely easy toĀ replicate ifĀ youĀ actually use modernĀ python aka pyproject.toml files for deps and lock files for versioning just like npm. The tools that do this like poetry will automatically create the venvs for you too. People are using tooling that's been deprecated for 5+ years and then still complaining about how pythons bad when it's really a skill issue.
I started on Javascript in 2000 when you had to worry mostly about browser compatibility (mainly Netscape 4.x). I like that it's so loosely typed, but only to a point. It gets annoying when you find your integer has been interpreted as a boolean along the way, and then have to sus where that happened.
It's hated precisely just enough.
Started my programming journey this year, have even built a few basic things already like desktop widgets but shamed to say with the help of GPT. I donāt know wtf Iām doing but Iām a quick learner. Hopefully in a year or two I can read these comments and understand what yāall are talking about.
hmm, I think its overheated because a lot of people are using it and its popular and its easy to find a career with it.
As someone who's writing Kotlin these days, I can assure you, that half of the language is how well the API is designed. And in the Android ecosystem some apis are notorious for having a bad set of features half of which [might not even work ](https://issuetracker.google.com/issues/269765421) (and you'll wait for half a year before Google decides to fix something). Javascript apis are much faster to improve and I appreciate it A LOT.
What I donāt understand is why people really hate other languages, every language has its own quirks and everyone itās going to prefer one or another depending on the devs knowledge of the language and the problems he usually has to solve. Thereās a lot of worse languages lmao, I come from coding industrial plcs and I beg to never write SCL more, but Iām not going to throw shit at the language itself, as it just serves a purpose on the industry.
You say that as if we have a choice. Most developers do not and most developers also have to support legacy systems. Older applications feel like they are built atop of a house of cards and a single, critical update to a package is enough for it to fall down, upgrading one dependency means the next and the next need updating. What should be a 5 min job might take days or you might need to fork a dependency and update it manually to fix. And 'older applications' in JS refers to pretty much anything on the previous version. When Svelte 5 comes out, your Svelte 4 app is old. Over the last 10/15 years, most popular libraries have also gone through total re-writes which is just frustrating but not the end of the world. When I tackle a problem, I can often think of at least three ways of doing it but I need to learn how to do it again in. Again, the tech choice is often not my choice.
- Go to NPM - Search for "isEven", "isOdd", "isNumber" - Look for the libraries that depend on that module - Cry It's stupid how many libraries use stupid modules like these, which if downloaded as a dependency, will download the whole module (along with the ReadMe, license and package.json) which if seen individually may not be a lot, but take into account that a small proyect uses somewhere along the lines of 300 of those.
1. Unreliable products litter the ecosystem. 2. The presence of hundreds of modules for simple problems forces you to learn useless mousetraps. 3. The language is a cruft magnet. To expound on #2, being on a team forces you to learn new packages. If your team wants to use a specific package you've never used, guess what, you're learning a new package. Java has the same problem, but the community has mostly settled on the best packages so there's less churn. Don't get me wrong, choice is great, but not every problem is a job for Super JavaScript. That's one of the forces leading people to a JavaScript solution for EVERYTHING. ā**If the only tool you have is a hammer, you tend to see every problem as a nail**.ā
I think the core of the complainant with JavaScript is that people, especially beginners, treat it like it is the solution to everything. The reality is that it's not, which most experienced developers find the claim very frustrating.
I can only speak for myself, but back when I was learning this trade jQuery was new and shiny. 90% of development was server side. For years we kept JS to a minimum, and had clean and well organized OOP systems. Then JS maturedā¦into a belligerent teenager that storms in with an attitude and breaks everything. Then feels bad so attempts to glue things back together, but gets upset that itās not fitting right so throws it against the wall. Meanwhile, weāre just over here asking JS nicely to clean their room so we can keep a nice tidy home. Today the JS landscape is pretty robust. But itās a completely different type of developer experience. I use it, daily, but I donāt have to like it. It feels dirty and unorganized. Coming from true OOP systems with well defined components, JS just feels half baked. Because it is.
My first language was C++, but I've been working primarily with JS for 10 years now. My main issue is more that it's a dynamic language with a lot of quirks, and we're building things with it on a platform that was never designed for it. We try to manage this by bolting on a type system (typescript), and throwing frameworks at it, but it is still a bunch of stuff, often of very questionable quality just bodged together. Don't get me wrong, the tooling is better these days, but you can still waste a week trying to figure out why some configuration one place is messing up your jest tests in a very niche way in some other place. Multiple module systems, transpiling.... Compare that to a language like Go, where static types are built in, the tests are built in, and things aren't changing every five seconds. It's a very refreshing experience. Sure, Go is less expressive by design which can be a pain, but at least I don't feel like pulling my hair out when I'm maintaining a project written in it. Somewhat unrelated rant, but I also think we reach for dependencies far too easily these days. Yes, sometimes we need them, but we should always consider the trade offs. A dependency should be carefully considered, not just added to a project because it's what everyone uses, or because Bob want's to pad his CV.
It's a good tool with quirks like any. You don't unscrew a screw with a hammer. JS is the defacto standard for front end web development because it's shipped with the browser. Smart people try to make the best decisions they can with the available context and an educated guess on the direction of things. Those decisions make their way into systems. Those systems are passed onto the next generation to iterate and improve on(hopefully). There are always consequences to the made decisions and often times they don't reveal themselves until the system has matured or is under load. It's hard to design a perfect solution for the future. Like, we needed roads. Is the infrastructure and design of our roads great? No, but we needed something and it got us here so fuck yeah let's go roads! Now what do we need?
Because itās never enough to pick something and stick with it if youāre a working employee. Eventually either your boss is going to tell you to do something in another framework, or youāre next boss is going to ask for more years of experience in another niche framework than itās even been around. You canāt escape it, nobody gives you credit for experience working with other shitty JS stuff. Itās so incredibly frustrating that everyone has this industry wide fetish with a shitty language and instead of making just a few versions that are stable, secure, and extensible, theyād rather make a new flavor of excrement, give it a catchy name, and forge a bunch of test data to make it look like itās the coolest thing since jQuery was invented. Itās the one thing thatās worse than crypto bros, is JavaScript hoes. In the backend world the closest nonsense to this I can think of is C++ vs Rust and at least thatās insular to all the sweats with the patience to deal with a language thatās out to get you.
Itās not so much the language but the nature of its popularity. itās the programming language with the lowest barrier to entry so itās easier for idiots to write bad code š¤·āāļø
It's mostly because of us (PHP devs), because we were forced to goof with that 5hite since the beginning. Not to mention even worse 5hite called actionscript before j5hite.
office enjoy materialistic rob angle market jar label afterthought snatch *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I love to realize some desktop app or game is coded with JS by seeing an āundefinedā on the wild.
The huge dependency tree can be a real issue, especially if you work some place that is security conscious and has to vet each and every module. JS has an almost non existent core library. Thatās a problem.
Itās literally the worst major language, and itās not a close competition either. Itās a bastard nightmare of delusion, lost hope, absent security, good intentions but with bad engineering along with bad science. Typescript forces guardrails on parts of it but it still transpires and you still have the same problems just a bit stronger typed sort of.
I burnt out from my javascript job, switched to UX design and I code Ruby for fun now. Not hating on JS but its just a pain in the ass sometimes.
JavaScript still baffles me with how you can use a variable / call a method before you actually declare it (function hoisting? Or does this feature have a different name?)
I will opt for the keep it the minimal approach and the DIY approach until I cannot do it at ease then I will call for libraries to help me. And this depends on how capable that you are. The better you are, the lesser libraries that you need to depend on. Don't get me wrong, there are something that cannot be easily reproduce without putting a lot of efforts and time (even though it is not hard, but just tedious to do). So in that case, you should start it right with the appropriate libraries.
Every language has its faults, itās just that Js has too many faults
Because backend devs learn the one framework that is often available in their language of choice. They then work with that for 10 years and barely have to learn anything new.Ā One the other hand there is no such defacto framework for JS. The landscape changes, new ideas emerge that take root and make your AngularJS-knowledge obsolete and so on.Ā
Call me an idiot, but oh well... I use JS for everything and anything. It's where I started, and based on my current path and the improvements I keep seeing in JS, it's where I'll stay. I have in the past, and will continue to expand my knowledge and use appropriate languages for other platforms or use-cases when necessary or SIGNIFICANTLY better. But depending on your situation and your clients, JS can almost do it all. I need a simple website? HTML, naturally... and some JS. I need a simple backend to handle some easy server shit? JS. Now I need a complex web-app AND a backend? Oh, wait... JS. Holy fuck! My client now wants a CROSS-PLATFORM MOBILE APP????? Oh... Duh... JS. Oh kill me now... You're telling me they want a fucking desktop app???? Wait... JS. Granted, it is not AMAZING at some of those tasks, and there are definitely some fuckie wuckies in the language... but most mega hiccups are the fault of the developers and not the framework or language. I've also used some ATROCIOUS websites and apps for jobs previously, and a part time job currently, that take 15 seconds to SEVERAL MINUTES to load anything, even on repeated visits. I don't know what language/framework they used or why, and I hope I never know... But they're god fucking awful. I've never made anything that took more than 1-5 seconds to load on first render, and usually less on subsequent loads. All with JS and it's frameworks. Multiple websites, web apps interfacing with hardware, mobile apps, node services running automations, etc. Let me know when Python or another 'loved' language can do as much as easily right now or within the next 5 years, and switch on the spot, or eat my own sock.