23 ms·

Today’s JavaScript, from an outsider’s perspective (2020)

341 points by ddtaylor 4y ago

RedNifre 4y ago
Isn't it like this with most languages? The only exceptions I can think of are Io and Go (I heard that Rust also works, but I haven't tried that one).
- lbriner 4y ago
  Yes it is to a lesser or greater degree. I guess a lot of languages struggle with the balance between Communism and Dictatorship. If you allow genuine communism, people don't agree on things, stuff gets built to different levels of quality, some of it maintained better than others etc. You end up with the problems we see in lots of package management. On the other hand, if you have an individual or team who dictates how stuff gets developed, what is an acceptable level of functionality, getting rid of stuff that is not maintained etc. then it is possible to build a much more reliable package management system but perhaps get less people getting involved because they can't just offer what they feel like but only what is accepted! I think some languages suffer less because they really invested in the standard library including a tonne of stuff avoiding the need for external packages. .Net, Go and Python are like this I believe.
mbrodersen 4y ago
Here is what I did when I had to create a fairly complicated web application with no prior experience in web development (but 20+ years of developer experience in other environments): I started by learning the basics: HTML, CSS and JavaScript. Without relying on any build systems or packages. And only then adding a build step or package if it really absolutely was worth it compared with writing a bit of extra code myself. It worked like a charm. I completed the project in a few months with very few dependencies. And the build “system” was simple. Which should be kinda obvious when you think about it: Every build system or package you rely on will become a liability and a major pain point down the road. Guaranteed. So the less you rely on external tools/packages, the more stable your code will be. And the more you understand the basics, the more you are able to fix problems with code you didn’t write yourself. The downside of course is that you have to invest more heavily in the basics (HTML,CSS,JS) but that is a good thing. The time you spend becoming an expert in fashionable build tool X or package Y is a waste of time. Something else will be more fashionable tomorrow so your hard earned expertise is wasted. It is a bad investment compared with deeply understanding the foundation (HTML,CSS,JS).
iamsaitam 4y ago
Is it that time of the month to shit on Javascript? oh yeah.. /s
spiderfarmer 4y ago
I've been burned by VSCode's collapsing folders more than once.
- deleted 4y ago
  [deleted]
goldenkey 4y ago
All he had to do was run `node index.mjs` or `npm run start` to have his index recognized as a module. Node DOES not read package.json, npm (node package manager) does. Node is not the package manager, so of course changes to package.json won't affect running `node index.js` However, node recognizes the file extension mjs as a module and will execute it as such. So renaming the extension of the script would work. Alternatively, if you wish to use the package.json info to launch node, use the package manager through `npm run start` This isn't rocket science and honestly makes perfect sense. Package management is basic stuff and Node really doesn't do it any different than Ruby gems or Pip requirements, etc..I think you and your buddy need to have a talk about the assumptions you're making with regard to the actual executable versus the package manager and re- evaluate your understanding from first principles.
- MaxLeiter 4y ago
  It only makes sense because you understand the decisions behind it. Try teaching JS to someone with little experience — they don’t care that the browser wants one kind of module and Node wants another. They don’t know what a module is, they just want their code to run
  - goldenkey 4y ago
    The article is making the whole thing sound arcane and unreasonable when the distinction between package managers and runtimes has been the case for decades. Expecting package.json (a package manager file) to alter the behavior of node (the executable runtime) shows a lack of even first principle knowledge of computer languages, runtimes, or package managers. I don't feel bad in the slightest, because math feels like shit too when you first get into it. But the reasons are mostly sound, so complaints are mostly just whining.
    - chii 4y ago
      > shows a lack of even first principle knowledge of computer languages, runtimes, or package managers. it's more that the author has the expectation that a computer scientist (well versed in computer science) should be able to immediately discern the intricacies of software construction and engineering. The complexities of a software system is distinct and different from that of computer science. It's like saying that a physicist would be able to do the job of a construction civil engineer, because they know the physical theories of forces.
tarcon 4y ago
Chances are, the only thing interesting from that package is a single source file, which you could just copy over to your project.
- sullyj3 4y ago
  I feel like the point of the article isn't so much "how do I solve this specific issue" as "this is the general state of JS packaging", and the solution you present doesn't work in the general case of larger, less trivial dependencies
  - chii 4y ago
    But the thing is, the general problem of packaging is a complicated system, and the current solution developed are there to solve those complications (which adds more complications unfortunately). However, the article wasn't about this general problem of package management. It's a problem of somebody wanting to test out some code, and went down the rabbit hole without understanding what they're doing (not a slight at them - it's hard to know what to do). Ideally, you don't go down that route, because testing out some code doesn't require solving the packaging problem.
wrnr 4y ago
Deno uses ES modules and has a build in TypeScript compiler and solves these issues. Just be careful when using different versions of different packages and always use the same version of a service like esm.sh that translates CommonJS modules to ES modules, it has a versioned API so esm.sh/v70/lodash@1.2 != esm.sh/v71/lodash@1.2. I hit my head on this problem for a couple of days.
- cutler 4y ago
  But Deno is incompatible with npm, no? Deal breaker.
  - mattlondon 4y ago
    https://deno.land/manual/node#interoperating-with-node-and-npm https://deno.land/manual/node#interoperating-with-node-and-n...
  - wrnr 4y ago
    No it is not, that it what the esm.sh is for. It transforms a npm package into a ES module. Just make sure that when you have the dependencies A@2 and B@1 where B@1 depends on A@1 (in package.json) then you end up with 3 dependencies A@1, A@2 and B2 which results in bugs if your code expect the versions of A to match. Similar for using the same version of A but a different version of the api like esh.sh/v10/A@1 and esh.sh/v11/B@1 this will result in esh.sh/v10/A@1, esh.sh/v11/A@1 and esh.sh/v11/B@2.
  - jhgb 4y ago
    Why does it matter? Deno should not need NPM in any capacity, or does it?
    - cutler 4y ago
      Because npm is the biggest repo in the history of computing and Deno makes it redundant. The people at Jetbrains knew about backwards compatibility when they created Kotlin. It's too late to just ditch npm.
michaelsalim 4y ago
Module resolution is quite a mess in JS at the moment. With the steady move to ESM, hopefully things will get better soon. In this transition period, it's painful. Even for those that deal with JS everyday, most don't actually understand the intricacies of CommonJS & ESM.
- BluSyn 4y ago
  I use JS/TS every day. I tried to understand the intricacies in module/import issues. Just reading about it gave me a headache, and tempted me to just rewrite my entire project in Rust. I'm still tempted some days. It's beyond painful. It's infuriating.
  - afiori 4y ago
    It is not going to convince you that ESM modules are well designed... but this post explain a lot of the intricacies https://jakearchibald.com/2021/export-default-thing-vs-thing-as-default/ https://jakearchibald.com/2021/export-default-thing-vs-thing...
    - b0afc375b5 4y ago
      I read halfway through before my brain shutoff. I keep asking myself if all this complexity is necessary.
      - afiori 4y ago
        It is a shame because the whole "import namespaces from URLs" is a nice idea. In my opinion they should have dropped the whole "live reference imports" which is a completely new concept to the language. Personally I would have liked inline modules definitions à la Rust.
- Moru 4y ago
  That's funny, every time I think that I should invest a bit of time to actually learn JS, someone comes along and says "a mess in JS at the moment". I can hack something to a working state but I never feel I have a full grasp of what's happening... But I grew up on assembler 35+ years ago so all this magic is unnatural. :-)
laxis96 4y ago
I can totally relate to this, even after working professionally with Angular for 3+ years and generally with JavaScript for way more than that. I recently set up a quick JS project from scratch that needed a few different npm packages and ended up spending more time understanding the >three< different ways I had to use to import the different packages (because the returned errors were utterly useless), than actually writing the business logic...
deleted 4y ago
[deleted]
pjmlp 4y ago
And this is why on personal projects I only care about JavaScript on the browser, without any npm ecosystem, classical SSR using a scripts folder.
etamponi 4y ago
I can feel the author, in particular about the mess that is node_modules resolutions (and the fact that it sounds like 99% of "tutorials" - or even package READMEs - about Node seem to be written by someone that didn't really think things through). Anyway: I think the underlying problem is that it has been hidden that Node is NOT JavaScript. It uses (some) of the JavaScript syntax, but it doesn't use its standard library, and its not guaranteed that a Node package will also run on the browser. Deno tries to fix it. But I think everyone should ask themselves: is it really worth it? The backend and the browsers are two different environments with different needs. Why making novices think that the two are interchangeable, just to disappoint them a few moments later?
- qsort 4y ago
  I think the reason it's worth it (to the extent that it is) is not that it's good for novices, it's that it can leverage V8 and libuv. If your claim is "you're on the backend, you have saner options" then I would agree, but this isn't really about beginners.
  - etamponi 4y ago
    Don't get me wrong: the reason why both Node and Deno (and probably JavaScript itself!) are so successful is that v8 is a ridiculously good runtime, and libuv is great. Deno did something smart: all the non-web-compatible APIs are under the Deno package. That's great, and almost fixes the issue I am highlighting. If Node could do the same, and provide a way to find at "compile time" (that is, statically), if a package is web-compatible or not, that would be very good. My issue has probably more to do with npm than with Node itself.
- MCArth 4y ago
  Because for lots of code, they are interchangeable, and being able to write your code that runs on both the server and client can be very useful. Not to mention that splitting the ecosystem down the middle would result in less high quality modules that can fit your specific usecase!
- norman784 4y ago
bryanrasmussen 4y ago
I always go into these things hoping the outsider will be an Amish farmer or professional welder, but it always turns out to be just another programmer.
- _ZeD_ 4y ago
  in what scenario an amish farmer, a professional welder, or, well, anything but a programmer, would know anything about this "javascript" thing?
  - donthellbanme 4y ago
    You would be suprized. I know a few people whom keep up on tech trends, even though it has nothing to do with their job. I follow programming trends, basically through HN, and self study. (I have wasted a lot of money on programming/Computing books.), and I'm basically a Jack of all Trades in life. I'm a mechanic certain years. I'm a contractor certain years. I'm a Electrician when I am very low on money. I'm a Watchmaker whenever someone asks me what I do. (I hate that last sociatial question. When did it become copacetic to ask for job status, and finances. I guess it came with the Selfie. (I didn't use a question mark on purpose. Too disenfranchised today to care.) I do miss the days before relying on bloated JS libraries. I miss the LAMP days for my personal websites. There was a free server I used to use, but forget it's name. It allowed full domain names without their branding. Like mysite.com, instead of mysite.com.branding. I know Git, Google, and Amazon offer a free page, but I just don't like learning their way of putting up a site. As you can by my verbage, I'm not a professional. But for some reason I try to stay current on certain aspects of this industry.
    - 2muchcoffeeman 4y ago
      As a programmer for my day job, I thought it was weird as well. But then I realised I am interesting in things other people do as a job: cooking, CAD, gardening, wood work, music. So people must be interested in programming as a past time.
    - corrral 4y ago
