Photo by m wrona on Unsplash
Seriously, give me your honest opinion and save any rant: what's the worst part about being a developer in the JS eco...
For further actions, you may consider blocking this person and/or reporting abuse
The fact that you need a complex build process (Webpack, Babel) to be able to utilize newer features/versions of the language ... Webpack and Babel are products of a genius, but what would be absolutely gold is if we wouldn't need them anymore.
(what other language requires you to learn the intricacies of a complex build tool like Webpack in order to use modern versions of the language? any other language you can mention - Python, Ruby, PHP, you just install the latest compiler/runtime and there you go)
I wouldn't say that you need those build tools to support newer features: I would rather say that you need those build tools to support older browsers and engines, what do you think?
Anyway, I'm with you: the amount of extremely complex tools around the ecosystem doesn't make it easy for newcomers. Also, by hiding such configurations and tools behind something like
react-scriptsis not good as well: too many times I've seen junior developers thinking that JS is able to do something that instead it's being done under the hood by some Webpack plugin.What are your advice? What would you change, practically speaking?
Well the problem (at least the Babel part) would go away once 95% users run browsers that natively support ES6. That way at least we'd know that our end users would really run our shiny ES6 code, instead of grand dad's old fashioned ES5 (the transpiled) version - to me this process always feels a bit comical, like we're collectively fooling ourselves. So in a matter of a few years we might at least not need Babel anymore!
But, the funny thing is that Typescript is becoming ever more popular, so we'd still need transpilation. But, what if the TS compiler would be able to do the whole thing - transpilation and bundling (including source maps, minification, and so on), and we wouldn't need Webpack anymore on top of that - now that might be a real step forward in terms of reduction of complexity.
Oh, and what if Web Assembly would take off - that would also be a solution, we'd simply choose our favorite programming language and use that, who needs JS lol.
I once complained that an experienced Java developer told me that Js is a disposable language: "any JS engine is a LLVM, I can write in it with whatever language I want". I couldn't understand him at the time, what a junior dev I was...
I'm with you though: I hope for TypeScript to improve its learning curve so that it can become the de facto standard for this field (but this is another story); I can't also wait for WebAssembly to become widespread enough in order to rewrite everything in Rust 😈
Exactly ... Web Assembly and Rust FTW ! and then TS as an intermediary thing or a stepping stone.
JS is just weird in that you're writing shiny new and slick ES6 or ES7, and then what gets actually run is often mundane old ES5 lol.
To be fair you're writing Rust, but what actually gets run is often mundane old assembly. It's all just layers of abstraction.
Yes but the difference is that ASM is fast, that's why we're compiling Rust (or C++ or whatever) down to ASM rather than interpreting Rust ... but ES5 isn't faster than ES6 (neither the other way around) - we gain no performance from the transpilation, that's why it always feels a bit more to me like a trick or like we're fooling ourselves a bit, just so that we're can get that warm fuzzy feeling by being able to write "let" or "const" instead of "var" (okay, I'm being cynical here). In other words, if I'm brutally honest it's more about programmer convenience than about performance (unless ES6 can be executed natively by the browser's JS engine).
Even these days public serving web sites should be practicing differential serving:
That way most browsers will be served a ES2017 bundle while legacy browsers have to deal with the larger ES5 bundle with its polyfills.
The root of the problem is that the web isn't a universal, monolithic platform but an infinite continuum of platforms. That is likely not going to change.
I wouldn't hold my breath.
WebAssembly:
And languages that require separate multi-megabyte run times aren't going to succeed outside of niche applications - JavaScript doesn't have to ship a separate runtime and Web APIs are all designed with JavaScript in mind. So really C/C++, Rust and perhaps AssemblyScript are the only real contenders for solutions with a broader market but I'd expect "productivity" to take a serious hit.
Given the Mobile Performance Inequality Gap, 2021 a JavaScript payload can be more effective in most cases - as long as it doesn't drag half of npm with it.
@leob code in ES5 will be slower than ES6 because it is more code to execute. I came across this. So to support 1% or 5% or whatever of legacy browsers you make speed and file size worse for everyone
Interesting!
Sorry corrected my typo. ES5 slower than, not in.
@peerreynders your comment is gold 🦄
Good news, they aren't needed anymore! Use Rollup and ESBuild and reduce your carbon footprint :)
Haha, heard about those, instant Webpack lite without the hassle ... but do we need to use ESBuild and Rollup? I understood that ESBuild is the speed king, can we dispense with Rollup?
esbuild compiles typescript and bundles javascript. You need rollup if you want to bundle anything else.
JavaScript.
The community has done an heroic job of building useful things on top of it, defying the "house built on sand" fate, but I still wish the language itself had not been rushed in ten days in the early days at Netscape.
So, basically the main problem of the JS ecosystem is JavaScript itself? What are the biggest struggles you face when working with it?
If you open "JavaScript the good parts" you will find two chapters that summarize that well
And the lack of types, and here thanks Microsoft for Typescript, I hope schools don't teach vanilla JavaScript anymore but skip to Typescript. I strongly dislike giving beginners bad habits of working without types.
Thanks for your reply, very helpful!
Long live TypeScript! 🛡️
I hate Typescript
I used to think the same but I realised I wasn’t hating TypeScript: I was hating its lack of good documentation, its unjustified complexity and its learning curve for newcomers.
The hatred decreased with the increase of my knowledge and now, it’s hard to admit it, I can’t use plain JS anymore even with the easiest pet project.
Nah, it's definitely TypeScript for me
Lol, got it 😅
Future readers might find more details useful 👌
Douglas Crockford, JavaScript - The Good Parts, 2008; p.2:
The bulk of "JavaScript the Good Parts" (before those appendices) was about dealing with JavaScript successfully on its own terms - which relied heavily on leaving behind any preconceived notions carried over from other programming languages.
On the surface the argument to start with a statically typed language for the sake of "safety" makes sense but people who have dedicated their career to computer science education have come to a different conclusion; The Structure and Interpretation of the Computer Science Curriculum:
I haven't noticed that TypeScript compels people to actually think in terms of types which is the important part of program design. Just like working with an OOP doesn't teach OO, working with types doesn't automatically foster thinking in types. Dynamic typing doesn't impede thinking in types.
I left my take in this comment earlier this year.
Ignorance/lack of knowledge.
Lots of people know jQuery, React, Vue, etc., but they don't know JavaScript itself. If you take away their library, they would be lost. They don't understand how React works and why it's useful. They don't know how and when to use different strategies and methods, because they lack the understanding of how those things work under the covers.
This is so sad yet so true
I wholeheartedly agree. I'm myself was and still is the person mentioned above. When I got into frontend I never emphasize on learning Javascript but j just use it as I learn jquery, react, node.
The constant fighting over everything and anything. Just let everyone use what they love and focus on building cool stuff.
Oh yes it gets heated. Everyone thinks there tool is best. In a Vue vs React post, the argument went that the one that was slower to get features was annoying while others said that this very slowness is a benefit because it gives security and stability
Let people choose Ubuntu vs Debian or nightly vs stable release. I wish people did not assume their needs and preferences are the same as others.
This is the best comment so far 🦄
Dependencies, and more specifically: Invisible dependencies.
For any medium sized project, node_modules has everything you needed, everything those packages needed and so on.
In the end, we’re depending on code we didn’t even know we’re using. What’s worse, these 3rd party dependencies can conflict with your own and can be a real horror show to upgrade and keep up to date.
There are lot´s of complains about the use of "this", which give people some headaches. For me, the worst thing about "this" is the use in classes. As any class variable and any class function is bound to "this", code inside a class is peppered with hundreds of "this".
On the other hand, function definitions inside a class do not need the "function" identifier. Writing longer class definitions you often get los to know, what precise class you are working on. I just started to add the class-name as a comment:
It would be far more handy to have any class method clearly be part of the class like
This yould also allow to shift some code into a class without the need to rewrite anything.
In my view
this, prototypal inheritance, constructors, and most of "classical" OO in Javascript is simply better avoided when designing new JS code. I much prefer a more FP (functional programming) style approach. Use objects, but just put data in those objects, then write functions that take in those objects as arguments and do something with them.I know that almost every introduction about Javascript starts talking about
thisand about prototypal inheritance, but IMO it's a load of historical baggage that's confusing and almost always unnecessary. Just look at contemporary React (with function based components and with hooks, but without classes) and you can see that we don't really need classical OO, "this" and prototypal inheritance.(use functional components and hooks in React and you'll almost never have to write "this")
Plain objects and functions get you there 90% of the time, prototypal inheritance is historical baggage. Javascript (especially ES6 with arrow functions, destructuring and so on) is a cool language, simply don't use its legacy features, that's all just cruft.
Yeah
thisworks differently in function and arrow function (not allowed in latter I think).I found a video which explained
thisand there are some many cases where it behaves weird.And then you assign
var _this = thisto get some context frozen...Don't expect JavaScript's 'this' to be a 'this' that you are already familiar with.
It's its own thing.
xkcd
People who complain about the JS ecosystem...
Sure there are some flaws; but I'd love to hear what 'ecosystem' doesn't have any.
I complain more about Python though.
To me JavaScript is not so bad, although there are some major flaws. I will type later.
[1, 2] + [3, 4]. I sometimes did this, coming from Python. And, left-side type coercion?Object.create()?forkor equivalent toiframe.There is TypeScript, but it also has a fair share of love-hate as well.
JavaScript needs an official compiler, projects like webpack, typescript, rollup, babel should come together and create under ECMA an official compiler, goal should be compile to targets like old browsers/node versions and directly to wasm. The ultimate goal should be no difference between browser and Node + rebranding of JS call it "Node" maybe?
Everything from start to end. The tooling is a nightmare for those of us that wasn't into front-end development when Angular, React, etc, came to light. Nowadays, every single goddamn tutorial takes for granted that you already know how NPM works, it just goes to 'hey, install this, put this code there, bam, your todo app is done!' without actually properly explaining whats going on. It took me 6 months to understand how importing JS packages works, and why I don't need any kind of autoloader of whatever, like pretty much every PHP framework does.
Promise, async and await are also another nightmare that is so bad explained that only today I finallly got a small grasp on how they work (thanks to this article dev.to/zackdotcomputer/i-promise-y...), but I'm still confused about their usage and everywhere I look, things got more complex instead of breaking down each concept first before you start doing any actual code.
There are still lots of stuff that works by black magic hidden under a stone set aside a tree in the middle of the nordic forest on Kepler-10c. It just works, but how?
And please don't get me started on node_modules. That is ridiculous, an atrocity, and I wish that whoever came up with this got fired and was never allowed to touch, get close, stand nearby or even talk about any computer, ever again.
This is actually one of the things Ryan Dahl, creator of Node.js, strongly regrets about Node.js.
youtube.com/watch?v=M3BM9TB-8yA
It's also one of the reasons why he built Deno.
Really? Interesting, even the Node creator dislikes node_modules! I'm watching his talk now, thanks for that!
Hi there, pigoz!
... I think it's the usual stuff that affects big, large, and in this case immense communities: latent toxicity from some members, who don't lose time to spew vitriolic remarks and uncostructive comments towards this or that library/framework/specification/tool. We really, really don't need that 😫
As the language per se, it's mainly fine. I wish we had, you know, types but it seems that TC39 is fine with the current situation of transpiling everything. Which is strange, since they gave us so many things to let us use module directly. In practice, we still create big bundles...
Over-complexity, over-engineering, too much tooling, too much emphasis on supposed 'convenience' for the developer rather than the efficiency or appropriateness of the solution(s)
Then you've got the wrong developers. I pay my devs a lot. I want them to have every convenience precisely so they can concentrate on writing the best solution. Their time should be spent rapidly writing code that does a thing. We can create amazing application software very quickly using Javascript and React, with crafted user interfaces and high runtime performance. In this way we serve our customers well and give them excellent value for money.
What do you mean exactly? Could you provide some examples? Even some links and repos are welcome 💪
That paper was from 2004. In the meantime they acknowledge that "all those parentheses" can be challenging for some students. That is why Pyret was developed.
However:
So in terms of education static type checking is still being delayed.
See also Programming and Programming Languages
They still deal with types (other than
string) - they just don't use static typing from day one.Well that explains it then.
Most of the "coping techniques" outlined in "JavaScript the Good Parts" are about leveraging JavaScript's Scheme-y bits to maximum effect.
package.jsonandrequire().PNPM now has support for
package.yamlbut half of the npm modules insist on parsing apackage.json, preferably with a JSON parser from the early 2000s that doesn't support JSON-with-comments or trailing commas. Just give us animport.meta.moduleInfo(packageName)to get the package information already.require()is completely broken but at least it's almost dead now.And yes, having to deal with JSON in 2021 keeps me up at night.
If I'm allowed to pick a minor thing as a second answer...
I don't like the naming with an extension.
Like Node.js
It is not the name of a file.
react.js, vue.js, next.js... is not the name of a file. Well maybe sometimes but usually it is vue-1.2.3-esm.js or whatever as a long name
So why add extension?
We don't call it pandas.py, requests.py or grails.jar or rails.rb in other languages. Yes Python packages have Py names sometimes like Pygame or Numpy but that is fun and artistic and doesn't go to extension level.
And Node and Node.js and NodeJS are all (sort of) correct spellings.
And some say Node dot JS aloud. It sounded so verbose on NextConf for the presenters to say Next dot JS all the time when it is clear from the context and "Next" would be fine.
Typing "next.js" is the common way for packages while "DocsifyJS" is the preferred way of some packages like in Docsify docs.
What bothers me is JavaScript (aka EMScript aka ECMAScript) has no truth in a single version.
In Python, Java, etc. you and I can say that we have version 3.4.5 installed on our machine and we know it will give identical results. (Maybe some architecture differences or OS implementation differences but that is for any language)
While JS is standards or specifications, right? So when a new feature comes out in say ES6, then every browser and mobile browser has to go and implement that feature. And some diverge and never add a feature that the others do or blaze a path of a feature that no one else adds to their browser.
I mean it's an issue with CSS too I guess.
Plus there is the difference of what ES6 / ES2015 for example does in my browser vs in Node 12 or whatever and Deno 0.x
Too many frameworks, tools do the same thing. Everyone suggests that they are the best, even though they didn't say it. I prefer to use w3c standard and language built-in features rather than the frameworks and tools.
LOL "WebDevs actively work to prevent their usage" ... conspiracy thinking much?
I've worked plenty with SOAP but never liked it, TBH hated it, like pretty much almost everyone else I knew. You know, those corporate and proprietary "standards" tend to be over complicated, over engineered, feel like "designed by committee" and are terrible to work with.
The open web standards though are simple, easy to work with, and are sufficient in 95% of the common scenarios, that's why people like them. In case you need more sophisticated, you step up to GraphQL.
Microsoft got better yes, mainly due to their leadership, Satya Nadella is lightyears ahead of what Steve Ballmer ever was, it's like the evolution from the chimpanzee to Homo sapiens. And they (Microsoft) finally embrace open standards and aren't actively trying to sabotage them (remember IE6/7/8, ActiveX, JScript?)
MS also abandoned Silverlight, and embraced HTML5, JS, CSS ... so ironically your "heroes" have started to bet on and embrace the platform that you dislike.
Seriously though, I fully admit that the web was conceived as a platform for content delivery - it was never designed or meant to be an application development platform - a lot of it feels bolted on, even though arguably a lot of effort has been put in to improve it as an app dev platform (of course it's not true that JS hasn't made any progress).
That's why I made the comparison with mobile ecosystems (Android and iOS) with their native client apps, and wondered why a similar development hasn't taken off on the desktop - web for content delivery, native apps (connecting to backends via web technologies) for apps.
Oh and by the way - if you despise Javascript as a language (and even Typescript, conceived by MS) then there are plenty alternatives (all of which "compile" to JS, so that you don't have to write that): Elm, Dart, ReasonML (the last one is really interesting and I'd expected it to take off, but it hasn't) and others ... so I'd say that you can hardly use the weaknesses of JS as an argument against "the web".
I was about to start arguing again lol but I do have to admit you have a point here. Look at the mobile ecosystems (Android and iOS), where there's a clear market for native client apps which aren't web based, but which use web tech (HTTP, JSON and so on) to communicate with the backend.
So yeah I'd say use HTTP and all of the web standards on the backend (and in MOST cases do NOT Javascript or node.js there, use a proper language) but for the client I'd argue we should have more choice than just HTML/JS/CSS. Something like the iOS or Android app model but then for the desktop.
P.S. on a tangential note, you're clearly a Microsoft fan but I'll never forgive them their monopolistic practices of the 90s, which included threatening PC manufacturers if they'd dare offer Linux on their hardware, or anything non-MS. I have to say they've changed a lot and they sing a different tune now, but the days of Steve Ballmer were horrible (and so was Windows back then).
I agree that node.js isn't ideal, but hey, to equate node.js with "web dev" is a bit misleading isn't it? There are dozens of platforms for doing web development (backend).
Also: "95% of WEB devs, not devs" => okay, but the large majority of devs are now "web devs", maybe not 95% but well, probably like 75% - so still "the majority of devs"
And: "Most non-web-devs hate web dev with a passion" => that's a bold (and subjective) claim, can you back it up with facts? I rather think most non-web-devs are neutral, or even mildly positive, and are MAYBE even using it themselves occasionally ;)
And finally: "for the reasons I listed" => I haven't seen any clear reasons mentioned anywhere, have I missed them?
You can program in a backend language with strong typing and still be doing web dev, I've done Java for years and considered myself a web dev (or at least a "web dev" among wearing a number of other hats) most of that time, so I don't see the artificial divide you're trying to put up.
Right, I've read similar proposals before to keep the internet (TCP/IP), but to replace the application platform / content delivery platform (the Web) that's running on top of it - i.e. to replace the Web with a "better" platform ... what do you think realistically speaking, does this even remotely stand a chance? That ship has sailed a long time ago, the web is what we've got, for better or for worse (and I think it has a lot of good things to offer).
"The trio of HTML, CSS and JavaScript epitomize horrible technology", that's rather stark, why do you think so? Sounds like you're not a fan of the web platform, what's the alternative then, we need to code all our apps with Silverlight or what?
Java for sure had a sandbox, the security model is documented extensively, based on (among others) the infamous "class loaders" (I was a Java dev in the past, so then you get to learn about all that obscure shit).
But for some reason their sandbox was leaky, apparently. Maybe they just had more competent programmers in the Silverlight team?
The V8 JavaScript runtime is the real root of Google's power on the web, I wasn't aware of that! I believe you, although I can't really deduce why that is so.
Right ...
On a tangential note, I always find it so comical that, way back when, Oracle paid billions to acquire Sun Microsystems, not because of their great high tech (SPARC chips and Solaris OS), but because "Java is installed on a billion computers" (that was the silly Java plugin which almost nobody used, and which everyone hated) ... they really believed Sun's marketing mumbo jumbo ;)
Years later Oracle killed SPARC, then Solaris, then Java EE, and then they wrote off the last remaining bits of their failed astronomical investment ... utter incompetence of the "suits" in higher management.
P.S. I'm not a Java hater, it's a great language for the backend and it's utilized heavily for big enterprise systems, it's sort of the new COBOL, but on the frontend it was always a bit of a joke, and the biggest joke of all were Java Applets, what an epic failure that was ;)
The worst part is that the language is just too successful, so that folks who would much rather could happily dwell on PHP, Java, Cobol or whatever their particular pick of poison actually is, end up in its ecosystem and whine about it.
At least JS didn't need eight god-damned major versions to get first-class functions right. Brendan Eich could actually pull that off in ten days.
The worst thing about the Javascript ecosystem is Typescript.
It was painful watching an experienced dev waste hours tinkering with code, not to craft software features, but to get rid of complaints from Typescript about mismatched types. Then watching as they sit looking aghast at their runtime type errors, in disbelief because transpile-time type safety should have saved them. And the sheer volume of code written... I'd rather they spent the time thinking about what happens at runtime, and thinking about writing well-composed, maintainable code that's self-documenting... Not jumping through syntactical or semantic hoops trying to satisfy some tyrannical software tool with its uphelpful, nonsensical error messages written by people who really shouldn't have been put in a position where they have to write error messages to help other devs.
As I've said elsewhere, my devs are high worth individuals. I pay them a lot. I want high productivity, so the customer's money is spent on crafting the features of their software solutions, not tinkering with the tooling. We develop things once and reuse massively. Typescript would just get in the way of all this. The way we do what we do is to employ properly educated devs who know how to use Javascript expertly to create exquisite business application software, and keep everyone up to date with current best practises and communicating well. Appropriate tools like IDE, linters and formatters look out for us and watch our backs. Code reviews are opportunities to learn and teach. In this way Javascript is made friend, not enemy.
Of course I'll get flamed for this by the True Believers, but I don't care. I do what I do backed up by decades of experience with commercial success. You should carrying on doing what you do and go in peace.
I can sort of understand why they're blocking that - bad experience in the past with Flash and Java and other browser plugins (security issues) ... they don't ever want browser plugins anymore (and to be honest, not just them, is there anyone who's really enthusiastic about the idea of bringing back browser plugins)?
The language itself, more specifically, a super weak standard lib. Everyone installs an NPM package for everything. It’s a security nightmare.
Compare to, for example, the excellent standard lib of C#.
I'm just starting from working with PHP and the worst part was de npm enviroment. There are SO MANY copies of the same packages and the npm UX is very improvable. Maybe is unexperience talking but it seems like the project building part is a mess with a long way to improve. What are the experienced devs take on this?
I've been working with JS for quite a long time but I feel the same problem: the package management system has room for improvement.
The main issue, though, is not the package manager itself but the easiness for anybody to publish their own fork of the same package that is slightly different and solves a very specific problem that the author is facing. Don't you feel the same? I'm wondering if the developers in the JS community have ever heard of pull requests on Open Source Software.
The fact that most of the time classes and plain objects are not tree-shaked nor minified really irk me. Hopefully tscc/tsickle can solve this problem but still it's slow solution and require JVM.
And what Deno said in their docs is true. There is a need a new kind of Typescript compiler that fully use the type annotation to reduce the bundle size.
var
Could you argue more your opinion? Otherwise it might feel pointless to other readers 📖
The hoisting of var instead of being block scoped like let and const
var, let, and const – Why to avoid var 😷 and how to put the other two to good use? - Javascript
Pratap Sharma ・ Jun 12 ・ 6 min read
None. npm is the ecosystem. And Deno fixes it.
As deno gains support, parsel, Babel, and snowpack will get rewritten into rust and tied into deno native speed improvements. Deno sis written in rust and can connect to rust. Deno can access gpu for speed up. It can run web assembly. And so can the browser.
Cool!
P.S. I tried to post a comment on your article but strangely couldn't, persistent server error ... so let me post it here instead:
Interesting! but should we call Google "evil" for pursuing this strategy?
I don't think so ... every company tries to optimize their profits, it's natural and it ain't evil by itself - but the outcome of what Google is doing is to further the open Web standards (based on HTML, CSS, JS) at the detriment of the proprietary "plugins" like Flash, Java and Silverlight ...
That's progress in my book, in the end the open Web as an application platform (even though not perfect, but then what is ...) means we all win in the end.
Var.
Well, you're pretty outspoken to put it mildly, and with an opinion that I think is at odds with what 95% of devs are thinking ... interesting discussion, to be continued!
Daily one new JS frameworks born. Job opportunity is also based on the current trending JS frameworks. That's not good for the community.
Hype Driven Development
npm ecosystem.
The ridiculous number of packages npm installs. I have NO IDEA what could be in there, besides my desired package. Vulnerabilities? Ok, glad to know but that side wastes time resolving.
No idea really, but what do consumers use? web browsers, and mobile apps (Android and iOS) ... I don't see how that's going to change. Standards are good in my opinion, even when they're not perfect.
Having a new framework every 5 mins.