BiteCode_dev 4y ago
And this is why I gave a try to VueJS in the first place. It can be deployed with npm, or a simple script tag. It still does today, making prototypes easy to write, training very simple, and yet, it plays well with the more complex ecosystem. Now of course, VueJS has Vite, which makes all the complexity of Webpack goes away, removes the slowness of compilation and has sane defaults. Still, npm remains. I'm now used to it, but I understand that if you come from another language, it's not attractive. It's funny to me that most people consider JS packaging better than Python packaging. Both are troublesome, just for different reasons. E.G: using different versions of node is much harder, espacially on windows, or for the same project, than different versions of python. And installing compiled extensions is a way better experience in Python than in any other high level language. On the other hand, node_module is easier to use than the average venv.
- zelphirkalt 4y ago
  > And this is why I gave a try to VueJS in the first place. It can be deployed with npm, or a simple script tag. This is exactly, what I noticed positively about VueJS and advertised as a good feature for integrating this specific "web component" framework into a project. You can add it as simply as one used to add jQuery to any project. However, others thought of including script tag as "not proper" (even though I told them, that in the end it would all be a script tag anyway ...) and it was decided to use another framework, which is way more complicated to integrate in any statically rendered / server side rendered and template based website. Simply putting VueJS in a script tag is not a problem. One can cache it easily and one can use noscript tags at places in any page templates. All is fine.
mellosouls 4y ago
Basically: How it feels to learn JavaScript in 2016 https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f https://hackernoon.com/how-it-feels-to-learn-javascript-in-2... Original old-man-railing-at-modern-tech parody: https://circleci.com/blog/its-the-future/ https://circleci.com/blog/its-the-future/
- moss2 4y ago
  That old-man-railing-at-modern-tech parody was a great read
  - masswerk 4y ago
    Now this inspired me to the great idea that we all should move to microservices in the browser, running as concurrent background tasks along a managed message bus, as soon as possible… (Functional programming and modules are dead, browser microservices are the future! We may even launch our web app in a fleet of redundant windows/tabs, by the this greatly improving stability!) ;-)
    - jeroenhd 4y ago
      Write a system of service workers intercepting each other's HTTP requests and I think you can do it!
      - masswerk 4y ago
        Also, include WebRTC for distributed remote partitions! (For redundant peer to peer backup, call your Ma and ask her to join your session as a distributed backup peer. If your computer dies, she'll still have the data. Now she really shouldn't close that window until your gear comes back from service…)
- brycewray 4y ago
  Both of those inspired me to write what amounts to an homage, specifically about web development: https://www.brycewray.com/posts/2021/01/easy-peasy/ https://www.brycewray.com/posts/2021/01/easy-peasy/ . . . and, as I note in the opening: > I do **not** pretend this is in the originals’ amazing league.
gernb 4y ago
sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error. repeat the same with xcode and any project in c, c++, objc, swift okay how about ruby? oh I have old ruby , hmmm , try to install new ruby, seems to run, but it can't find certain gems or something. oh and this other ruby thing I was using is now broken ? why do I have to install this stuff globally? You don't but there are several magic spells you must execute and runes you must set in the rigtt places. Oh ... I think I got that setup but it getting this new error. .... I'm sypathetic it sucks but it's not unique to js
- Madmallard 4y ago
  Stacks being nonfunctional on install is a failure not progress
- synthmeat 4y ago
  Go is yet to prove its stability over timespans similar to those languages you've mentioned, but it doesn't have many of noted (and similar) quirks.
  - rat9988 4y ago
    My old go code doesn't compile anymore with the newer compiler versions
    - synthmeat 4y ago
      What was it that broke it? Usage of unsafe? Security and bug fixes in the compiler/tooling? Just interested.
      - rat9988 4y ago
        I didn't try for a long time I have a hard time remembering. I believe it had something to do about how it handles dependencies.
mattlondon 4y ago
I think the problem was using Node in the first place - most the article is fighting node + NPM nonsense. I personally try to avoid Node + NPM where I can these days, and use Deno for backend stuff since it is much more sane IMO. I've never heard of people putting typescript into a .js file - is that some node thing? Modules in the browser for vanilla JS is a delight and Just Works though. I've started doing it recently and it is lovely - no need for a bundler/compile step. There are concerns about load performance if there ends up being many modules, but you can do on-demand module loading via vanilla javascript (import returns a promise IIRC) for when that happens.
- MCArth 4y ago
  I completely disagree with this as someone who's spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem I'm not sure what the solution is, but I no longer use any packages which export only an es module.
  - mattlondon 4y ago
    I guess the first thought that springs to my mind is why should ECMAscript care about what node does? Standard vanilla modules just seem to work totally fine without any issues (in standard vanilla javascript environments) while being totally intuitive, and is basically identical to how typescript does it too... and it is even very similar to how Deno does things. It seems to me that nopde + npm here is - as usual - a bit of a cesspit. It is this sort of thing that keeps driving me away from node + npm. There is just too much hassle and gotchyas and concerns when using it these days. By comparison Deno is a joy to use, as is pure vanilla js in the browser without a build step.
    - whostolemyhat 4y ago
      > why should ECMAscript care about what node does? Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day?
nathias 4y ago
looks like a Microsoft issue ...
MCArth 4y ago
I've spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem I'm not sure what the solution is, but I no longer use any packages which export only an es module.
- an1sotropy 4y ago
  Can you explain more what is half-baked about ES6 modules? To me the logic and syntax of how imports [1] and exports [2] are organized seems clean, but maybe I'm missing something? Sure the interoperability between things that do and do not (pure ES6) require a build/bundle/whatever, and between JavaScript and TypeScript may remain an engineering challenge, but that's not for the ES6 modules spec to solve, right? [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - MCArth 4y ago
    I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. Backwards compatibility is a serious concern. It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.
quickthrower2 4y ago
I think they (as in author and the friend) need some expectation adjustments about how easy it will be to get some random code package published for free on the web to work, regardless of the programming language. In other news I am quite annoyed by the confusing range of hardware and how difficult they make it to bolt a fencepost to a wall: There are masonry bits, high speed steel, different sizes, different anchors. And then getting the right length screws. I seem to do it all right but the post keeps slipping out. Eventually there will be dropbox-like disruption of both node.js and diy hardware, but until then just do the normal 10-20 hours of mandatory training (like udemy courses) to get the basics down.
- IshKebab 4y ago
  I disagree. I've never had issues of the magnitude of JS's mess with random free code written in Go or Rust. I think the reasons for it in JS's case are kind of reasonable though. Just annoying that it's taking so long to sort out.
  - Gigachad 4y ago
    I have had plenty of issues trying to get packages from Rust working. Half of them depend on external libraries and its up to you to work out what package for your distro satisfies the compile. And then if its not a binary tool, you have to work out how to use it in your code, which if you are a Rust outsider, is very difficult. I don't blame any of this on Rust. You can be expected to be proficient in the tools as these are not end user products designed for someone with no training.
    - IshKebab 4y ago
      > Half of them depend on external libraries Bit of an exaggeration. Some do. I would say more than with Go, but waaaay less than half. Maybe like 1/10th. OpenSSL is the most annoying. > And then if its not a binary tool, you have to work out how to use it in your code, which if you are a Rust outsider, is very difficult. I don't understand this. Of course you have to work out how to use a third party library in your code. Do libraries in other languages magically integrate themselves?
alexb_ 4y ago
This thread is also a good read: https://twitter.com/Aella_Girl/status/1522633160483385345 https://twitter.com/Aella_Girl/status/1522633160483385345 Shows that a lot of people, ESPECIALLY programmers, vastly overestimate the competence of the average person when it comes to whatever they are an expert at. You may think that this person is silly - but that is tainted by your past experience of already knowing it warping what you think the baseline average knowledge level is at. And this issue would have never been solved for normal people - the only reason this barrier was ever breached for this person was due to their large twitter following. Most people don't have that luxury. So, if you think it's hard for someone who is already a programmer - think about how needlessly complicated the entire ecosystem and everything surrounding it is for the average person. It's no wonder many people basically view anything past the surface level of computers as dark magic, and we call people good with these magical devices "wizards".
- alexb_ 4y ago
  Was going to edit this in but it quickly turned into a related rant about the state of things: if you don't want that, scroll past. The real problem is that there's no more room for the technological "middle class". We've gotten to the point where you cannot be SLIGHTLY interested in computers, want to make a quick app for yourself, or make something small to share with the world. You either have to have no interest at all (and live in blissful ignorance) or be so into this type of stuff that you might as well just make it a career. In between these two extremes lies a valley of frustration and needless complexity, where everything is always breaking and changing because we found out what was used 2 years ago is actually bad but THIS TIME IS DIFFERENT! because now we found a solution that is totally going to work forever this time. It's exhausting to even think about. Many people got their start programming with something like messing with simple Visual Basic stuff. I, and I'm sure many others who are reading this, started with a TI-83 and a desire to cheat on my math quiz. I know that I'm going a little off the rails here, and this has become more of a rant than anything meaningful, but I really, really hate how there's quickly becoming no space for that sort of thing - nowhere for people formerly uninterested in technology and programming to get their feet wet, nowhere to make a quick application to accomplish a small task, etc..
kovalevski 4y ago
it'd interesting to see the same experience with deno
sillycube 4y ago
That's why I stick with cdn. No build process. Slower in run time but easier to get started
samwillis 4y ago
JS tooling has come a long way in the last couple of years, Vite for example is so much better than everything that came before. Esbuild is incredible and clearly the future of all JS build tools. The trouble is that to people who are only just outside JS ecosystem it’s not very accessible. If you are a PHP, Python or Ruby developer who cut your teeth in the era of jQuery or earlier (prototype.js & script.aculo.us!) it can be quite difficult to make the transition. Combining the modern JS environments with platforms like Django, Laravel or Rails often means having to install and setup from scratch a full Node/NPM toolchain in parallel with your backend toolchain. I believe this is some of the reason for such a disconnect between the the “backend” and “frontend” unless you go 100% JS. I think it's pushed a lot of devs who used to think of themselves as "full stack" towards the backend. I’m trying to fix this with Tetra (https://www.tetraframework.com https://www.tetraframework.com) for the Django ecosystem, the plan is to eventually bundle a esbuild/postcss/sass/less toolchain along with built in tools for installing JS dependancies so you can completely live within the Python/Django environment. It will manage all the complexities of JS tooling for you. The vast majority of developers don't want to think about tooling, they just want to build something quickly and get it out there.
whiddershins 4y ago
It is so true. I have seen experienced developers pull their hair out for a day or more trying to get a basic build system working, or to import a simple module. I have been that developer. I have been that developer, tried to communicate the lessons learned to other developers, and ended up finding out they couldn’t learn from my mistakes and had to reinvent the wheel with many hours of frustration anyway. I develop in Node and Sveltekit regularly and the chances that on any given day my flow might be crushed by random madness is unacceptably high. I’m not even sure what I think about it all.
- cxr 4y ago
  Thanks for sharing this account of your experience. This is helpful in the face of denialism. See also: <https://news.ycombinator.com/item?id=22991033 https://news.ycombinator.com/item?id=22991033>
noufalibrahim 4y ago
It says quite a bit that when I got started coding (with minimal access to the internet) and not much experience understanding "cryptic" error messages, I was able to compile the Linux kernel and bootstrap gcc without a native compiler on Solaris. My day job used to mostly be Python. It can be a confusing ecosystem. I teach it to students and I can see the trouble they have. Other languages are different. With C projects, I can mostly get them to work. In fact, it's not too hard to even compile nodeJS from scratch. I've even had some amount of luck fumbling in the dark with languages I'm not familiar with to submit pull requests. Javscript is a whole different ballgame though and I fully sympathise with John. It's very counter intuitive and even when I've been in the thick of it, I've had to squint quite a bit to make sense of how the ecosystem operated.
hudo 4y ago
My experience also. As a backend engineer trying to create a front end app, the whole toolchain of JS, bundlers, minifiers, Typescript, React... is basically; works if you have one magical init script that wires up everything, and much more than you really need since its tailored for more complex apps, but if you need just simplest thing, like run Typescript app in browser, well, good luck with that! Hundreds of tutorials (unofficial blog posts) on internents, none of them work. Front end dev work is broken. Also, funny experience: asked few senior FE devs how to configure React, webpack and TS manually, absolutely nobody could do it.
- btbuildem 4y ago
  The best part: all of the utils in the tool chains "evolve" and so your one script has to be regularly modified and kept up to date. A project that "just worked" but has been on ice for several months, will now not even build after you pull updates etc. It's infuriating. I used to work on a front-end team, and a good 20% of our time was spent babying the build chain, I kid you not.
- threads2 4y ago
  Always wanted to learn about webpack - doesn't feel good using CRA (create-react-app), needing to configure webpack, ejecting CRA, and then being the "owner" of the config without knowing anything about it - thanks for the impetus.
- maxloh 4y ago
  It is not quite hard to learn actually. You just need to go through the webpack Concepts section[0]. Documentations in the JavaScript ecosystem are quite good and explanatory compared to other languages (like Java). Not every front-end developers learn the internals of the tool they chose, like create-react-app. Most of them settled down if the solution "just work". [0]: https://webpack.js.org/concepts/ https://webpack.js.org/concepts/
  - lucidguppy 4y ago
    X is not hard, you just have to Y. Be careful of these statements, you have to understand why a person says X is hard. The OP stated he did extensive work trying to get it to work and found it difficult. You posted one link out of thousands. When talking about these things - its not like there's a problem with one solution. There's one problem with thousands of answers that are frustratingly close to correct, but not correct. That's why X is hard.
qwertox 4y ago
This is exactly my issue with all this modern JavaScript / Node-stuff. The boilerplate just to get the simplest thing started is brutal. Now I'm dealing with some Vue3/Quasar/TipTap stuff, and I still don't know what exactly I have there, but just that it is working somehow. Python is such a pleasure to work with that I wish that all this modern web stuff were more like it.
- mattlondon 4y ago
  If you try simple vanilla javascript, then you may be surprised at how pythonic it is in cerain ways - e.g. just open a browser (any browser!) and you have a javascript REPL read to go in the developer tools. Node severely complicates and confuses things, but node alone is not javascript. Vanilla JS is IMHO a very nice and expressive language, and you do not need any of the Node/Webpack/React/Vue/jquery/whatever to do effective things in Javascript these days as it is very capable on its own.
  - qwertox 4y ago
    I usually do use Vue and Quasar via UMD (?) directly in the browser together with http-vue-loader, which makes it bearable and is pretty powerful as well, but then there's a lot of handpicking with libraries like dayjs (when used with plugins) or TipTap which then just doesn't scale, so you need to start to use some tooling. So you fall back to the recommended tooling and then it begins.
  - atemerev 4y ago
    Oh, there is another way to code with JS on the server side? Something else besides node?
    - mattlondon 4y ago
      Try http://deno.land http://deno.land - think of it as sequel to node (written by same guy who created node, aiming to fix mistakes of the past - e.g. deno does not use NPM)
    - krapp 4y ago
AltruisticGapHN 4y ago
We just need all this tooling to go in the browser.. which is where it always belonged. That was the purpose of JS. To "just run" in the browser. It's getting there but very slowly. As for my own rant, simply the fact that Microsoft, of all places are the ones who run TypeScript and now the proposal to add TS to native JS.. is part of the issue. MS has zero imagination. JS needs native typing and it shouldn't be done by MS, and it should be a limited subset of TS with no particular intent to be compatible with MS's TS. Then and only then JS becomes its own thing again.
- grandpoobah 4y ago
  Who made you the arbiter of how things ought to be?
- drawkbox 4y ago
  TypeScript and C# are both great languages from Anders Hejlsberg. The Danish know how to design a language, C# developer was Mads Torgersen. Microsoft employs them so they want it used more and people like it. Fun fact: Anders Hejlsberg also designed Turbo Pascal, Delphi which were huge in their day. I agree though, JS needs to just run in the browser. All the tooling is really a leaky abstraction or unnecessary guts that get in the way. Rant: Webpack is an abomination to anything simple and clear, many dev hours are lost on it. I still think if ES4 hadn't been cancelled for ES5 we'd be in a better place. It had amazing typing, event handling and was very clear, essentially looked like TypeScript. Browsers could have easily supported ES3 and ES4, we'd have a more solid browser "just works" setup.
  - AltruisticGapHN 4y ago
    Good points. > Webpack is an abomination to anything simple and clear, many dev hours are lost on it. Check out Vite. It's basically Webpack with sensible defaults. Still the same bundling paradigm but it's been so much easier for me to use. Also way way easier to add plugins in Vite.
- krapp 4y ago
  >That was the purpose of JS. To "just run" in the browser. It's getting there but very slowly. It's not getting there, it was ALREADY THERE. Javascript has always "just run" in the browser. We don't need any of this tooling. Typescript isn't necessary. NPM isn't necessary. None of this is necessary. They're useful, yes, but they shouldn't be mandatory. The simple act of testing some code you found on Github shouldn't require any of it.
noisymemories 4y ago
I'm mostly a designer and I've been trough the same experience trying to learn the ropes of modern ES6 javascript development and this matches my experience fully. On the same note, it took me days to wrap my head around: - The small differences managing modules ( even simple stuff like inclusion paths using "~" vs "node_modules" vs ../node_modules" vs...) between build environments (Webpack vs Parcel vs ...) or even between different configurations for stuff like webpack and babel. - The module format used by different libraries. Some use only the es6 module format, some use the CommonJS standard, some use both, plus a few oddball packages that are still released as global JS libraries. - Specifically on the last one, I've yet to find a way that let you use global packages in webpack that works all the time. Sometimes you have to declare them as globals (jquery), a few other times you have to just include the js file, and in a few cases (p5.js) nothing seems to work properly. Parcel seems to require some extra plugins for this that I've never been able to configure properly. - I've tried doing some REST requests using fetch and no matter what, It always seems that there's something completely wrong with CORS and the Access-Control-Allow-Origin parameter. I've tried using both a local dev environment and a remote host, with docker and bare metal, using nginx and apache using the required headers, with SSL certs and without. Obviously I'm doing something wrong, but it never feels like there a consistent logic in what should be the right configuration to avoid such issues. For every guide that suggests you to do X there's another that says you should be doing the opposite of X.
- cauefcr 4y ago
  Personally, for the last point, I just use a disable CORS extension on my browser for local dev work, and any http-server.
tsaixingwei 4y ago
There are learning Javascript resources targeted at non-technical people and children interested in learning how to code... one of the more promising that make it easy to start coding and experimenting with code is p5js (https://p5js.org/learn/ https://p5js.org/learn/) a Javscript port of the wonderful Processing framework... beautiful and simple APIs to start coding...
deleted 4y ago
[deleted]
grandpoobah 4y ago
At an old job we affectionately referred to the process of setting up the environment and getting started as "figging" (short for configuring). It's the worst part of any dev's job exactly because it's not programming.
jakey_bakey 4y ago
This is a problem with all kinds of programming for new learners - actually writing some code is easy. But getting a development environment configured to actually allow you to start writing that code requires a ton of tacit knowledge. I find this to be the biggest hurdle to new joiners. When I was first learning in my grad job, my company did a terrible job of addressing this and threw us into a test project with no support and expected us to navigate Git and React through our own wits and poor ability to Google. What Microsoft is trying to do by introducing live coding environments into Github is a fantastic step forward.
- ricklamers 4y ago
  As a consequence what one should actually strive for, if one is aiming to become a professional software developer, is to have a good process for mastering these types of “configuration” tasks. Understanding why language ecosystems are organized the way they are, understanding the trade-offs involved etc. I believe, will make you a significantly more productive developer. It’s where I see a lot of junior developers plateauing. They keep “banging their head against the wall until it works” instead of carefully unpacking why things are breaking in order to update their mental models.
  - psyc 4y ago
    There's no mastering configuration tasks, because it's all arbitrary unilateral decisions made by randos and committees of randos. There's no logic to finding out which arcane formatted strings need to be placed where in which text files in which directories, otherwise every single thing fails out of the gate. I used to complain about having to spend my time on this even as a senior.
throwaway0x7E6 4y ago
from an insider's perspective, javascript is better than it has ever been. ES6 has fixed all significant shortcomings 8 years ago, and at this point you don't even have to transpile it the "community" however is as shit as ever, but you can easily ignore it.
PetahNZ 4y ago
Maybe we should teach beginners PHP instead of JavaScript then.
5350-uiop-1130 4y ago
honestly, i've been working with node and npm for about 6-7 years and this is a weekly experience for me. every time i run npm install i am prepared to embark on a bunch of side missions.
lucideer 4y ago
The author encounters four problems trying to approach a programming task: 1) A problem common to every programming language (feature introduction/deprecation compatibility conflicts w.r.t. import/require) 2) A security issue around browser filesystem access (not-JS related at all: HTTP content-type sniffing) 3) A usability issue with the VSCode IDE (not JS related) 4) A bug in a single JS module Concludes this is all the fault of "modern Javascript", gives up. > What hope do actual novices have? Programming is a profession requiring learning from experience - if a novice doesn't have the patience to overcome very small speedbumps like this on a daily basis while learning a new domain, this might not be a good path for them. Don't get me wrong, there's A LOT about the modern JS ecosystem that could be improved from a UX perspective, but... it's not these things. I don't think any of the 4 bullets above are avoidable: (1) is a painful but necessary migration incompatibility is an unfortunate reality, the only alternative of which is to stagnate and never introduce/deprecate breaking features ever. (4) is human error - it happens. The others aren't JS-related at all.
- deleted 4y ago
  [deleted]
- cxr 4y ago
  > Programming is a profession requiring learning from experience - if a novice doesn't have the patience to overcome very small speedbumps like this on a daily basis while learning a new domain, this might not be a good path for them. There's a lot of assumption packed into this statement. Those speedbumps used to also not be there—they were put in recently[1]. Also, having read through your comment first and then read through the article (fully expecting to find what you describe), I'm compelled to say that your summaries grossly mischaracterize the substance of the complaints actually mentioned by the author. > a painful but necessary migration incompatibility is an unfortunate reality, the only alternative of which is to stagnate and never introduce/deprecate breaking features Well, no. The module fiasco is 100% a consequence of really, really bad decisions on the part of the NodeJS folks. They created the preconditions that led to the demand for their solution. This problem/solution cycle is rife in the NodeJS/NPM world. The only way to deal with it is to opt out[1][2]. 1. <https://www.colbyrussell.com/2019/03/06/how-to-displace-javascript.html https://www.colbyrussell.com/2019/03/06/how-to-displace-java...> 2. <https://news.ycombinator.com/item?id=24495646 https://news.ycombinator.com/item?id=24495646>
korijn 4y ago
I think it's a very bizarre assumption to think that running some code you found on the internet will just do exactly what you want right out of the box. That almost never happens.
- krapp 4y ago
  They never even got to the point of running the code because of Node's bullshit, which is the point.
  - korijn 4y ago
    Is node.js giving the author bullshit or did they knowingly step into a field they are unfamiliar with, getting themselves involved with a package manager, a javascript runtime, a browser, and a local fileserver? As if you were able to instantly run whatever code you found on the internet back in the C++ days. It's bizarre. Not everything needs to have such a low barrier to entry that anyone can work with it. Who said _that_ is where we collectively set the bar? It's a false premise, and frankly it feels like toxic false entitlement open source maintainers are typically showered with.
    - krapp 4y ago
      >Is node.js giving the author bullshit or did they knowingly step into a field they are unfamiliar with, getting themselves involved with a package manager, a javascript runtime, a browser, and a local fileserver? Node.js is giving the author bullshit. They were not unfamiliar with the field. They knew what a package manager was, they already had NPM installed. They were familiar with the architecture of the web and one of them had a CS degree. >Not everything needs to have such a low barrier to entry that anyone can work with it. Who said _that_ is where we collectively set the bar? It's a false premise, and frankly it feels like more of the toxic false entitlement open source maintainers are typically showered with. I find the premise that the bar should be set artificially high just to keep people out to be toxic, especially with a language like javascript that's intended to be accessible to everyone. Generations of people learned how to code by studying (and ripping off) source code on the web, but now those people have grown up and surrounded themselves with shibboleths and want to pretend they're in a rarified air where high spec engineering expertise should be required just to get past the gate. And that's all most of the JS ecosystem is - gatekeeping. We're not talking about linking some arcane C program here, we're talking about a scripting language so simple it doesn't even know what integers are - no not even modern JS does - designed to be written in Notepad and run in a browser. Yes, this should have been simple, or at the very least much simpler than it was. Yes, it should be possible for someone who isn't a full stack developer to be able to run javascript code, even with a package manager, even random code they find on the internet, with minimum effort. Yes, it's actually easier to link and run random C++ code than it is javascript at the moment. Yes, that is a bad thing.
chiefalchemist 4y ago
I'm currently reading "The Design of Everyday Things" by Don Norman. https://en.m.wikipedia.org/wiki/The_Design_of_Everyday_Things https://en.m.wikipedia.org/wiki/The_Design_of_Everyday_Thing... And a couple of books ago I read "Don't Make Me Think" by Steve Krug. https://en.m.wikipedia.org/wiki/Don%27t_Make_Me_Think https://en.m.wikipedia.org/wiki/Don%27t_Make_Me_Think You'll see both on must-read lists for design and design thinking. But many of the concepts - sometimes in an abstract sort of way - apply to engineering. Krug's is relatively short and easy read. Norman is broad and thorough. Both deserve their tag of "highly recommended."
jmartin2683 4y ago
The JavaScript ecosystem, in my opinion, largely because JavaScript makes it so easy to write awful code and even easier to distribute it widely.
spicyusername 4y ago
ITT: - Stockholm Syndrome: Programming is supposed to be needlessly hard for beginners. - Denial: What OP describes isn't a problem because I already learned how to avoid it. - Propagation: Try this even NEWER JavaScript library / paradigm / framework to solve all your problems (and totally not create a bunch of new ones). - JavaScript Bad: See this is why nobody should ever do front-end programming. - Acceptance: It shouldn't be like this.
- InvertedRhodium 4y ago
  You forgot: - Over simplified summaries of complex viewpoints
Traubenfuchs 4y ago
Beginners just run angular/react/vue cli and restrict themselves to first-class compatible dependencies that can be installed with one loine. This way, quickly creating something useful that is good enough is easy for the novice. But yes, the plumbing the cli controls and sets up for you is insanely complex and overengineered.
longrod 4y ago
It's still mostly the same. Nothing much has happened in the JS space in the last 2 years that would make all this easier. The JS ecosystem suffers from a huge issue of duplication. There's multiple module systems, multiple ways to make a function, multiple ways to make a class, multiple ways to make a variable, multiple ways to loop over the array. Some of those exist in other languages as well but it's pretty bad in JS. The problem is a language where you can do anything but where every day something has changed and the new something is the new cool. Now you have to ditch what you learned + the libraries to migrate to this. Or you have to use babel. The module system fragmentation is the worst thing that can happen to a language. Unfortunately, I haven't seen anything remotely close to a bridge between CommonJS & ESM so both can coexist peacefully. If you turn towards one, node starts screaming about how ESM modules can't contain require and if you go the other way, well then CommonJS doesn't have import. Aside from that JS is a great language. No, just kidding it's a mess.
- lolinder 4y ago
  > The module system fragmentation is the worst thing that can happen to a language. Unfortunately, I haven't seen anything remotely close to a bridge between CommonJS & ESM so both can coexist peacefully. If you turn towards one, node starts screaming about how ESM modules can't contain require and if you go the other way, well then CommonJS doesn't have import. It's possible it's more confusing on backend node, but on my current frontend project I can import any module without caring what type it is. Yes, I have to pick one import syntax, but I'm not sure why I'd want to mix them.
  - longrod 4y ago
    You don't realize what's required for all that to work properly. Webpack + Babel at the least. Expecting that a beginner developer will have to learn these to write even simple programs is absurd.
    - lolinder 4y ago
      I set up the project myself, so, yes, I do know what's required. :) For this project, `vue create my-project` and choosing TypeScript was sufficient. I've done it before by configuring webpack and babel by hand, and yes, that can be a pain. I certainly wouldn't recommend a beginner start with that, but the existence of complicated options doesn't disqualify the simple solutions.
DrFell 4y ago
If you take the credo of don't reinvent the wheel to a fanatical extreme, your best practice devolves into a ritualistic appeasing of the wheel gods to bestow wheels upon you.
deleted 4y ago
[deleted]
wonderbore 4y ago
You don’t really have to get an outside’s perspective. I’m a literally JavaScript developer with a long career and I’m still incredibly annoyed by the state of JavaScript tooling. Fixing those errors on larger projects isn’t exactly a walk in the park either. I constantly find broken packages because people simply don’t understand how Node ESM work. Every build tool has had a decade to figure ESM out and they still all suck at it. Rollup is the only “somewhat” savior because it’s “almost” ESM-only.
bmacho 4y ago
Package management just breaks package management and software distribution most of the time. It just shouldn't be used, when not necessary. Just put your things (and the dependencies) into a single downloadable folder. Especially with javascript, it is one of the most stable things ever, everything written in the past 27 years just runs on every device, on every environment, without any problem. Heck, you can't even navigate yourself into troubles, i bet if you reverse some javascript files, browsers still will figure it out. Try that with any other top TIOBE languages.
duxup 4y ago
To me this reads like "I'm a programmer, I can just pick this up without understanding the environment I'm working in." That's not a justification for whatever they ran into, but I suspect is the reason for many of the issues. If I thought I could just write some C... I probably couldn't and nobody would think twice about that.
samsquire 4y ago
I don't like the annoyance of modern computing. Installing vagrant and Virtualbox and chocolatey on windows or apt get install on Lubuntu. When you want to deploy you need to learn Kubernetes, ingress, Nginx ingress configuration, Kubectl. I've written ansible to bring up kubernetes and consul but it probably doesn't work anymore I suspect the kubeadmin has changed with the shim removal - I wrote a tool to automate everything chef, ansible, packer, aws, terraform (http://devops-pipeline.com http://devops-pipeline.com it's a prototype and not ready for others to use but the idea of a repeatable environment stands) It's so hard to get computers setup. When I get started with some source repository I dread reading the README.md due to it requiring a complicated build procedure. And that's before you've even started reading the codebase. Once you get something working you need to keep it updated and that's when things definitely go wrongm everyone refactors and changes interfaces so things stop working.
- deleted 4y ago
  [deleted]
wruza 4y ago
It is not only javascript, the entire world of programming lacks things that just work like other non-programmer’s apps do. Most people are smart enough to automate their everything when given a set of decent tools, but instead they have to rely on smartasses who speak 90% buzzword religion and only get a vague idea of what the requirements are, cause they are mostly specialized in being themselves. I hope this “industry” will break under its weight some day and we will realize that our daily topics are irrelevant to homes and businesses. Modules vs non-modules vs node vs browser is a bullshit that should not exist, but it does, for stupidest reasons. One of them is being “amazed” by obviously average-to-questionable parts of our stacks.
JaggerJo 4y ago
Yes, the JS ecosystem is nuts.
the__alchemist 4y ago
The examples in the article are all realistic, but I'd like to add something important: This is using the NPM ecosystem and JS dependencies. A language's tooling and ecosystem are arguably part of the language itself for practical purposes. So, the article is a fair assessment. I'm making this distinction because you can use JS in what it accels at without invoking build tools and dependencies: As an imperative language making DOM manipulations without the IO-induced latency of querying a server and waiting for a response, JS gets the job done.
- krapp 4y ago
  > I'm making this distinction because you can use JS in what it access at without invoking build tools and dependencies. Theoretically, yes. Practically, no, because almost all javascript code is written in typescript, packaged into modules and distributed on NPM nowadays. There's the tiniest inking of a "vanilla js" movement out there, but otherwise all of the libraries and tutorials and advice assumes that ecosystem is a given.
  - the__alchemist 4y ago
    https://developer.mozilla.org/en-US/docs/Web/JavaScript https://developer.mozilla.org/en-US/docs/Web/JavaScript You don't need any of those to invoke client-side UI changes.
    - krapp 4y ago
      I know how javascript works, I was writing javascript before JQuery was a thing. The problem is, there's no ecosystem around plain javascript anymore. You either write everything yourself or, as OP discovered, have to work with NPM packages.
deleted 4y ago
[deleted]
soliton4 4y ago
i wonder if this kind of pattern emerges natuarlly from a community of experts. think of how you need lawers who studied for years, to understand whats going on with laws and regulations a similar pattern most certainly emerged within the german tax system. maybe the complexity of the health system is (in part) a similar pattern. i hypothesis that a community of expert will reiterate on the rules that are present within the community, over and over, until only experts who studied the topic for years can even begin to deal with it. perhaps there is even a self regulating mechnism. you need to understand a system to a certain degree in order to contribute. at some point the group who can contribute consists soley of experts who studied their field for years. those experts will then contribute and make it slightly more complex. the complexity raises but only to a degree that allows a group of experts to "catch up" with the complexity in order to contribute themselves. if it gets "to complex" it runs out of contributers
jmull 4y ago
No doubt: The standardization of modules in Javascript was a real screw up. I hope the people involved are embarrassed enough to figure out how they are going to avoid fails like this in the future. (But I suspect they pat themselves on the back and each other it was a total success.)
wly_cdgr 4y ago
That's why if you're smart enough to be a computer scientist you should just do pure math
davidhay 4y ago
Why not use Google?
lmeyerov 4y ago
Just spent an hour this morning helping a customer's 2 js devs do a hello world setup because of the first one. And even as someone experienced here, it still took me 10-15min to untangle the core issues. (In this case, enabling esm as in the article, instructing babel to preserve module imports, and then some whackamole of individual imports.) Every individual step made sense in isolation, just not in aggregate.
likortera 4y ago
The author has zero experience on JavaScript or the ecosystem and complaints how difficult it is to use a random library god knows who wrote it. This would have been a problem on any ecosystem, even more, trying to do something for the first time in life is difficult whatever it it is.

341 points by ddtaylor 4y ago

Isn't it like this with most languages? The only exceptions I can think of are Io and Go (I heard that Rust also works, but I haven't tried that one).

lbriner 4y ago
Yes it is to a lesser or greater degree. I guess a lot of languages struggle with the balance between Communism and Dictatorship. If you allow genuine communism, people don't agree on things, stuff gets built to different levels of quality, some of it maintained better than others etc. You end up with the problems we see in lots of package management. On the other hand, if you have an individual or team who dictates how stuff gets developed, what is an acceptable level of functionality, getting rid of stuff that is not maintained etc. then it is possible to build a much more reliable package management system but perhaps get less people getting involved because they can't just offer what they feel like but only what is accepted! I think some languages suffer less because they really invested in the standard library including a tonne of stuff avoiding the need for external packages. .Net, Go and Python are like this I believe.

mbrodersen 4y ago

Here is what I did when I had to create a fairly complicated web application with no prior experience in web development (but 20+ years of developer experience in other environments): I started by learning the basics: HTML, CSS and JavaScript. Without relying on any build systems or packages. And only then adding a build step or package if it really absolutely was worth it compared with writing a bit of extra code myself. It worked like a charm. I completed the project in a few months with very few dependencies. And the build “system” was simple. Which should be kinda obvious when you think about it: Every build system or package you rely on will become a liability and a major pain point down the road. Guaranteed. So the less you rely on external tools/packages, the more stable your code will be. And the more you understand the basics, the more you are able to fix problems with code you didn’t write yourself. The downside of course is that you have to invest more heavily in the basics (HTML,CSS,JS) but that is a good thing. The time you spend becoming an expert in fashionable build tool X or package Y is a waste of time. Something else will be more fashionable tomorrow so your hard earned expertise is wasted. It is a bad investment compared with deeply understanding the foundation (HTML,CSS,JS).

iamsaitam 4y ago

Is it that time of the month to shit on Javascript? oh yeah.. /s

spiderfarmer 4y ago

I've been burned by VSCode's collapsing folders more than once.

deleted 4y ago
[deleted]

goldenkey 4y ago

All he had to do was run `node index.mjs` or `npm run start` to have his index recognized as a module. Node DOES not read package.json, npm (node package manager) does. Node is not the package manager, so of course changes to package.json won't affect running `node index.js` However, node recognizes the file extension mjs as a module and will execute it as such. So renaming the extension of the script would work. Alternatively, if you wish to use the package.json info to launch node, use the package manager through `npm run start` This isn't rocket science and honestly makes perfect sense. Package management is basic stuff and Node really doesn't do it any different than Ruby gems or Pip requirements, etc..I think you and your buddy need to have a talk about the assumptions you're making with regard to the actual executable versus the package manager and re- evaluate your understanding from first principles.

MaxLeiter 4y ago
It only makes sense because you understand the decisions behind it. Try teaching JS to someone with little experience — they don’t care that the browser wants one kind of module and Node wants another. They don’t know what a module is, they just want their code to run
- goldenkey 4y ago
  The article is making the whole thing sound arcane and unreasonable when the distinction between package managers and runtimes has been the case for decades. Expecting package.json (a package manager file) to alter the behavior of node (the executable runtime) shows a lack of even first principle knowledge of computer languages, runtimes, or package managers. I don't feel bad in the slightest, because math feels like shit too when you first get into it. But the reasons are mostly sound, so complaints are mostly just whining.
  - chii 4y ago
    > shows a lack of even first principle knowledge of computer languages, runtimes, or package managers. it's more that the author has the expectation that a computer scientist (well versed in computer science) should be able to immediately discern the intricacies of software construction and engineering. The complexities of a software system is distinct and different from that of computer science. It's like saying that a physicist would be able to do the job of a construction civil engineer, because they know the physical theories of forces.

tarcon 4y ago

Chances are, the only thing interesting from that package is a single source file, which you could just copy over to your project.

sullyj3 4y ago
I feel like the point of the article isn't so much "how do I solve this specific issue" as "this is the general state of JS packaging", and the solution you present doesn't work in the general case of larger, less trivial dependencies
- chii 4y ago
  But the thing is, the general problem of packaging is a complicated system, and the current solution developed are there to solve those complications (which adds more complications unfortunately). However, the article wasn't about this general problem of package management. It's a problem of somebody wanting to test out some code, and went down the rabbit hole without understanding what they're doing (not a slight at them - it's hard to know what to do). Ideally, you don't go down that route, because testing out some code doesn't require solving the packaging problem.

wrnr 4y ago

Deno uses ES modules and has a build in TypeScript compiler and solves these issues. Just be careful when using different versions of different packages and always use the same version of a service like esm.sh that translates CommonJS modules to ES modules, it has a versioned API so esm.sh/v70/lodash@1.2 != esm.sh/v71/lodash@1.2. I hit my head on this problem for a couple of days.

cutler 4y ago
But Deno is incompatible with npm, no? Deal breaker.
- mattlondon 4y ago
  https://deno.land/manual/node#interoperating-with-node-and-npm https://deno.land/manual/node#interoperating-with-node-and-n...
- wrnr 4y ago
  No it is not, that it what the esm.sh is for. It transforms a npm package into a ES module. Just make sure that when you have the dependencies A@2 and B@1 where B@1 depends on A@1 (in package.json) then you end up with 3 dependencies A@1, A@2 and B2 which results in bugs if your code expect the versions of A to match. Similar for using the same version of A but a different version of the api like esh.sh/v10/A@1 and esh.sh/v11/B@1 this will result in esh.sh/v10/A@1, esh.sh/v11/A@1 and esh.sh/v11/B@2.
- jhgb 4y ago
  Why does it matter? Deno should not need NPM in any capacity, or does it?
  - cutler 4y ago
    Because npm is the biggest repo in the history of computing and Deno makes it redundant. The people at Jetbrains knew about backwards compatibility when they created Kotlin. It's too late to just ditch npm.

michaelsalim 4y ago

Module resolution is quite a mess in JS at the moment. With the steady move to ESM, hopefully things will get better soon. In this transition period, it's painful. Even for those that deal with JS everyday, most don't actually understand the intricacies of CommonJS & ESM.

BluSyn 4y ago
I use JS/TS every day. I tried to understand the intricacies in module/import issues. Just reading about it gave me a headache, and tempted me to just rewrite my entire project in Rust. I'm still tempted some days. It's beyond painful. It's infuriating.
- afiori 4y ago
  It is not going to convince you that ESM modules are well designed... but this post explain a lot of the intricacies https://jakearchibald.com/2021/export-default-thing-vs-thing-as-default/ https://jakearchibald.com/2021/export-default-thing-vs-thing...
  - b0afc375b5 4y ago
    I read halfway through before my brain shutoff. I keep asking myself if all this complexity is necessary.
    - afiori 4y ago
      It is a shame because the whole "import namespaces from URLs" is a nice idea. In my opinion they should have dropped the whole "live reference imports" which is a completely new concept to the language. Personally I would have liked inline modules definitions à la Rust.
Moru 4y ago
That's funny, every time I think that I should invest a bit of time to actually learn JS, someone comes along and says "a mess in JS at the moment". I can hack something to a working state but I never feel I have a full grasp of what's happening... But I grew up on assembler 35+ years ago so all this magic is unnatural. :-)

laxis96 4y ago

I can totally relate to this, even after working professionally with Angular for 3+ years and generally with JavaScript for way more than that. I recently set up a quick JS project from scratch that needed a few different npm packages and ended up spending more time understanding the >three< different ways I had to use to import the different packages (because the returned errors were utterly useless), than actually writing the business logic...

deleted 4y ago

[deleted]

pjmlp 4y ago

And this is why on personal projects I only care about JavaScript on the browser, without any npm ecosystem, classical SSR using a scripts folder.

etamponi 4y ago

I can feel the author, in particular about the mess that is node_modules resolutions (and the fact that it sounds like 99% of "tutorials" - or even package READMEs - about Node seem to be written by someone that didn't really think things through). Anyway: I think the underlying problem is that it has been hidden that Node is NOT JavaScript. It uses (some) of the JavaScript syntax, but it doesn't use its standard library, and its not guaranteed that a Node package will also run on the browser. Deno tries to fix it. But I think everyone should ask themselves: is it really worth it? The backend and the browsers are two different environments with different needs. Why making novices think that the two are interchangeable, just to disappoint them a few moments later?

qsort 4y ago
I think the reason it's worth it (to the extent that it is) is not that it's good for novices, it's that it can leverage V8 and libuv. If your claim is "you're on the backend, you have saner options" then I would agree, but this isn't really about beginners.
- etamponi 4y ago
  Don't get me wrong: the reason why both Node and Deno (and probably JavaScript itself!) are so successful is that v8 is a ridiculously good runtime, and libuv is great. Deno did something smart: all the non-web-compatible APIs are under the Deno package. That's great, and almost fixes the issue I am highlighting. If Node could do the same, and provide a way to find at "compile time" (that is, statically), if a package is web-compatible or not, that would be very good. My issue has probably more to do with npm than with Node itself.
MCArth 4y ago
Because for lots of code, they are interchangeable, and being able to write your code that runs on both the server and client can be very useful. Not to mention that splitting the ecosystem down the middle would result in less high quality modules that can fit your specific usecase!
norman784 4y ago

bryanrasmussen 4y ago

I always go into these things hoping the outsider will be an Amish farmer or professional welder, but it always turns out to be just another programmer.

_ZeD_ 4y ago
in what scenario an amish farmer, a professional welder, or, well, anything but a programmer, would know anything about this "javascript" thing?
- donthellbanme 4y ago
  You would be suprized. I know a few people whom keep up on tech trends, even though it has nothing to do with their job. I follow programming trends, basically through HN, and self study. (I have wasted a lot of money on programming/Computing books.), and I'm basically a Jack of all Trades in life. I'm a mechanic certain years. I'm a contractor certain years. I'm a Electrician when I am very low on money. I'm a Watchmaker whenever someone asks me what I do. (I hate that last sociatial question. When did it become copacetic to ask for job status, and finances. I guess it came with the Selfie. (I didn't use a question mark on purpose. Too disenfranchised today to care.) I do miss the days before relying on bloated JS libraries. I miss the LAMP days for my personal websites. There was a free server I used to use, but forget it's name. It allowed full domain names without their branding. Like mysite.com, instead of mysite.com.branding. I know Git, Google, and Amazon offer a free page, but I just don't like learning their way of putting up a site. As you can by my verbage, I'm not a professional. But for some reason I try to stay current on certain aspects of this industry.
  - 2muchcoffeeman 4y ago
    As a programmer for my day job, I thought it was weird as well. But then I realised I am interesting in things other people do as a job: cooking, CAD, gardening, wood work, music. So people must be interested in programming as a past time.
  - corrral 4y ago

BiteCode_dev 4y ago

And this is why I gave a try to VueJS in the first place. It can be deployed with npm, or a simple script tag. It still does today, making prototypes easy to write, training very simple, and yet, it plays well with the more complex ecosystem. Now of course, VueJS has Vite, which makes all the complexity of Webpack goes away, removes the slowness of compilation and has sane defaults. Still, npm remains. I'm now used to it, but I understand that if you come from another language, it's not attractive. It's funny to me that most people consider JS packaging better than Python packaging. Both are troublesome, just for different reasons. E.G: using different versions of node is much harder, espacially on windows, or for the same project, than different versions of python. And installing compiled extensions is a way better experience in Python than in any other high level language. On the other hand, node_module is easier to use than the average venv.

zelphirkalt 4y ago
> And this is why I gave a try to VueJS in the first place. It can be deployed with npm, or a simple script tag. This is exactly, what I noticed positively about VueJS and advertised as a good feature for integrating this specific "web component" framework into a project. You can add it as simply as one used to add jQuery to any project. However, others thought of including script tag as "not proper" (even though I told them, that in the end it would all be a script tag anyway ...) and it was decided to use another framework, which is way more complicated to integrate in any statically rendered / server side rendered and template based website. Simply putting VueJS in a script tag is not a problem. One can cache it easily and one can use noscript tags at places in any page templates. All is fine.

mellosouls 4y ago

Basically: How it feels to learn JavaScript in 2016 https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f https://hackernoon.com/how-it-feels-to-learn-javascript-in-2... Original old-man-railing-at-modern-tech parody: https://circleci.com/blog/its-the-future/ https://circleci.com/blog/its-the-future/

moss2 4y ago
That old-man-railing-at-modern-tech parody was a great read
- masswerk 4y ago
  Now this inspired me to the great idea that we all should move to microservices in the browser, running as concurrent background tasks along a managed message bus, as soon as possible… (Functional programming and modules are dead, browser microservices are the future! We may even launch our web app in a fleet of redundant windows/tabs, by the this greatly improving stability!) ;-)
  - jeroenhd 4y ago
    Write a system of service workers intercepting each other's HTTP requests and I think you can do it!
    - masswerk 4y ago
      Also, include WebRTC for distributed remote partitions! (For redundant peer to peer backup, call your Ma and ask her to join your session as a distributed backup peer. If your computer dies, she'll still have the data. Now she really shouldn't close that window until your gear comes back from service…)
brycewray 4y ago
Both of those inspired me to write what amounts to an homage, specifically about web development: https://www.brycewray.com/posts/2021/01/easy-peasy/ https://www.brycewray.com/posts/2021/01/easy-peasy/ . . . and, as I note in the opening: > I do **not** pretend this is in the originals’ amazing league.

gernb 4y ago

sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error. repeat the same with xcode and any project in c, c++, objc, swift okay how about ruby? oh I have old ruby , hmmm , try to install new ruby, seems to run, but it can't find certain gems or something. oh and this other ruby thing I was using is now broken ? why do I have to install this stuff globally? You don't but there are several magic spells you must execute and runes you must set in the rigtt places. Oh ... I think I got that setup but it getting this new error. .... I'm sypathetic it sucks but it's not unique to js

Madmallard 4y ago
Stacks being nonfunctional on install is a failure not progress
synthmeat 4y ago
Go is yet to prove its stability over timespans similar to those languages you've mentioned, but it doesn't have many of noted (and similar) quirks.
- rat9988 4y ago
  My old go code doesn't compile anymore with the newer compiler versions
  - synthmeat 4y ago
    What was it that broke it? Usage of unsafe? Security and bug fixes in the compiler/tooling? Just interested.
    - rat9988 4y ago
      I didn't try for a long time I have a hard time remembering. I believe it had something to do about how it handles dependencies.

mattlondon 4y ago

I think the problem was using Node in the first place - most the article is fighting node + NPM nonsense. I personally try to avoid Node + NPM where I can these days, and use Deno for backend stuff since it is much more sane IMO. I've never heard of people putting typescript into a .js file - is that some node thing? Modules in the browser for vanilla JS is a delight and Just Works though. I've started doing it recently and it is lovely - no need for a bundler/compile step. There are concerns about load performance if there ends up being many modules, but you can do on-demand module loading via vanilla javascript (import returns a promise IIRC) for when that happens.

MCArth 4y ago
I completely disagree with this as someone who's spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem I'm not sure what the solution is, but I no longer use any packages which export only an es module.
- mattlondon 4y ago
  I guess the first thought that springs to my mind is why should ECMAscript care about what node does? Standard vanilla modules just seem to work totally fine without any issues (in standard vanilla javascript environments) while being totally intuitive, and is basically identical to how typescript does it too... and it is even very similar to how Deno does things. It seems to me that nopde + npm here is - as usual - a bit of a cesspit. It is this sort of thing that keeps driving me away from node + npm. There is just too much hassle and gotchyas and concerns when using it these days. By comparison Deno is a joy to use, as is pure vanilla js in the browser without a build step.
  - whostolemyhat 4y ago
    > why should ECMAscript care about what node does? Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day?

nathias 4y ago

looks like a Microsoft issue ...

MCArth 4y ago

I've spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem I'm not sure what the solution is, but I no longer use any packages which export only an es module.

an1sotropy 4y ago
Can you explain more what is half-baked about ES6 modules? To me the logic and syntax of how imports [1] and exports [2] are organized seems clean, but maybe I'm missing something? Sure the interoperability between things that do and do not (pure ES6) require a build/bundle/whatever, and between JavaScript and TypeScript may remain an engineering challenge, but that's not for the ES6 modules spec to solve, right? [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- MCArth 4y ago
  I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. Backwards compatibility is a serious concern. It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.

quickthrower2 4y ago

I think they (as in author and the friend) need some expectation adjustments about how easy it will be to get some random code package published for free on the web to work, regardless of the programming language. In other news I am quite annoyed by the confusing range of hardware and how difficult they make it to bolt a fencepost to a wall: There are masonry bits, high speed steel, different sizes, different anchors. And then getting the right length screws. I seem to do it all right but the post keeps slipping out. Eventually there will be dropbox-like disruption of both node.js and diy hardware, but until then just do the normal 10-20 hours of mandatory training (like udemy courses) to get the basics down.

IshKebab 4y ago
I disagree. I've never had issues of the magnitude of JS's mess with random free code written in Go or Rust. I think the reasons for it in JS's case are kind of reasonable though. Just annoying that it's taking so long to sort out.
- Gigachad 4y ago
  I have had plenty of issues trying to get packages from Rust working. Half of them depend on external libraries and its up to you to work out what package for your distro satisfies the compile. And then if its not a binary tool, you have to work out how to use it in your code, which if you are a Rust outsider, is very difficult. I don't blame any of this on Rust. You can be expected to be proficient in the tools as these are not end user products designed for someone with no training.
  - IshKebab 4y ago
    > Half of them depend on external libraries Bit of an exaggeration. Some do. I would say more than with Go, but waaaay less than half. Maybe like 1/10th. OpenSSL is the most annoying. > And then if its not a binary tool, you have to work out how to use it in your code, which if you are a Rust outsider, is very difficult. I don't understand this. Of course you have to work out how to use a third party library in your code. Do libraries in other languages magically integrate themselves?

alexb_ 4y ago

This thread is also a good read: https://twitter.com/Aella_Girl/status/1522633160483385345 https://twitter.com/Aella_Girl/status/1522633160483385345 Shows that a lot of people, ESPECIALLY programmers, vastly overestimate the competence of the average person when it comes to whatever they are an expert at. You may think that this person is silly - but that is tainted by your past experience of already knowing it warping what you think the baseline average knowledge level is at. And this issue would have never been solved for normal people - the only reason this barrier was ever breached for this person was due to their large twitter following. Most people don't have that luxury. So, if you think it's hard for someone who is already a programmer - think about how needlessly complicated the entire ecosystem and everything surrounding it is for the average person. It's no wonder many people basically view anything past the surface level of computers as dark magic, and we call people good with these magical devices "wizards".

alexb_ 4y ago
Was going to edit this in but it quickly turned into a related rant about the state of things: if you don't want that, scroll past. The real problem is that there's no more room for the technological "middle class". We've gotten to the point where you cannot be SLIGHTLY interested in computers, want to make a quick app for yourself, or make something small to share with the world. You either have to have no interest at all (and live in blissful ignorance) or be so into this type of stuff that you might as well just make it a career. In between these two extremes lies a valley of frustration and needless complexity, where everything is always breaking and changing because we found out what was used 2 years ago is actually bad but THIS TIME IS DIFFERENT! because now we found a solution that is totally going to work forever this time. It's exhausting to even think about. Many people got their start programming with something like messing with simple Visual Basic stuff. I, and I'm sure many others who are reading this, started with a TI-83 and a desire to cheat on my math quiz. I know that I'm going a little off the rails here, and this has become more of a rant than anything meaningful, but I really, really hate how there's quickly becoming no space for that sort of thing - nowhere for people formerly uninterested in technology and programming to get their feet wet, nowhere to make a quick application to accomplish a small task, etc..

kovalevski 4y ago

it'd interesting to see the same experience with deno

sillycube 4y ago

That's why I stick with cdn. No build process. Slower in run time but easier to get started

samwillis 4y ago

JS tooling has come a long way in the last couple of years, Vite for example is so much better than everything that came before. Esbuild is incredible and clearly the future of all JS build tools. The trouble is that to people who are only just outside JS ecosystem it’s not very accessible. If you are a PHP, Python or Ruby developer who cut your teeth in the era of jQuery or earlier (prototype.js & script.aculo.us!) it can be quite difficult to make the transition. Combining the modern JS environments with platforms like Django, Laravel or Rails often means having to install and setup from scratch a full Node/NPM toolchain in parallel with your backend toolchain. I believe this is some of the reason for such a disconnect between the the “backend” and “frontend” unless you go 100% JS. I think it's pushed a lot of devs who used to think of themselves as "full stack" towards the backend. I’m trying to fix this with Tetra (https://www.tetraframework.com https://www.tetraframework.com) for the Django ecosystem, the plan is to eventually bundle a esbuild/postcss/sass/less toolchain along with built in tools for installing JS dependancies so you can completely live within the Python/Django environment. It will manage all the complexities of JS tooling for you. The vast majority of developers don't want to think about tooling, they just want to build something quickly and get it out there.

whiddershins 4y ago

It is so true. I have seen experienced developers pull their hair out for a day or more trying to get a basic build system working, or to import a simple module. I have been that developer. I have been that developer, tried to communicate the lessons learned to other developers, and ended up finding out they couldn’t learn from my mistakes and had to reinvent the wheel with many hours of frustration anyway. I develop in Node and Sveltekit regularly and the chances that on any given day my flow might be crushed by random madness is unacceptably high. I’m not even sure what I think about it all.

cxr 4y ago
Thanks for sharing this account of your experience. This is helpful in the face of denialism. See also: <https://news.ycombinator.com/item?id=22991033 https://news.ycombinator.com/item?id=22991033>

noufalibrahim 4y ago

It says quite a bit that when I got started coding (with minimal access to the internet) and not much experience understanding "cryptic" error messages, I was able to compile the Linux kernel and bootstrap gcc without a native compiler on Solaris. My day job used to mostly be Python. It can be a confusing ecosystem. I teach it to students and I can see the trouble they have. Other languages are different. With C projects, I can mostly get them to work. In fact, it's not too hard to even compile nodeJS from scratch. I've even had some amount of luck fumbling in the dark with languages I'm not familiar with to submit pull requests. Javscript is a whole different ballgame though and I fully sympathise with John. It's very counter intuitive and even when I've been in the thick of it, I've had to squint quite a bit to make sense of how the ecosystem operated.

hudo 4y ago

My experience also. As a backend engineer trying to create a front end app, the whole toolchain of JS, bundlers, minifiers, Typescript, React... is basically; works if you have one magical init script that wires up everything, and much more than you really need since its tailored for more complex apps, but if you need just simplest thing, like run Typescript app in browser, well, good luck with that! Hundreds of tutorials (unofficial blog posts) on internents, none of them work. Front end dev work is broken. Also, funny experience: asked few senior FE devs how to configure React, webpack and TS manually, absolutely nobody could do it.

btbuildem 4y ago
The best part: all of the utils in the tool chains "evolve" and so your one script has to be regularly modified and kept up to date. A project that "just worked" but has been on ice for several months, will now not even build after you pull updates etc. It's infuriating. I used to work on a front-end team, and a good 20% of our time was spent babying the build chain, I kid you not.
threads2 4y ago
Always wanted to learn about webpack - doesn't feel good using CRA (create-react-app), needing to configure webpack, ejecting CRA, and then being the "owner" of the config without knowing anything about it - thanks for the impetus.
maxloh 4y ago
It is not quite hard to learn actually. You just need to go through the webpack Concepts section[0]. Documentations in the JavaScript ecosystem are quite good and explanatory compared to other languages (like Java). Not every front-end developers learn the internals of the tool they chose, like create-react-app. Most of them settled down if the solution "just work". [0]: https://webpack.js.org/concepts/ https://webpack.js.org/concepts/
- lucidguppy 4y ago
  X is not hard, you just have to Y. Be careful of these statements, you have to understand why a person says X is hard. The OP stated he did extensive work trying to get it to work and found it difficult. You posted one link out of thousands. When talking about these things - its not like there's a problem with one solution. There's one problem with thousands of answers that are frustratingly close to correct, but not correct. That's why X is hard.

qwertox 4y ago

This is exactly my issue with all this modern JavaScript / Node-stuff. The boilerplate just to get the simplest thing started is brutal. Now I'm dealing with some Vue3/Quasar/TipTap stuff, and I still don't know what exactly I have there, but just that it is working somehow. Python is such a pleasure to work with that I wish that all this modern web stuff were more like it.

mattlondon 4y ago
If you try simple vanilla javascript, then you may be surprised at how pythonic it is in cerain ways - e.g. just open a browser (any browser!) and you have a javascript REPL read to go in the developer tools. Node severely complicates and confuses things, but node alone is not javascript. Vanilla JS is IMHO a very nice and expressive language, and you do not need any of the Node/Webpack/React/Vue/jquery/whatever to do effective things in Javascript these days as it is very capable on its own.
- qwertox 4y ago
  I usually do use Vue and Quasar via UMD (?) directly in the browser together with http-vue-loader, which makes it bearable and is pretty powerful as well, but then there's a lot of handpicking with libraries like dayjs (when used with plugins) or TipTap which then just doesn't scale, so you need to start to use some tooling. So you fall back to the recommended tooling and then it begins.
- atemerev 4y ago
  Oh, there is another way to code with JS on the server side? Something else besides node?
  - mattlondon 4y ago
    Try http://deno.land http://deno.land - think of it as sequel to node (written by same guy who created node, aiming to fix mistakes of the past - e.g. deno does not use NPM)
  - krapp 4y ago

AltruisticGapHN 4y ago

We just need all this tooling to go in the browser.. which is where it always belonged. That was the purpose of JS. To "just run" in the browser. It's getting there but very slowly. As for my own rant, simply the fact that Microsoft, of all places are the ones who run TypeScript and now the proposal to add TS to native JS.. is part of the issue. MS has zero imagination. JS needs native typing and it shouldn't be done by MS, and it should be a limited subset of TS with no particular intent to be compatible with MS's TS. Then and only then JS becomes its own thing again.

grandpoobah 4y ago
Who made you the arbiter of how things ought to be?
drawkbox 4y ago
TypeScript and C# are both great languages from Anders Hejlsberg. The Danish know how to design a language, C# developer was Mads Torgersen. Microsoft employs them so they want it used more and people like it. Fun fact: Anders Hejlsberg also designed Turbo Pascal, Delphi which were huge in their day. I agree though, JS needs to just run in the browser. All the tooling is really a leaky abstraction or unnecessary guts that get in the way. Rant: Webpack is an abomination to anything simple and clear, many dev hours are lost on it. I still think if ES4 hadn't been cancelled for ES5 we'd be in a better place. It had amazing typing, event handling and was very clear, essentially looked like TypeScript. Browsers could have easily supported ES3 and ES4, we'd have a more solid browser "just works" setup.
- AltruisticGapHN 4y ago
  Good points. > Webpack is an abomination to anything simple and clear, many dev hours are lost on it. Check out Vite. It's basically Webpack with sensible defaults. Still the same bundling paradigm but it's been so much easier for me to use. Also way way easier to add plugins in Vite.
krapp 4y ago
>That was the purpose of JS. To "just run" in the browser. It's getting there but very slowly. It's not getting there, it was ALREADY THERE. Javascript has always "just run" in the browser. We don't need any of this tooling. Typescript isn't necessary. NPM isn't necessary. None of this is necessary. They're useful, yes, but they shouldn't be mandatory. The simple act of testing some code you found on Github shouldn't require any of it.

noisymemories 4y ago

I'm mostly a designer and I've been trough the same experience trying to learn the ropes of modern ES6 javascript development and this matches my experience fully. On the same note, it took me days to wrap my head around: - The small differences managing modules ( even simple stuff like inclusion paths using "~" vs "node_modules" vs ../node_modules" vs...) between build environments (Webpack vs Parcel vs ...) or even between different configurations for stuff like webpack and babel. - The module format used by different libraries. Some use only the es6 module format, some use the CommonJS standard, some use both, plus a few oddball packages that are still released as global JS libraries. - Specifically on the last one, I've yet to find a way that let you use global packages in webpack that works all the time. Sometimes you have to declare them as globals (jquery), a few other times you have to just include the js file, and in a few cases (p5.js) nothing seems to work properly. Parcel seems to require some extra plugins for this that I've never been able to configure properly. - I've tried doing some REST requests using fetch and no matter what, It always seems that there's something completely wrong with CORS and the Access-Control-Allow-Origin parameter. I've tried using both a local dev environment and a remote host, with docker and bare metal, using nginx and apache using the required headers, with SSL certs and without. Obviously I'm doing something wrong, but it never feels like there a consistent logic in what should be the right configuration to avoid such issues. For every guide that suggests you to do X there's another that says you should be doing the opposite of X.

cauefcr 4y ago
Personally, for the last point, I just use a disable CORS extension on my browser for local dev work, and any http-server.

tsaixingwei 4y ago

There are learning Javascript resources targeted at non-technical people and children interested in learning how to code... one of the more promising that make it easy to start coding and experimenting with code is p5js (https://p5js.org/learn/ https://p5js.org/learn/) a Javscript port of the wonderful Processing framework... beautiful and simple APIs to start coding...

deleted 4y ago

[deleted]

grandpoobah 4y ago

At an old job we affectionately referred to the process of setting up the environment and getting started as "figging" (short for configuring). It's the worst part of any dev's job exactly because it's not programming.

jakey_bakey 4y ago

This is a problem with all kinds of programming for new learners - actually writing some code is easy. But getting a development environment configured to actually allow you to start writing that code requires a ton of tacit knowledge. I find this to be the biggest hurdle to new joiners. When I was first learning in my grad job, my company did a terrible job of addressing this and threw us into a test project with no support and expected us to navigate Git and React through our own wits and poor ability to Google. What Microsoft is trying to do by introducing live coding environments into Github is a fantastic step forward.

ricklamers 4y ago
As a consequence what one should actually strive for, if one is aiming to become a professional software developer, is to have a good process for mastering these types of “configuration” tasks. Understanding why language ecosystems are organized the way they are, understanding the trade-offs involved etc. I believe, will make you a significantly more productive developer. It’s where I see a lot of junior developers plateauing. They keep “banging their head against the wall until it works” instead of carefully unpacking why things are breaking in order to update their mental models.
- psyc 4y ago
  There's no mastering configuration tasks, because it's all arbitrary unilateral decisions made by randos and committees of randos. There's no logic to finding out which arcane formatted strings need to be placed where in which text files in which directories, otherwise every single thing fails out of the gate. I used to complain about having to spend my time on this even as a senior.

throwaway0x7E6 4y ago

from an insider's perspective, javascript is better than it has ever been. ES6 has fixed all significant shortcomings 8 years ago, and at this point you don't even have to transpile it the "community" however is as shit as ever, but you can easily ignore it.

PetahNZ 4y ago

Maybe we should teach beginners PHP instead of JavaScript then.

5350-uiop-1130 4y ago

honestly, i've been working with node and npm for about 6-7 years and this is a weekly experience for me. every time i run npm install i am prepared to embark on a bunch of side missions.

lucideer 4y ago

The author encounters four problems trying to approach a programming task: 1) A problem common to every programming language (feature introduction/deprecation compatibility conflicts w.r.t. import/require) 2) A security issue around browser filesystem access (not-JS related at all: HTTP content-type sniffing) 3) A usability issue with the VSCode IDE (not JS related) 4) A bug in a single JS module Concludes this is all the fault of "modern Javascript", gives up. > What hope do actual novices have? Programming is a profession requiring learning from experience - if a novice doesn't have the patience to overcome very small speedbumps like this on a daily basis while learning a new domain, this might not be a good path for them. Don't get me wrong, there's A LOT about the modern JS ecosystem that could be improved from a UX perspective, but... it's not these things. I don't think any of the 4 bullets above are avoidable: (1) is a painful but necessary migration incompatibility is an unfortunate reality, the only alternative of which is to stagnate and never introduce/deprecate breaking features ever. (4) is human error - it happens. The others aren't JS-related at all.

deleted 4y ago
[deleted]
cxr 4y ago
> Programming is a profession requiring learning from experience - if a novice doesn't have the patience to overcome very small speedbumps like this on a daily basis while learning a new domain, this might not be a good path for them. There's a lot of assumption packed into this statement. Those speedbumps used to also not be there—they were put in recently[1]. Also, having read through your comment first and then read through the article (fully expecting to find what you describe), I'm compelled to say that your summaries grossly mischaracterize the substance of the complaints actually mentioned by the author. > a painful but necessary migration incompatibility is an unfortunate reality, the only alternative of which is to stagnate and never introduce/deprecate breaking features Well, no. The module fiasco is 100% a consequence of really, really bad decisions on the part of the NodeJS folks. They created the preconditions that led to the demand for their solution. This problem/solution cycle is rife in the NodeJS/NPM world. The only way to deal with it is to opt out[1][2]. 1. <https://www.colbyrussell.com/2019/03/06/how-to-displace-javascript.html https://www.colbyrussell.com/2019/03/06/how-to-displace-java...> 2. <https://news.ycombinator.com/item?id=24495646 https://news.ycombinator.com/item?id=24495646>

korijn 4y ago

I think it's a very bizarre assumption to think that running some code you found on the internet will just do exactly what you want right out of the box. That almost never happens.

krapp 4y ago
They never even got to the point of running the code because of Node's bullshit, which is the point.
- korijn 4y ago
  Is node.js giving the author bullshit or did they knowingly step into a field they are unfamiliar with, getting themselves involved with a package manager, a javascript runtime, a browser, and a local fileserver? As if you were able to instantly run whatever code you found on the internet back in the C++ days. It's bizarre. Not everything needs to have such a low barrier to entry that anyone can work with it. Who said _that_ is where we collectively set the bar? It's a false premise, and frankly it feels like toxic false entitlement open source maintainers are typically showered with.
  - krapp 4y ago
    >Is node.js giving the author bullshit or did they knowingly step into a field they are unfamiliar with, getting themselves involved with a package manager, a javascript runtime, a browser, and a local fileserver? Node.js is giving the author bullshit. They were not unfamiliar with the field. They knew what a package manager was, they already had NPM installed. They were familiar with the architecture of the web and one of them had a CS degree. >Not everything needs to have such a low barrier to entry that anyone can work with it. Who said _that_ is where we collectively set the bar? It's a false premise, and frankly it feels like more of the toxic false entitlement open source maintainers are typically showered with. I find the premise that the bar should be set artificially high just to keep people out to be toxic, especially with a language like javascript that's intended to be accessible to everyone. Generations of people learned how to code by studying (and ripping off) source code on the web, but now those people have grown up and surrounded themselves with shibboleths and want to pretend they're in a rarified air where high spec engineering expertise should be required just to get past the gate. And that's all most of the JS ecosystem is - gatekeeping. We're not talking about linking some arcane C program here, we're talking about a scripting language so simple it doesn't even know what integers are - no not even modern JS does - designed to be written in Notepad and run in a browser. Yes, this should have been simple, or at the very least much simpler than it was. Yes, it should be possible for someone who isn't a full stack developer to be able to run javascript code, even with a package manager, even random code they find on the internet, with minimum effort. Yes, it's actually easier to link and run random C++ code than it is javascript at the moment. Yes, that is a bad thing.

chiefalchemist 4y ago

I'm currently reading "The Design of Everyday Things" by Don Norman. https://en.m.wikipedia.org/wiki/The_Design_of_Everyday_Things https://en.m.wikipedia.org/wiki/The_Design_of_Everyday_Thing... And a couple of books ago I read "Don't Make Me Think" by Steve Krug. https://en.m.wikipedia.org/wiki/Don%27t_Make_Me_Think https://en.m.wikipedia.org/wiki/Don%27t_Make_Me_Think You'll see both on must-read lists for design and design thinking. But many of the concepts - sometimes in an abstract sort of way - apply to engineering. Krug's is relatively short and easy read. Norman is broad and thorough. Both deserve their tag of "highly recommended."

jmartin2683 4y ago

The JavaScript ecosystem, in my opinion, largely because JavaScript makes it so easy to write awful code and even easier to distribute it widely.

spicyusername 4y ago

ITT: - Stockholm Syndrome: Programming is supposed to be needlessly hard for beginners. - Denial: What OP describes isn't a problem because I already learned how to avoid it. - Propagation: Try this even NEWER JavaScript library / paradigm / framework to solve all your problems (and totally not create a bunch of new ones). - JavaScript Bad: See this is why nobody should ever do front-end programming. - Acceptance: It shouldn't be like this.

InvertedRhodium 4y ago
You forgot: - Over simplified summaries of complex viewpoints

Traubenfuchs 4y ago

Beginners just run angular/react/vue cli and restrict themselves to first-class compatible dependencies that can be installed with one loine. This way, quickly creating something useful that is good enough is easy for the novice. But yes, the plumbing the cli controls and sets up for you is insanely complex and overengineered.

longrod 4y ago

It's still mostly the same. Nothing much has happened in the JS space in the last 2 years that would make all this easier. The JS ecosystem suffers from a huge issue of duplication. There's multiple module systems, multiple ways to make a function, multiple ways to make a class, multiple ways to make a variable, multiple ways to loop over the array. Some of those exist in other languages as well but it's pretty bad in JS. The problem is a language where you can do anything but where every day something has changed and the new something is the new cool. Now you have to ditch what you learned + the libraries to migrate to this. Or you have to use babel. The module system fragmentation is the worst thing that can happen to a language. Unfortunately, I haven't seen anything remotely close to a bridge between CommonJS & ESM so both can coexist peacefully. If you turn towards one, node starts screaming about how ESM modules can't contain require and if you go the other way, well then CommonJS doesn't have import. Aside from that JS is a great language. No, just kidding it's a mess.

lolinder 4y ago
> The module system fragmentation is the worst thing that can happen to a language. Unfortunately, I haven't seen anything remotely close to a bridge between CommonJS & ESM so both can coexist peacefully. If you turn towards one, node starts screaming about how ESM modules can't contain require and if you go the other way, well then CommonJS doesn't have import. It's possible it's more confusing on backend node, but on my current frontend project I can import any module without caring what type it is. Yes, I have to pick one import syntax, but I'm not sure why I'd want to mix them.
- longrod 4y ago
  You don't realize what's required for all that to work properly. Webpack + Babel at the least. Expecting that a beginner developer will have to learn these to write even simple programs is absurd.
  - lolinder 4y ago
    I set up the project myself, so, yes, I do know what's required. :) For this project, `vue create my-project` and choosing TypeScript was sufficient. I've done it before by configuring webpack and babel by hand, and yes, that can be a pain. I certainly wouldn't recommend a beginner start with that, but the existence of complicated options doesn't disqualify the simple solutions.

DrFell 4y ago

If you take the credo of don't reinvent the wheel to a fanatical extreme, your best practice devolves into a ritualistic appeasing of the wheel gods to bestow wheels upon you.

deleted 4y ago

[deleted]

wonderbore 4y ago

You don’t really have to get an outside’s perspective. I’m a literally JavaScript developer with a long career and I’m still incredibly annoyed by the state of JavaScript tooling. Fixing those errors on larger projects isn’t exactly a walk in the park either. I constantly find broken packages because people simply don’t understand how Node ESM work. Every build tool has had a decade to figure ESM out and they still all suck at it. Rollup is the only “somewhat” savior because it’s “almost” ESM-only.

bmacho 4y ago

Package management just breaks package management and software distribution most of the time. It just shouldn't be used, when not necessary. Just put your things (and the dependencies) into a single downloadable folder. Especially with javascript, it is one of the most stable things ever, everything written in the past 27 years just runs on every device, on every environment, without any problem. Heck, you can't even navigate yourself into troubles, i bet if you reverse some javascript files, browsers still will figure it out. Try that with any other top TIOBE languages.

duxup 4y ago

To me this reads like "I'm a programmer, I can just pick this up without understanding the environment I'm working in." That's not a justification for whatever they ran into, but I suspect is the reason for many of the issues. If I thought I could just write some C... I probably couldn't and nobody would think twice about that.

samsquire 4y ago

I don't like the annoyance of modern computing. Installing vagrant and Virtualbox and chocolatey on windows or apt get install on Lubuntu. When you want to deploy you need to learn Kubernetes, ingress, Nginx ingress configuration, Kubectl. I've written ansible to bring up kubernetes and consul but it probably doesn't work anymore I suspect the kubeadmin has changed with the shim removal - I wrote a tool to automate everything chef, ansible, packer, aws, terraform (http://devops-pipeline.com http://devops-pipeline.com it's a prototype and not ready for others to use but the idea of a repeatable environment stands) It's so hard to get computers setup. When I get started with some source repository I dread reading the README.md due to it requiring a complicated build procedure. And that's before you've even started reading the codebase. Once you get something working you need to keep it updated and that's when things definitely go wrongm everyone refactors and changes interfaces so things stop working.

deleted 4y ago
[deleted]

wruza 4y ago

It is not only javascript, the entire world of programming lacks things that just work like other non-programmer’s apps do. Most people are smart enough to automate their everything when given a set of decent tools, but instead they have to rely on smartasses who speak 90% buzzword religion and only get a vague idea of what the requirements are, cause they are mostly specialized in being themselves. I hope this “industry” will break under its weight some day and we will realize that our daily topics are irrelevant to homes and businesses. Modules vs non-modules vs node vs browser is a bullshit that should not exist, but it does, for stupidest reasons. One of them is being “amazed” by obviously average-to-questionable parts of our stacks.

JaggerJo 4y ago

Yes, the JS ecosystem is nuts.

the__alchemist 4y ago

The examples in the article are all realistic, but I'd like to add something important: This is using the NPM ecosystem and JS dependencies. A language's tooling and ecosystem are arguably part of the language itself for practical purposes. So, the article is a fair assessment. I'm making this distinction because you can use JS in what it accels at without invoking build tools and dependencies: As an imperative language making DOM manipulations without the IO-induced latency of querying a server and waiting for a response, JS gets the job done.

krapp 4y ago
> I'm making this distinction because you can use JS in what it access at without invoking build tools and dependencies. Theoretically, yes. Practically, no, because almost all javascript code is written in typescript, packaged into modules and distributed on NPM nowadays. There's the tiniest inking of a "vanilla js" movement out there, but otherwise all of the libraries and tutorials and advice assumes that ecosystem is a given.
- the__alchemist 4y ago
  https://developer.mozilla.org/en-US/docs/Web/JavaScript https://developer.mozilla.org/en-US/docs/Web/JavaScript You don't need any of those to invoke client-side UI changes.
  - krapp 4y ago
    I know how javascript works, I was writing javascript before JQuery was a thing. The problem is, there's no ecosystem around plain javascript anymore. You either write everything yourself or, as OP discovered, have to work with NPM packages.

deleted 4y ago

[deleted]

soliton4 4y ago

i wonder if this kind of pattern emerges natuarlly from a community of experts. think of how you need lawers who studied for years, to understand whats going on with laws and regulations a similar pattern most certainly emerged within the german tax system. maybe the complexity of the health system is (in part) a similar pattern. i hypothesis that a community of expert will reiterate on the rules that are present within the community, over and over, until only experts who studied the topic for years can even begin to deal with it. perhaps there is even a self regulating mechnism. you need to understand a system to a certain degree in order to contribute. at some point the group who can contribute consists soley of experts who studied their field for years. those experts will then contribute and make it slightly more complex. the complexity raises but only to a degree that allows a group of experts to "catch up" with the complexity in order to contribute themselves. if it gets "to complex" it runs out of contributers

jmull 4y ago

No doubt: The standardization of modules in Javascript was a real screw up. I hope the people involved are embarrassed enough to figure out how they are going to avoid fails like this in the future. (But I suspect they pat themselves on the back and each other it was a total success.)

wly_cdgr 4y ago

That's why if you're smart enough to be a computer scientist you should just do pure math

davidhay 4y ago

Why not use Google?

lmeyerov 4y ago

Just spent an hour this morning helping a customer's 2 js devs do a hello world setup because of the first one. And even as someone experienced here, it still took me 10-15min to untangle the core issues. (In this case, enabling esm as in the article, instructing babel to preserve module imports, and then some whackamole of individual imports.) Every individual step made sense in isolation, just not in aggregate.

likortera 4y ago

The author has zero experience on JavaScript or the ecosystem and complaints how difficult it is to use a random library god knows who wrote it. This would have been a problem on any ecosystem, even more, trying to do something for the first time in life is difficult whatever it it is.