14 ms·

Today’s Javascript, from an outsider’s perspective

319 points by llacb47 6y ago

deanmkenzey 6y ago
This doesn't really seem to be specific to Javascript. A beginner in pretty much any language will have to go through these kind of issues.
trashfindhunter 6y ago
> John gives up. Concludes never to touch Node, npm, or ES6 modules with a barge pole. > The End. > Note that John is a computer scientist that knows a fair bit about the Web: He had Node & npm installed, he knew what MIME types are, he could start a localhost when needed. What hope do actual novices have? The ones who don't give up on the first night will likely have more luck (try, try again).
- alanbernstein 6y ago
  Or maybe John found it less aggravating to find or create another implementation in a different language?
  - fastball 6y ago
    Well if he followed internet trends he'd try Rust next, which doesn't exactly have the most straightforward package system either.
    - DangitBobby 6y ago
      As someone with little experience in Rust, I can say that I have had no trouble downloading, compiling, and running binaries from a crate. The only hard part for me is organizing my own crate correctly.
    - saghm 6y ago
      Rust is definitely known for having a sharp learning curve, but I'm not sure what you mean about the package system. I've onboarded several people onto Rust at my job over the past year, and the package system has never been an issue for any of them.
    - jtdev 6y ago
      Or, you know, Python, Ruby, Java, Go, C#, Swift, Kotlin, etc., etc., or any number of other languages that are less of a foot-gun full of bizarre issues, poorly maintained packages, and droves of Jr. devs eager to do clever things that make the language and ecosystem psychotic.
      - runawaybottle 6y ago
        Woah woah woah, show me a Java project repo that we’re all going to be able to install here without running into an issue. I ran into one with Go imports just the other day, and since I’m new to it, it wasn’t a 10 minute google fix.
      - TechBro8615 6y ago
        Python is good at many things, but packaging is not one of them. The best python package manager at the moment is Poetry, and it drew most of its inspiration from npm and yarn... Python packaging has historically been so bad that dotcloud invented docker in an attempt to make it usable.
        Carpetsmoker 6y ago
        But at least I can just download a .py file (or a bunch of files) and just import them. Perhaps the biggest frustration/pain point in this article isn't npm as such, but that you can't "just" use some JS module.
        TechBro8615 6y ago
        You definitely can. On the server side, you can literally do that. On the client side, you can "import" one with a script tag, and increasingly you can use modules in browsers too.
        dceddia 6y ago
        Nothing would stop you from doing that (import thing from ‘./downloaded.js’) but it’s Just Not Done That Way and packages aren’t really built with that in mind, so it probably wouldn’t work very well in practice.
    - jack1243star 6y ago
      Cargo (Rust's equivalent to npm) is quite good.
    - FridgeSeal 6y ago
      I've played around with a bunch of languages, and Rusts' is unequivocally the best experience I've had so far. Cargo works as intended, literally straight out of the box, crates.io and the Cargo.toml was straightforward to figure out. Certainly way less frustrating than figuring out how to use Python virtualenv when I was first starting.
      - fastball 6y ago
        I meant how imports work within a package, since that is what was being discussed in the article. Nested `mod`s with sometimes `pub` and then `use` for other stuff certainly seems more complex to me than `import X from P`. Package/crate management is fairly trivial in both cases, yes. `npm i [package]` isn't exactly a difficult process either.
      - guitarbill 6y ago
        that's fair, but newer languages like Rust have the benefit of hindsight, and can mandate one way to do things. to be clear, i'm all for that. i don't think it's possible to do that any more with Python, the genie is out of the bottle. but you can get close with things like Black (auto-formatting) and Poetry (nicer deps mgmt and so much more). of course, how would a beginner know this? hopefully some day tools like that will become the default answers
    - NightlyDev 6y ago
      To be fair, Rust is a dream compared to JS.
  - trashfindhunter 6y ago
    He wouldn't be the first. Speaking of which, whatever happened to Dart?
zdragnar 6y ago
What experience DOES john have? I've had far worse experiences with ruby, python, scheme, clojure, java and C. If you want a language that requires zero learning to use, I am sad to say that they are very far and few between. Sure, we have a clusterf*ck of a module ecosystem and interoperability issues between preprocessors but it isn't like that is a particularly novel problem either.
- vsareto 6y ago
  The node environment and the browser environment is a pretty unique aspect to JavaScript. It adds some complexity for novices. An hour spent trying is a bit on the light side though.
  - aryonoco 6y ago
    This is one reason I'm so excited about Deno. It's basically like browser, but for (ESM) modules. Solves so many of node's problems.
- hombre_fatal 6y ago
  Now I want to see John try to build a client on another stack, like deciding between Carthage vs CocoaPods vs etc. for his iOS hello-world and running into the problems with that. Or, hell, how about the packaging systems in Go or Python? "Yeahhh, we don't really use X anymore, go ahead and use Y." John certainly failed the perseverance test though.
  - paultopia 6y ago
    It's true that basically every language (except Rust?) has nightmarish package/environment management/tooling ecosystem problems. Why is this, anyway? It's a little nuts that it's easier to learn how to code than it is to figure out how to install a module.
  - faizmokhtar 6y ago
    I don't know. I think both of the examples you provided really require less perseverance and are more of an analysis paralyis issue. In John's case, even after he got some help he still couldn't set up and run the project which is really frustating.
_bxg1 6y ago
The module syntax inconsistency situation is atrocious but we're gradually making the transition. Now that we have a clear destination, I suspect it will be a non-issue in a few years. Projects like Deno and Pika are accelerating/papering-over the transition. I've been working in JS for years and I've never encountered a module containing a typescript file with a .js extension... That was extraordinarily unfortunate. I don't think I've encountered a module containing Typescript at all. Correct practice is to build to JS and include the optional type declaration files. In my experience people are pretty good about that.
- deleted 6y ago
  [deleted]
- yawaramin 6y ago
  Now that I think about it, it was probably a Flow[1] file, they look a lot like TypeScript but have a .js extension. [1] flow.org
  - FlorianRappl 6y ago
    It was definitely flow. It was the first thing that came to my mind, because I've never seen anyone writing TS in .js files, but I've seen flow in just plain .js files - a lot.
  - _bxg1 6y ago
    Ah, yeah. Flow files do, unfortunately, stick with the .js extension by convention. However, it's still terrible practice to publish a node module that doesn't include a plain JS version of everything.
marcandre 6y ago
This resonates so much. I support some JS packages but I often wonder how anyone gets anything done in general on the JS side, and why people seem to accept the state of affairs. I'm spending most of my time with Ruby and it is night and day.
- BigJono 6y ago
  People get stuff done in JS by sidestepping all the bullshit. If you keep your tooling simple and use a minimal amount of dependencies, then JS is one of the languages/environments with the least bloat, not the most. The big problem JS has is the same one PHP used to have when it was top dog. Everyone is a fucking noob, including all the people writing all the advice online. I find almost every JS resource to be unbearably bad, with the sole exception of MDN. The vast majority of my learning these days comes from work colleagues who also have a decent level of mastery. So the real answer is probably that the people getting stuff done are happy with the current state of affairs, because it works for them. And the people that are unhappy are for the most part trying to change the current state of affairs without fully understanding it, and making it worse. I think every language suffers from this to some extent, JS just has a much worse ratio of masters to beginners so the effect is exacerbated.
deleted 6y ago
[deleted]
runawaybottle 6y ago
If you are on an older version of node and want ESM, but don’t want to use .mjs, you can try: https://www.npmjs.com/package/esm https://www.npmjs.com/package/esm The package.json should have something like this if they are going to use import/export statements so anyone on older versions don’t have to worry about it (it’s not native to Node yet without .mjs extension). We can blame whoever didn’t set that up, or the instructions should have been to just use require().
- ravenstine 6y ago
  > it’s not native to Node yet without .mjs extension Since v13, you can use ES modules without the .mjs extension if the nearest package.json includes `"type": "module"`.
  - runawaybottle 6y ago
    Thank you, that’s good to know.
kyeb 6y ago
As a computer scientist who learned JavaScript this year, I strongly agree with the sentiment here. I feel like I often spend more time debugging module errors than my actual project. Granted, once I understood the ecosystem more, I gradually began to grasp the reason these issues are around. But still, it does make it incredibly frustrating as a reasonably decent coder getting started in JavaScript.
- rraghur 6y ago
  Like many others, I'm chiming in with a me-too... IMO the biggest problem is that if you come back to JS after a hiatus, it's very likely that most of what you thought you knew would probably have changed in the interim. I mostly work on the backend.. However, I've done a decent amount of JS too. In fact, back in 2015, even built a lot of the core parts of an SPA using a mix of knockout & requirejs with minified bundles and dynamic loading and so on. Given that it stuff put together from scratch, I though picking things up after a couple of years away from js would be easy. Oh how wrong I was... In 2017/18 sought to write a starter boilerplate with vue 2, Typescript and .NET Core. I would have probably spent an order of magnitude effort more fixing build issues and warnings than on the project. Once you hit bugs/issues with 3rd party webpack modules (which is almost a given), it is not fun at all. I recently had to put up a one page visualization and was not looking forward to it. Surprisingly, create-react-app just worked out of the box. Not much of a data point - but still a pleasant experience.
  - lukeramsden 6y ago
    > Surprisingly, create-react-app just worked out of the box. create-react-app is the only thing I've used in the ecosystem that hasn't catastrophically broken for me due to some years-old issue. Except for monorepos/yarn workspaces, that still doesn't have first class support[0] [0] https://github.com/facebook/create-react-app/issues/1333 https://github.com/facebook/create-react-app/issues/1333
  - caogecym 6y ago
    Totally agree. react starter is awesome, never need to look back how to do that require import again :)
_hardwaregeek 6y ago
My friend and I decided to start a project. This friend and I have had discussions where he espoused how libraries like Webpack, React, Redux, etc. just overcomplicate the web. I decided to humor him and do a "simple" stack of lit-html, vanilla JS and ES6 modules (since they landed in browsers). It took us maybe...a day to pedal that back? The first thing to go was doing ES6 imports in the browser. I forget the exact sequence of events but the MIME issue definitely showed up, along with maybe an untrusted source issue. Say what you will about Webpack, but native ES6 modules are definitely not here yet.
- hunterloftis 6y ago
  > a "simple" stack of lit-html, vanilla JS and ES6 modules This is precisely how I’ve been building tableofsending.com and it’s been a lovely experience. You do need some babel/tsc/etc build step to reach a reasonable audience.
  - _hardwaregeek 6y ago
    Yeah I bet once you get the stack up and running, as well as smooth out the inevitable early adopter bugs of lit-html, you'll have a great experience. The subtext of this was my friend constantly telling me easy and simple it'd be versus React. When in fact each stack has its tradeoffs and incidental complexity.
    - spankalee 6y ago
      lit-html has been used in production for over 2 years now, on sites with billions of page views a day. At this point no one new to it would be an early adopter :) The issue with module loading is a pretty fundamental one, though pretty unrelated to web components. Once you understand it, there are a large number of tools that make them work. The core problem is that most modules available on npm are written with import specifiers that assume the environment supports Node's module name result. Browsers don't, so it won't load something like `import * as redux from 'redux';` The solution is a tool that transforms package names into URLs. Webpack, Rollup, Parcel, es-dev-server, Snowpack, Vite, unpkg.com, Polymer CLI, and many more do this for you. More and more of the ecosystem is moving to native modules and we're all going to have to understand this issue.
sneak 6y ago
I feel like the tremendous popularity of node caused the development team to self-reinforce bad habits, but it’s just a theory. I often wonder what the js ecosystem would look like with Google-working-on-Go levels of runtime and package management design discipline. One would really think Google would do this, especially considering that Microsoft now has veto power over the npm repository and package format. Yarn was a huge improvement but is still dependent upon the same broken backend model. AFAICT the success of the JS ecosystem is entangled with Google’s success.
- _bxg1 6y ago
  The shortcomings of JS are rooted in its legacy baggage. Go had none of that. JS today is a good language emerging from the ashes of a bad one, but there are a lot of ashes, and some of them are impossible to completely shake off.
  - sneak 6y ago
    As much as I am not a fan of js-the-language, the problems TFA described and that I addressed in GP are 100% independent of the language and are 100% in the domain of tooling. Literally nothing about javascript-the-language is why package.json is in a file format that does not support comments, or why node_modules can’t be renamed or hidden or cached properly across projects, or why any of the cryptic import issues encountered by the author of TFA happened, or why yarn had to be made because npm is (or at least was) nondeterministic. The js packaging tooling sucks, and, more importantly, has continued to suck contiguously for at least ten years. Much like Python and Ruby (cryptographic checksums, anyone?) and Debian/Ubuntu to some extent, I think nobody gives enough of a shit (or has the skills and experience and inclination) to unfuck it, or has just become blind to it over ten+ years of it sucking in the same way (much like autoconf). It is entirely unfuckable. No part of it is baked into javascript. Go’s was fucked, and they did an epic job of unfucking it with the module and caching system. The same could be done for JS. It would require forking node to handle imports sanely, and replacing npm/yarn packages (as well as the backend npm package repository they talk to)—surmountable tasks.
  - sime2009 6y ago
Animats 6y ago
It's become easier to build with hard-compiled languages than with interpretive ones. Interpretive ones shouldn't need "building", but they seem to acquire build systems anyway. Compile and link systems at least diagnose what's missing during the build process, not during execution.
- fulafel 6y ago
  Are there other languages that suffer from this? I think Python, Erlang, Ruby at least seem to have escaped the fate so far. The upside of the JS transformation into just another compiler target is that there is little reason to use JS as the source language, IMO. These JSVM languages do suffer from the same problems to varying degrees.
  - Animats 6y ago
    Python has "eggs" and "wheels" and many headaches involving them.
    - BozeWolf 6y ago
      They most of the time work though. Except for a python environment + python version, not much is required to work with it. There is no package.json, typescript, flow, javascript mix, with tens of things configured which change frequently. Also continuing to work on a python project after a year often is not much of a hassle. That being said: virtualenvs still seem to be complex matter, especially when you are a beginner.
  - osdiab 6y ago
    A major difference is that JS developers have little control over the runtime of their users, while all these other languages and especially compiled languages do. JS is a special case because it's the sole supported language of browsers, which all implement it differently—that comes with a unique layer of complexity.
- de_watcher 6y ago
  I don't know why people do this. In more complex areas of programming the code and tooling are simpler. It seems like any ecosystem just fills up to the certain level of complexity regardless of the complexity of the original task at hand.
Lerc 6y ago
I have hit a few of these myself and I have also hit similar needlessly complicated issues in a bunch of languages. This particular instance also suffers from the seam between Modern ES modules and legacy JS, which could be better. Learning a language involves learning a bunch of non-language arcana about the environment, for no particular reason. Ideally you should be able to write the helloWorld equivalent for any platform and have a single command to turn that one file into a working program, but alas we have tool chains, configurations and requirements standing in our way. I don't think it has to be like that, but it all too frequently is. Deno seems to be making an admirable effort towards making a thing that just works. Developing for Android or iOS makes the JavaScript experience positively direct.
JMTQp8lwXL 6y ago
Anybody who's an outsider is going to hit stumbling blocks. It's your choice to feign ignorance or pick yourself up. A lot of languages have their peculiarities and JavaScript is no exception. Would "Today's <Language X>, from an Outsider's Perspective" look any different? Where X is a language that's at least 20 years old.
throwaway_sun 6y ago
> But why do I… ok fine, I’m going to start a localhost. Is "start a localhost" a generic term? If someone told me to do that, I would probably freeze in embarrassment -- no one has ever told me to do that in such context-independent terms. Since this was about node/JS, did John install express, or some other static file serving module? Or did he have an unrelated tool that makes this trivial?
- tonyhb 6y ago
  It's kind of a weird phrase. Would normally "start a server". But yes, generally speaking, it's a one liner to expose $PWD: python3 -m http.server
  - deleted 6y ago
    [deleted]
  - wrycoder 6y ago
    Which listens on localhost by default.
- alesua93 6y ago
  Yup, I've never heard of that particular idiom used to describe the action of spinning up a local server, and it's not really something trivial as to not require some external tooling. So I don't know what's up with that.
- marci 6y ago
  here's how trivial it can be: https://gist.github.com/willurd/5720255 https://gist.github.com/willurd/5720255 ("Big list of http static server one-liners")
ajross 6y ago
> Turns out VS Code collapses folders with only 1 subfolder, which is why we hadn’t noticed. OMG. Decades of life in emacs (emacs!) would never have prepared me for a world where my editor would helpfully lie about the filesystem to me. Yeah, this was horrifying to read. Obviously some of it is just normal churn, and all environments have their own oral histories and weird quirks. But... yikes.
- monocasa 6y ago
  FWIW, it tries to make it clear, underlining each path component separately, and with a path separator that sin't underlined in between. It's nice for Java style packages that are all "src/com/company/project" before you get into the meat of any code. I agree though about how surprising it is.
- wildpeaks 6y ago
  Github does this as well, it's not specific to VSCode or Javascript.
Carpetsmoker 6y ago
"Quickly" using the JavaScript tooling is somewhat akin to watching one or two episodes of the 6th Game of Thrones season without watching anything else. You really need to watch season 1-5 to understand what's going on. The other day I wanted to publish a little script I've been maintaining for years as a module easily usable by WebPack and whatnot, and that's much easier said than done. I published it on npm and put some UMD magic thing in there, and I think it should work now ... but I'm not really sure to be honest (still need to look at this and confirm). Just searching "publish JavaScript module" and trying to make sense of the WebPack isn't really all that helpful, not for me anyway, as I'm joining half-way through season 6. I have no opinion on the tooling as such – I lack experience to have an informed opinion – but it sure is confusing to "quickly" do something for people who are not heavily involved in it (i.e. me)
- 5cott0 6y ago
  >UMD magic thing I use rollup for libraries and webpack only for fullblown frontend projects for precisely this reason.
  - Carpetsmoker 6y ago
    I don't use it at all, but others do and I think my little library is neat enough for others to benefit. Unfortunately, I can't get any of thus UMD stuff to work, so for the time being I just "window.imgzoom = function(..) { .. }" it shrug.
- normalnorm 6y ago
  > "Quickly" using the JavaScript tooling is somewhat akin to watching one or two episodes of the 6th Game of Thrones season without watching anything else. You really need to watch season 1-5 to understand what's going on. I disagree. In both cases, you really only need one or two episodes to know that the story is not going anywhere. It will only get more complicated and convoluted without ever rewarding you, you will realize that no thought was ever put into it, and you will only stay for the ride because of sunk costs.
  - 6y ago
darepublic 6y ago
to echo others here, python ecosystem is worse imo. And compared to cross compiling C++ and C for ARM, js ecosystem seems like easy mode. You can always just write a little script to attach your module to the window, if you feel averse to webpack
- markmark 6y ago
  I've been programming professionally a long time and had toyed with python before for small scripts, but have only recently had to write larger amounts of production code, and I was not prepared for how bad the python import system is.
p2t2p 6y ago
I'm sorry but this rant is full of bs. Liquid, stinky bs. It's like someone found a lib on Maven Central and tries to use it without having project built my maven or gradle. If they do, they're in for a looooong journey I am a backend developer and recently I had to start a personal project with _a lot_ of frontend. Googling how to setup minimal webpack config for React (using that react starter app seemed an overkill) took 15 minutes and in another 15 minutes I had a proper minimal hello world. One more hour and I had everything - eslint with standardjs, automatic formatting, everything. Everything just works, react jsx, babel, source maps, everything. For whatever question I has there is an answer one Google search away. Last time I did something serious on frontend was in 2009 and so far I've written around 2000 lines in JSX with React for my personal project and it's been an absolute _pleasure_ compared to horrors I had to deal with in 2009. Stop wining and educate yourself, it literally takes 15 minutes.
esperent 6y ago
I had a similarly frustrating experience when I first set up Python to use Django. The complete mess that is the Python 2/3 split (thankfully somewhat better now after many years), trying to figure out what the hell pip and pipenv were (this was before I was familiar with package management). However, I initially learned some Python in university and I liked it then. We just installed Idle and ran some simple scripts, and everything worked. That's the right way to learn a language. If you dive straight into JS package management, you are attempting to learn multiple things at the same time: * Node.js environment * Browser environment * JavaScript syntax * 'running a localhost' * JavaScript modules * NPM package management You need to tackle these one by one. If you do them all at once, even with prior experience in other languages, of course you're gonna have a bad time. Really what I take away from this post is that the author is a bad teacher, although the experience of her student is probably similar to what many people experience when trying to learn by themselves. There are many improvements that could be made to the JS ecosystem, but this post does not do the current state justice. What it highlights, if anything, is a problem with the available of a standardized learning path. But I'm not sure what the solution to that would be.
- open-source-ux 6y ago
  "Really what I take away from this post is that the author is a bad teacher" No she isn't. This entire thread is full of the generic excuses one has come to expect from this profession when people struggle with programming setup and running programs. Always a defence of the (broken) status quo. Something has gone wrong? You didn't read the documentation (the incomplete or non-existing documentation). Or it's actually simple, all you need to do is x, y, z followed by a, b, c - how could you not know that? (Often implied in these responses: you're clearly a clueless noob). This is quite simply a profession that wouldn't recognise 'simple' if it came and bit it on the arse (or ass).
- pottertheotter 6y ago
  I've been learning Vue this year (I'm new to anything JavaScript so that means I also had to learn JavaScript, Node, NPM, We pack, etc.). I'm getting a lot better, but it has been a pretty frustrating experience. There are so many different layers and they are constantly changing what they do and don't use in another layer. I've been working in Python for the last several years. There's definitely a learning curve there, and I get frustrated with things all the time, but the whole JavaScript ecosystem seems like such a mess compared to Python. One of the things I miss the most about Python when working in JavaScript is the documentation. And I mean the core documentation from Python.org. The Tutorial is amazing [0]. And you can download the entire documentation already in PDF. Maybe I'm one of the few, but when I'm learning something new it is such a better process if I can leave my computer and read through a tutorial and mark it up. [0] https://docs.python.org/3/tutorial/index.html https://docs.python.org/3/tutorial/index.html
franciscop 6y ago
I totally agree with the author here, but also would love to give some context since we have lived something like this before on Javascript IMHO: Callback hell around 2015. It used to be that if you wanted to do something async you'd have to create a new callback. This led into callback hell[1], which was specially bad back then on the backend. Luckily after a migration that has taken many years, now most of the libraries use async/await instead of callbacks. There was some time where this was extra difficult because some code was using callbacks and some other code was using async/await, but it's almost totally solved in 2020. Which brings us to the article on hand. This is probably one of the biggest issues, and a fake promise in Javascript right now: reuse code on the back-end and front-end. The front-end side has been using `import` for almost a decade with Webpack and friends but this was not easy on the back-end, so there was not a practical way of reusing the code in a project. Luckily since last year Node.js supports import/export, and React supports it in libraries. It took a while because it was not an easy issue. I expect that more and more libraries will start to work only with import/export, and hopefully in 1-5 years this will also be a non-issue. [3] http://callbackhell.com/ http://callbackhell.com/
- wvenable 6y ago
  > Luckily after a migration that has taken many years, now most of the libraries use async/await instead of callbacks. Is that true? I was looking to port one of my C# projects to TypeScript/Node and it uses gRPC and it's not async/await compatible. That's a pretty major library in my opinion. In the end I didn't end up porting my project because the lack of elegance compared to the C# version was too depressing -- the C# code made heavy use of async and porting without that was just too messy. I'll take another shot at the project once this problem is totally solved.
  - yawaramin 6y ago
    Well, it's true for libraries that were using Node-style callbacks ('nodebacks') which had an upgrade path to promises[1] and from there to async/await. If some library was doing a completely different style of async, then unfortunately it won't get that easy migration path but it can probably still use the Promise constructor[2] to wrap the async operation in a promise. [1] https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/Promise https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
qudat 6y ago
> just run it in the browser Yikes. I really do not think that was the solution to this problem and only added a ton of complexity. JS is in a unique position because it can run both code in a browser as well as a server-side/scripting language. In order to do that with any level of success, tooling is required. This tooling (dev server, webpack) builds on other tooling (node, babel, typescript) which is where all this complexity lives. Furthermore, some packages are not worth installing and if you run into issues with that package, then try something else. We have no information about the package they tried to install and since the JS ecosystem encourages people to publish to npm for virtually anything, this is one area where you really have to be careful. The lesson here is the same lesson with installing something like left-pad: be careful what you install and read the source code to understand what it is doing. Most of the time, these packages can be inlined easily. Just because a library exists, doesn't mean you should use it. Most of the time for JS I'm reading the library's source code to see if I can a) inline it or b) use it as inspiration to build specifically what I need.
- masswerk 6y ago
  > JS is in a unique position because it can run both code in a browser as well as a server-side/scripting language. In order to do that with any level of success, tooling is required. Mind that this was not that much of a problem back in 1997 with Netscape Navigator and Netscape Enterprise Server. I think, the real issue here is that the JS ecosystem is targeting an abstract implementation, rather than a real world one. Much of the tooling is just about turning the abstract implementation into a real world standard and, in a second step, about packaging (i.e. linking).
  - bobthepanda 6y ago
    > Much of the tooling is just about turning the abstract implementation into a real world standard and, in a second step, about packaging (i.e. linking). So long as you have browsers in various states of compliance and paying customers using those browsers, this will always be a problem.
- mikeryan 6y ago
durnygbur 6y ago
Looks to me like a regular workflow and typical gotchas... ability to resolve this and similar is what pays the salary. Is Android, QT, Django, or Java development any more straightforward? Anegdotally my perception is that people oftentimes think "It's just stupid JavaScript, let me paste it into HTML and run in a web browser, oh wait... why it doesn't work?!". If you think it's confusing then add Angular to this tiny app (it's from Google so it must be good, right?).
- Joeri 6y ago
  If you think it's confusing then add Angular to this tiny app Ironically had they run ng new followed by npm install the import instructions would have worked out of the box. In today’s javascript landscape you have to pick the template to start your project from, because starting from scratch is way more difficult.
juped 6y ago
I'm a dedicated Javascript hater, but I don't think this is a Javascript problem. This seems to be how people (not me) have decided all software should be organized now. I don't get it. I really don't.
- chadcmulligan 6y ago
  My thoughts are its to make something boring and uninteresting into something complex and special - the process of complification I like to call it. Maybe its to charge more to, like the old lawyers charge by the word scam.
  - thrwaway69 6y ago
    It's the result of code reuse and modularity taken to the extreme.
jameslk 6y ago
So basically the entire series of issues can be rooted to the fact they're trying to run TypeScript code in Node/a browser. This doesn't seem like an issue with "today's JavaScript" but rather a symptom of either not reading the docs or the module not having good docs. I wouldn't be able to compile Java code with a C++ compiler. Also that the package is published to Node Package Manager with only a TypeScript distribution seems very odd. I do agree that the Node ecosystem could be easier to use, especially with the myriad of transpilers and build tools. But this doesn't seem like a very compelling anecdote to demonstrate it. Unless the point is that NPM package authors should not be able to publish their package in languages other than Node-flavored JS?
- 0xfffafaCrash 6y ago
  One of the problems with the js community is the idea that it is a good idea to name just about anything that is js-ish in a file with a .js extension. I love Dan Abramov, but I think a large part of the blame for this can be placed on his feet for encouraging the use of js extensions for jsx. This sent a lot of people down a dark path. File extensions serve a purpose. Even more so if you don’t have a standardized header line disambiguating the contents of the file. When you rely on tribal knowledge and sophisticated build tools that rely on strange assumptions or the requirement to parse whole files with different syntaxes just to know what you are looking at you have a problem. If the c++ community had a tendency to name their java files with cpp, would you be so forgiving?
  - jameslk 6y ago
    To be honest, I don't run into much JS code that doesn't have proper extensions, but that's just been my experience for the past 6 or whatever years I've been using Node.js. If I use JSX, I use .jsx as an extension. Likewise for TS and TSX. And CoffeeScript in years past. I can't recall coming across any NPM packages that couldn't run in Node. So I can't really relate. Maybe it's confusing that there's different flavors of JS though with the same file extension: browser-flavored JS and Node-flavored JS.
    - 6y ago
jpsimons 6y ago
The problem is, these are the Node team's stated goals for ES Modules: > It is worth mentioning that many of our design decisions were made with two primary goals. Spec compliance and Web Compatibility. It is our belief that the current implementation offers a future proof model to authoring ESM modules that paves the path to Universal JavaScript. Please read more in our documentation. Sorry guys, those are the wrong goals! Just make CommonJS and ESM be mix and match interoperatable. ESM wasn't designed to be a local disk build system. Just have CommonJS behavior with ESM syntax for god's sakes.
ikaria91 6y ago
Literally my experience trying to use something to calculate distance between two points
- layoutIfNeeded 6y ago
  Have you tried Math.sqrt((a.x - b.x) * (a.x - b.x) + (a.y - b.y) * (a.y - b.y)) maybe?
  - quickthrower2 6y ago
    Even better: npm i pythag npm i complex-sqrt // then var pythag = require('pythag'); var sqrtrt = (z) => require('complex-sqrt')(z,0); let x = 3 const y = 4 var result = sqrtrt(pythag(x, y))
    - layoutIfNeeded 6y ago
      I can't tell if you're joking :S
  - deleted 6y ago
    [deleted]
ikaria91 6y ago
Literally what I went through as well just trying to use a distance between two points module... I wish I was a cool front end kid.... but this type of experience is exactly what turns me off from front end dev
- lerax 6y ago
  I wish that type of experience would be uncommon, rare, exceptions... But in my perspective is the real true state of front-end today. Everything is broken from a outside perspective, so much changes happened that for me learning the overall Common Lisp specification (from 1000+ pages) it's more easy to do JS dev stuff on browser.
lerax 6y ago
This is so shitty and sad. I wish front-end dev could be more fun, with less pain, confusion and suffering. I'm losting the hope over the years about any browser stuff. :[
methodin 6y ago
Seems like this should be directed at the particular packaged and not the ecosystem as a whole? I do feel the pain of "I just want to try this out" and it's assumed I have webpack and all the other tooling already setup to do so, though.
hypewatch 6y ago
HTML/CSS/JS has been stretched so far beyond what it was originally designed for. JavaScript’s tooling will only get harder to work with as we push it to handle more. Eventually we’ll need to find something better than HTML/CSS/JS for developing in the browser.
- de_watcher 6y ago
  Yea, the original intent of js was to write small snippets of code to stitch HTML together. The neat "software distribution system" - the web browser became very popular. The wide adoption of the browser has forced js into the realm of the general purpose languages because it was the language of that VM-browser.
axegon_ 6y ago
For years on I kept saying that Java is the worst language ever because of the tons of unnecessary boilerplate and it's "you're doing it my way or you are not doing it" approach. But over the last year I've come to realize that javascript has become much worse. A good engineer and community are identified by their ability to say "OK, you know what, this turned out to be a very stupid idea, let's start over and scrap this". However w3, mozilla, opera and every other organization behind js have turned into a full blown North Korean dictatorship and everyone who suggests that there should be alternative, they get chased down with pitchforks and never heard from again. And even if they have a constructive argument as to why everything that is going on is wrong. I'm sure that sooner or later this will bite back those organizations really REALLY hard. Basically we are in the baby boomer era of js - 30 children, 17 cars, all at least 6 liter v8's, hardly getting across the street without refueling, etc. And I'm betting that in a few years time they will be the web-equivalent of climate change and holocaust deniers.
ahupp 6y ago
Today's JS ecosystem reminds me of how people used to talk about Lisp: "Extend the language however you want, just write a macro!" And in practice that means there's a million little language variants floating around there; you can have different import semantics and language features and type systems and it's all glued together with a big pile of configuration and tooling. Obviously this flexibility has been good for progress of the JS ecosystem as whole, but I hope the next 10 years are more sedate than the last 10.
benboughton1 6y ago
I never really got the modern web app stack and Typescript/javascript compiling until I was forced to use it through Angular CLI. Then it sort of all made some sense. Having a defined structure in a complex stack helps novice people a lot. Before that it was all open up index.html template and import my js files for my projects. I am currently going through the same thing with Python/Django Rest Framework. Another fairly well defined toolbox that some wouldn't like - but it helps with learning good practices and you can lean on a community of developers that have thought long and hard about how things are well structured.
quickthrower2 6y ago
I had the same frustrating experience when I tried to drive a manual car without driving lessons. Car kept kangarooing uncontrollably, kept stalling, keeps rolling down the hill unless I press one of those metal things near my feet...
mrmonkeyman 6y ago
The title computer scientist is meaningless here. These are engineering tools, not academic abstractions. It's akin to an architect complaining about the state of drill bits or carpentry tooling. You need experience. Is that hard to grasp? You cannot lay a tile floor neatly the first time either.
fit2rule 6y ago
I just don't use Javascript, for precisely this reason, ever. Nothing is worth the hassle - no fancy libs to do spacing, or anything. This is not progress - as someone who has been professionally programming for 30+years, this state of affairs is atrocious. Its the equivalent of buying a 5-bedroom house for your kids to grow up in, only to go in to your kids room after 20 years and realise they are insane and should be committed.
- gfxgirl 6y ago
  It could be worse. I could be any other language / dev env. Trying getting a C or C++ open GL app to compile. the first hits are often 20+ years old NeHe tutorials. Every few years the libraries change, the dev environments change, and unless you're already an expert in them you have no idea what you need to change in the project to get them working again. I've run into this issue in every language. Nothing special about Javascript here.
  - fit2rule 6y ago
    20 years later, I can still write an SDL app using just the SDL repo and my C compiler, with GL features and all the other bells and whistles that made me choose SDL in the first place. Its there, it builds, it runs. There isn't a single Javascript project I've done in the last 10 years that I can return to and run again - they've all been borked by the eco-system. I dread the idea of even opening a package.json file to see what's wrong...
    - Gibbon1 6y ago
      Couple of weeks ago had a customer cross compile a project written in C. That was last compiled 8 years ago. Compiled perfectly with gcc 9.2
    - ptx 6y ago
      Try targeting Windows Script Host (i.e. cscript.exe) for your next project - it's still there and mostly unchanged since Windows 98. :) The language supported is ECMAScript 3 with some minor COM-related quirks, but with a few utility functions it's not too bad for simple scripts.
jacobedawson 6y ago
"Lo and behold, a pile of unnecessary error conditions, cryptic errors, and lack of proper feedback.". Sounds like literally every initial experience I've had with a new language / library / framework (also, life in general tbh). Usually reduced by RTFM.
zapf 6y ago
I have done close to a decade of work in js, with jQuery in 2008, all the way to react and webpacker madness. I hope someone builds a wasm based front end framework. I did a quick search and MSFT seem to be on it with their Blazor framework. Unfortunately, I am not in a hurry to go learn ASP.NET or C# anytime soon. Maybe we need a frontend framework in Golang that compiles to WebAssembly. I am rooting for Golang here, cause after a decade in Ruby/Python/JS, I am really enjoying going back to typed languages. But even a python/ruby to wasm web frontend framework will be awesome. Anything that keeps me away from node hell.
- onion2k 6y ago
  WASM compiles to what is effectively a normal JS library that exports some functions. You don't need a bundler to use that in an app, but as the complexity grows you might want one. It's likely that WASM frameworks will make that a simple process, but it'll probably end up working by using something like Webpack behind the scenes just as things like create-react-app do now. Take a look at https://rustwasm.github.io/docs/wasm-pack/ https://rustwasm.github.io/docs/wasm-pack/ for an example of what people are working on to do this. wasmbyexample has an example of how you can do it in Go right now - https://wasmbyexample.dev/examples/hello-world/hello-world.go.en-us.html https://wasmbyexample.dev/examples/hello-world/hello-world.g... - you'll need to write that index.js file yourself, and that's when you'll be back to using modern JS tooling as soon as you scale up to a real app.
  - zapf 6y ago
    Thanks for those links. I found them really educational. Does seem like we need some more tooling to avoid as much webpack pain as we can.
irrational 6y ago
So, this doesn't seem to be an issue with JavaScript per se. The issue seems to be with the insane environment people have built up around JavaScript. Typescript, node.js, npm, etc. If the code really had been plain vanilla JavaScript that a person could use from an external JS file (just like we did for 20 years) then none of this would have happened.
root_axis 6y ago
All the hand-wringing over the difficulties of js just doesn't seem to track with the reality I live every day. I've been hiring engineers for years and by far the most common skillset comes in the form of contemporary js framework knowledge, especially among juniors. Ask them to debug a native app build and they panic like the output on the screen is hieroglyphics instead of a log of useful information that they can leverage to solve their problem. Many times they're so confused they won't even google the errors because they can't distinguish the error text from the compiler info logs, and that's working with swift/kotlin, I can't even imagine what things would be like if we had any c or cpp projects. This stuff just isn't that hard.
- brailsafe 6y ago
  I can't really tell what you're getting at here. It would definitely track that your juniors know only this stuff, because often times that's all they've been exposed to and usually for a specific type of labour. It's not really generalized knowledge. It's also not difficult, but it's not trivial to explain or get started with, unless of course you're starting at the highest level and glossing over the details. It arguably should be, and at one point it was very trivial.
  - root_axis 6y ago
    > it would definitely track that your juniors know only this stuff It doesn't track with the narrative that it's difficult to get started with, in fact, it shows that the opposite is true since these skills are very common among novices. Native application development is much more challenging learning curve for novices. >details. It arguably should be, and at one point it was very trivial. Create-react-app and similar tooling make things very trivial, but the suggestion that things were trivial "at one point" and no longer so is obviously false since whatever trivialities you're referring to work just fine today as they did in 1998.
aabbcc1241 6y ago
As it has .js extension, beside typescript, it maybe flow.js script that require babel transpilation as well.
self_awareness 6y ago
No offense to anyone, but this image wraps up how JavaScript, HTML and CSS looks from my (outsider's) perspective: https://www.desktopbackground.org/download/1280x1024/2013/02/25/536059_cat-riding-fire-breathing-unicorn-photos-for-desktop_1680x1050_h.jpg https://www.desktopbackground.org/download/1280x1024/2013/02...
tiborsaas 6y ago
I had very similar experiences with Rust and C++ lately. In Rust, all I wanted is to play an audio file... failed. In C++ all I wanted is to play an MP3 file... failed. With an hours of work I figured out how resources worked in Visual Studio and got a WAV file playing. In Rust I installed a creative coding crate, it had 314 dependencies and the deps folder was 540MB. My openframeworks C++ project is 1.6GB after a bit of playing around in it :) But yeah, node_modules is heavy. Bottom line is, when you are new to an environment and you aren't prepared to fight a battle, you will bleed out quite fast.
- canada_dry 6y ago
  Python... subprocess.Popen(['cvlc','--play-and-exit','{filename_here}']) (just being cheeky)
jaylossless 6y ago
True...Story.
deleted 6y ago
[deleted]
warpspin 6y ago
I can sympathize with that. Actually I miss the times where you could just drop a script into your project and have it work and still change it if necessary without having 40MB of build time dependencies.
oweiler 6y ago
The most ridiculous thing is the guy in the comment section recommending deno.js.
jaeming 6y ago
Seems like the issue here was a lack of documentation. Almost every npm package worth their salt details the various ways to get started with something along these lines: - In the Browser: - Using Parcel/Webpack/Rollup.js...etc - From a CDN - In Node: - Using CommonJS - `const funcName = require('somePackage')` - Using Native ES Modules ...etc
z3t4 6y ago
The JavaScript ecosystem was perfect before 2015. Everything just worked! Then either Hanlon's razor or sabotage. Instead of using the existing standard module system, a new module system was invented that was so alien to the JS ecosystem that now 5 years later it's still broken. I wish ES6 modules where reverted and removed from the JS standard. Then the standard body not only completely changed the syntax of the language itself, but it also now requires a preprocessor/transpiler...

319 points by llacb47 6y ago

This doesn't really seem to be specific to Javascript. A beginner in pretty much any language will have to go through these kind of issues.

trashfindhunter 6y ago

> John gives up. Concludes never to touch Node, npm, or ES6 modules with a barge pole. > The End. > Note that John is a computer scientist that knows a fair bit about the Web: He had Node & npm installed, he knew what MIME types are, he could start a localhost when needed. What hope do actual novices have? The ones who don't give up on the first night will likely have more luck (try, try again).

alanbernstein 6y ago
Or maybe John found it less aggravating to find or create another implementation in a different language?
- fastball 6y ago
  Well if he followed internet trends he'd try Rust next, which doesn't exactly have the most straightforward package system either.
  - DangitBobby 6y ago
    As someone with little experience in Rust, I can say that I have had no trouble downloading, compiling, and running binaries from a crate. The only hard part for me is organizing my own crate correctly.
  - saghm 6y ago
    Rust is definitely known for having a sharp learning curve, but I'm not sure what you mean about the package system. I've onboarded several people onto Rust at my job over the past year, and the package system has never been an issue for any of them.
  - jtdev 6y ago
    Or, you know, Python, Ruby, Java, Go, C#, Swift, Kotlin, etc., etc., or any number of other languages that are less of a foot-gun full of bizarre issues, poorly maintained packages, and droves of Jr. devs eager to do clever things that make the language and ecosystem psychotic.
    - runawaybottle 6y ago
      Woah woah woah, show me a Java project repo that we’re all going to be able to install here without running into an issue. I ran into one with Go imports just the other day, and since I’m new to it, it wasn’t a 10 minute google fix.
    - TechBro8615 6y ago
      Python is good at many things, but packaging is not one of them. The best python package manager at the moment is Poetry, and it drew most of its inspiration from npm and yarn... Python packaging has historically been so bad that dotcloud invented docker in an attempt to make it usable.
      - Carpetsmoker 6y ago
        But at least I can just download a .py file (or a bunch of files) and just import them. Perhaps the biggest frustration/pain point in this article isn't npm as such, but that you can't "just" use some JS module.
        TechBro8615 6y ago
        You definitely can. On the server side, you can literally do that. On the client side, you can "import" one with a script tag, and increasingly you can use modules in browsers too.
        dceddia 6y ago
        Nothing would stop you from doing that (import thing from ‘./downloaded.js’) but it’s Just Not Done That Way and packages aren’t really built with that in mind, so it probably wouldn’t work very well in practice.
  - jack1243star 6y ago
    Cargo (Rust's equivalent to npm) is quite good.
  - FridgeSeal 6y ago
    I've played around with a bunch of languages, and Rusts' is unequivocally the best experience I've had so far. Cargo works as intended, literally straight out of the box, crates.io and the Cargo.toml was straightforward to figure out. Certainly way less frustrating than figuring out how to use Python virtualenv when I was first starting.
    - fastball 6y ago
      I meant how imports work within a package, since that is what was being discussed in the article. Nested `mod`s with sometimes `pub` and then `use` for other stuff certainly seems more complex to me than `import X from P`. Package/crate management is fairly trivial in both cases, yes. `npm i [package]` isn't exactly a difficult process either.
    - guitarbill 6y ago
      that's fair, but newer languages like Rust have the benefit of hindsight, and can mandate one way to do things. to be clear, i'm all for that. i don't think it's possible to do that any more with Python, the genie is out of the bottle. but you can get close with things like Black (auto-formatting) and Poetry (nicer deps mgmt and so much more). of course, how would a beginner know this? hopefully some day tools like that will become the default answers
  - NightlyDev 6y ago
    To be fair, Rust is a dream compared to JS.
- trashfindhunter 6y ago
  He wouldn't be the first. Speaking of which, whatever happened to Dart?

zdragnar 6y ago

What experience DOES john have? I've had far worse experiences with ruby, python, scheme, clojure, java and C. If you want a language that requires zero learning to use, I am sad to say that they are very far and few between. Sure, we have a clusterf*ck of a module ecosystem and interoperability issues between preprocessors but it isn't like that is a particularly novel problem either.

vsareto 6y ago
The node environment and the browser environment is a pretty unique aspect to JavaScript. It adds some complexity for novices. An hour spent trying is a bit on the light side though.
- aryonoco 6y ago
  This is one reason I'm so excited about Deno. It's basically like browser, but for (ESM) modules. Solves so many of node's problems.
hombre_fatal 6y ago
Now I want to see John try to build a client on another stack, like deciding between Carthage vs CocoaPods vs etc. for his iOS hello-world and running into the problems with that. Or, hell, how about the packaging systems in Go or Python? "Yeahhh, we don't really use X anymore, go ahead and use Y." John certainly failed the perseverance test though.
- paultopia 6y ago
  It's true that basically every language (except Rust?) has nightmarish package/environment management/tooling ecosystem problems. Why is this, anyway? It's a little nuts that it's easier to learn how to code than it is to figure out how to install a module.
- faizmokhtar 6y ago
  I don't know. I think both of the examples you provided really require less perseverance and are more of an analysis paralyis issue. In John's case, even after he got some help he still couldn't set up and run the project which is really frustating.

_bxg1 6y ago

The module syntax inconsistency situation is atrocious but we're gradually making the transition. Now that we have a clear destination, I suspect it will be a non-issue in a few years. Projects like Deno and Pika are accelerating/papering-over the transition. I've been working in JS for years and I've never encountered a module containing a typescript file with a .js extension... That was extraordinarily unfortunate. I don't think I've encountered a module containing Typescript at all. Correct practice is to build to JS and include the optional type declaration files. In my experience people are pretty good about that.

deleted 6y ago
[deleted]
yawaramin 6y ago
Now that I think about it, it was probably a Flow[1] file, they look a lot like TypeScript but have a .js extension. [1] flow.org
- FlorianRappl 6y ago
  It was definitely flow. It was the first thing that came to my mind, because I've never seen anyone writing TS in .js files, but I've seen flow in just plain .js files - a lot.
- _bxg1 6y ago
  Ah, yeah. Flow files do, unfortunately, stick with the .js extension by convention. However, it's still terrible practice to publish a node module that doesn't include a plain JS version of everything.

marcandre 6y ago

This resonates so much. I support some JS packages but I often wonder how anyone gets anything done in general on the JS side, and why people seem to accept the state of affairs. I'm spending most of my time with Ruby and it is night and day.

BigJono 6y ago
People get stuff done in JS by sidestepping all the bullshit. If you keep your tooling simple and use a minimal amount of dependencies, then JS is one of the languages/environments with the least bloat, not the most. The big problem JS has is the same one PHP used to have when it was top dog. Everyone is a fucking noob, including all the people writing all the advice online. I find almost every JS resource to be unbearably bad, with the sole exception of MDN. The vast majority of my learning these days comes from work colleagues who also have a decent level of mastery. So the real answer is probably that the people getting stuff done are happy with the current state of affairs, because it works for them. And the people that are unhappy are for the most part trying to change the current state of affairs without fully understanding it, and making it worse. I think every language suffers from this to some extent, JS just has a much worse ratio of masters to beginners so the effect is exacerbated.

deleted 6y ago

[deleted]

runawaybottle 6y ago

If you are on an older version of node and want ESM, but don’t want to use .mjs, you can try: https://www.npmjs.com/package/esm https://www.npmjs.com/package/esm The package.json should have something like this if they are going to use import/export statements so anyone on older versions don’t have to worry about it (it’s not native to Node yet without .mjs extension). We can blame whoever didn’t set that up, or the instructions should have been to just use require().

ravenstine 6y ago
> it’s not native to Node yet without .mjs extension Since v13, you can use ES modules without the .mjs extension if the nearest package.json includes `"type": "module"`.
- runawaybottle 6y ago
  Thank you, that’s good to know.

kyeb 6y ago

As a computer scientist who learned JavaScript this year, I strongly agree with the sentiment here. I feel like I often spend more time debugging module errors than my actual project. Granted, once I understood the ecosystem more, I gradually began to grasp the reason these issues are around. But still, it does make it incredibly frustrating as a reasonably decent coder getting started in JavaScript.

rraghur 6y ago
Like many others, I'm chiming in with a me-too... IMO the biggest problem is that if you come back to JS after a hiatus, it's very likely that most of what you thought you knew would probably have changed in the interim. I mostly work on the backend.. However, I've done a decent amount of JS too. In fact, back in 2015, even built a lot of the core parts of an SPA using a mix of knockout & requirejs with minified bundles and dynamic loading and so on. Given that it stuff put together from scratch, I though picking things up after a couple of years away from js would be easy. Oh how wrong I was... In 2017/18 sought to write a starter boilerplate with vue 2, Typescript and .NET Core. I would have probably spent an order of magnitude effort more fixing build issues and warnings than on the project. Once you hit bugs/issues with 3rd party webpack modules (which is almost a given), it is not fun at all. I recently had to put up a one page visualization and was not looking forward to it. Surprisingly, create-react-app just worked out of the box. Not much of a data point - but still a pleasant experience.
- lukeramsden 6y ago
  > Surprisingly, create-react-app just worked out of the box. create-react-app is the only thing I've used in the ecosystem that hasn't catastrophically broken for me due to some years-old issue. Except for monorepos/yarn workspaces, that still doesn't have first class support[0] [0] https://github.com/facebook/create-react-app/issues/1333 https://github.com/facebook/create-react-app/issues/1333
- caogecym 6y ago
  Totally agree. react starter is awesome, never need to look back how to do that require import again :)

_hardwaregeek 6y ago

My friend and I decided to start a project. This friend and I have had discussions where he espoused how libraries like Webpack, React, Redux, etc. just overcomplicate the web. I decided to humor him and do a "simple" stack of lit-html, vanilla JS and ES6 modules (since they landed in browsers). It took us maybe...a day to pedal that back? The first thing to go was doing ES6 imports in the browser. I forget the exact sequence of events but the MIME issue definitely showed up, along with maybe an untrusted source issue. Say what you will about Webpack, but native ES6 modules are definitely not here yet.

hunterloftis 6y ago
> a "simple" stack of lit-html, vanilla JS and ES6 modules This is precisely how I’ve been building tableofsending.com and it’s been a lovely experience. You do need some babel/tsc/etc build step to reach a reasonable audience.
- _hardwaregeek 6y ago
  Yeah I bet once you get the stack up and running, as well as smooth out the inevitable early adopter bugs of lit-html, you'll have a great experience. The subtext of this was my friend constantly telling me easy and simple it'd be versus React. When in fact each stack has its tradeoffs and incidental complexity.
  - spankalee 6y ago
    lit-html has been used in production for over 2 years now, on sites with billions of page views a day. At this point no one new to it would be an early adopter :) The issue with module loading is a pretty fundamental one, though pretty unrelated to web components. Once you understand it, there are a large number of tools that make them work. The core problem is that most modules available on npm are written with import specifiers that assume the environment supports Node's module name result. Browsers don't, so it won't load something like `import * as redux from 'redux';` The solution is a tool that transforms package names into URLs. Webpack, Rollup, Parcel, es-dev-server, Snowpack, Vite, unpkg.com, Polymer CLI, and many more do this for you. More and more of the ecosystem is moving to native modules and we're all going to have to understand this issue.

sneak 6y ago

I feel like the tremendous popularity of node caused the development team to self-reinforce bad habits, but it’s just a theory. I often wonder what the js ecosystem would look like with Google-working-on-Go levels of runtime and package management design discipline. One would really think Google would do this, especially considering that Microsoft now has veto power over the npm repository and package format. Yarn was a huge improvement but is still dependent upon the same broken backend model. AFAICT the success of the JS ecosystem is entangled with Google’s success.

_bxg1 6y ago
The shortcomings of JS are rooted in its legacy baggage. Go had none of that. JS today is a good language emerging from the ashes of a bad one, but there are a lot of ashes, and some of them are impossible to completely shake off.
- sneak 6y ago
  As much as I am not a fan of js-the-language, the problems TFA described and that I addressed in GP are 100% independent of the language and are 100% in the domain of tooling. Literally nothing about javascript-the-language is why package.json is in a file format that does not support comments, or why node_modules can’t be renamed or hidden or cached properly across projects, or why any of the cryptic import issues encountered by the author of TFA happened, or why yarn had to be made because npm is (or at least was) nondeterministic. The js packaging tooling sucks, and, more importantly, has continued to suck contiguously for at least ten years. Much like Python and Ruby (cryptographic checksums, anyone?) and Debian/Ubuntu to some extent, I think nobody gives enough of a shit (or has the skills and experience and inclination) to unfuck it, or has just become blind to it over ten+ years of it sucking in the same way (much like autoconf). It is entirely unfuckable. No part of it is baked into javascript. Go’s was fucked, and they did an epic job of unfucking it with the module and caching system. The same could be done for JS. It would require forking node to handle imports sanely, and replacing npm/yarn packages (as well as the backend npm package repository they talk to)—surmountable tasks.
- sime2009 6y ago

Animats 6y ago

It's become easier to build with hard-compiled languages than with interpretive ones. Interpretive ones shouldn't need "building", but they seem to acquire build systems anyway. Compile and link systems at least diagnose what's missing during the build process, not during execution.

fulafel 6y ago
Are there other languages that suffer from this? I think Python, Erlang, Ruby at least seem to have escaped the fate so far. The upside of the JS transformation into just another compiler target is that there is little reason to use JS as the source language, IMO. These JSVM languages do suffer from the same problems to varying degrees.
- Animats 6y ago
  Python has "eggs" and "wheels" and many headaches involving them.
  - BozeWolf 6y ago
    They most of the time work though. Except for a python environment + python version, not much is required to work with it. There is no package.json, typescript, flow, javascript mix, with tens of things configured which change frequently. Also continuing to work on a python project after a year often is not much of a hassle. That being said: virtualenvs still seem to be complex matter, especially when you are a beginner.
- osdiab 6y ago
  A major difference is that JS developers have little control over the runtime of their users, while all these other languages and especially compiled languages do. JS is a special case because it's the sole supported language of browsers, which all implement it differently—that comes with a unique layer of complexity.
de_watcher 6y ago
I don't know why people do this. In more complex areas of programming the code and tooling are simpler. It seems like any ecosystem just fills up to the certain level of complexity regardless of the complexity of the original task at hand.

Lerc 6y ago

I have hit a few of these myself and I have also hit similar needlessly complicated issues in a bunch of languages. This particular instance also suffers from the seam between Modern ES modules and legacy JS, which could be better. Learning a language involves learning a bunch of non-language arcana about the environment, for no particular reason. Ideally you should be able to write the helloWorld equivalent for any platform and have a single command to turn that one file into a working program, but alas we have tool chains, configurations and requirements standing in our way. I don't think it has to be like that, but it all too frequently is. Deno seems to be making an admirable effort towards making a thing that just works. Developing for Android or iOS makes the JavaScript experience positively direct.

JMTQp8lwXL 6y ago

Anybody who's an outsider is going to hit stumbling blocks. It's your choice to feign ignorance or pick yourself up. A lot of languages have their peculiarities and JavaScript is no exception. Would "Today's <Language X>, from an Outsider's Perspective" look any different? Where X is a language that's at least 20 years old.

throwaway_sun 6y ago

> But why do I… ok fine, I’m going to start a localhost. Is "start a localhost" a generic term? If someone told me to do that, I would probably freeze in embarrassment -- no one has ever told me to do that in such context-independent terms. Since this was about node/JS, did John install express, or some other static file serving module? Or did he have an unrelated tool that makes this trivial?

tonyhb 6y ago
It's kind of a weird phrase. Would normally "start a server". But yes, generally speaking, it's a one liner to expose $PWD: python3 -m http.server
- deleted 6y ago
  [deleted]
- wrycoder 6y ago
  Which listens on localhost by default.
alesua93 6y ago
Yup, I've never heard of that particular idiom used to describe the action of spinning up a local server, and it's not really something trivial as to not require some external tooling. So I don't know what's up with that.
marci 6y ago
here's how trivial it can be: https://gist.github.com/willurd/5720255 https://gist.github.com/willurd/5720255 ("Big list of http static server one-liners")

ajross 6y ago

> Turns out VS Code collapses folders with only 1 subfolder, which is why we hadn’t noticed. OMG. Decades of life in emacs (emacs!) would never have prepared me for a world where my editor would helpfully lie about the filesystem to me. Yeah, this was horrifying to read. Obviously some of it is just normal churn, and all environments have their own oral histories and weird quirks. But... yikes.

monocasa 6y ago
FWIW, it tries to make it clear, underlining each path component separately, and with a path separator that sin't underlined in between. It's nice for Java style packages that are all "src/com/company/project" before you get into the meat of any code. I agree though about how surprising it is.
wildpeaks 6y ago
Github does this as well, it's not specific to VSCode or Javascript.

Carpetsmoker 6y ago

"Quickly" using the JavaScript tooling is somewhat akin to watching one or two episodes of the 6th Game of Thrones season without watching anything else. You really need to watch season 1-5 to understand what's going on. The other day I wanted to publish a little script I've been maintaining for years as a module easily usable by WebPack and whatnot, and that's much easier said than done. I published it on npm and put some UMD magic thing in there, and I think it should work now ... but I'm not really sure to be honest (still need to look at this and confirm). Just searching "publish JavaScript module" and trying to make sense of the WebPack isn't really all that helpful, not for me anyway, as I'm joining half-way through season 6. I have no opinion on the tooling as such – I lack experience to have an informed opinion – but it sure is confusing to "quickly" do something for people who are not heavily involved in it (i.e. me)

5cott0 6y ago
>UMD magic thing I use rollup for libraries and webpack only for fullblown frontend projects for precisely this reason.
- Carpetsmoker 6y ago
  I don't use it at all, but others do and I think my little library is neat enough for others to benefit. Unfortunately, I can't get any of thus UMD stuff to work, so for the time being I just "window.imgzoom = function(..) { .. }" it shrug.
normalnorm 6y ago
> "Quickly" using the JavaScript tooling is somewhat akin to watching one or two episodes of the 6th Game of Thrones season without watching anything else. You really need to watch season 1-5 to understand what's going on. I disagree. In both cases, you really only need one or two episodes to know that the story is not going anywhere. It will only get more complicated and convoluted without ever rewarding you, you will realize that no thought was ever put into it, and you will only stay for the ride because of sunk costs.
- 6y ago

darepublic 6y ago

to echo others here, python ecosystem is worse imo. And compared to cross compiling C++ and C for ARM, js ecosystem seems like easy mode. You can always just write a little script to attach your module to the window, if you feel averse to webpack

markmark 6y ago
I've been programming professionally a long time and had toyed with python before for small scripts, but have only recently had to write larger amounts of production code, and I was not prepared for how bad the python import system is.

p2t2p 6y ago

I'm sorry but this rant is full of bs. Liquid, stinky bs. It's like someone found a lib on Maven Central and tries to use it without having project built my maven or gradle. If they do, they're in for a looooong journey I am a backend developer and recently I had to start a personal project with _a lot_ of frontend. Googling how to setup minimal webpack config for React (using that react starter app seemed an overkill) took 15 minutes and in another 15 minutes I had a proper minimal hello world. One more hour and I had everything - eslint with standardjs, automatic formatting, everything. Everything just works, react jsx, babel, source maps, everything. For whatever question I has there is an answer one Google search away. Last time I did something serious on frontend was in 2009 and so far I've written around 2000 lines in JSX with React for my personal project and it's been an absolute _pleasure_ compared to horrors I had to deal with in 2009. Stop wining and educate yourself, it literally takes 15 minutes.

esperent 6y ago

I had a similarly frustrating experience when I first set up Python to use Django. The complete mess that is the Python 2/3 split (thankfully somewhat better now after many years), trying to figure out what the hell pip and pipenv were (this was before I was familiar with package management). However, I initially learned some Python in university and I liked it then. We just installed Idle and ran some simple scripts, and everything worked. That's the right way to learn a language. If you dive straight into JS package management, you are attempting to learn multiple things at the same time: * Node.js environment * Browser environment * JavaScript syntax * 'running a localhost' * JavaScript modules * NPM package management You need to tackle these one by one. If you do them all at once, even with prior experience in other languages, of course you're gonna have a bad time. Really what I take away from this post is that the author is a bad teacher, although the experience of her student is probably similar to what many people experience when trying to learn by themselves. There are many improvements that could be made to the JS ecosystem, but this post does not do the current state justice. What it highlights, if anything, is a problem with the available of a standardized learning path. But I'm not sure what the solution to that would be.

open-source-ux 6y ago
"Really what I take away from this post is that the author is a bad teacher" No she isn't. This entire thread is full of the generic excuses one has come to expect from this profession when people struggle with programming setup and running programs. Always a defence of the (broken) status quo. Something has gone wrong? You didn't read the documentation (the incomplete or non-existing documentation). Or it's actually simple, all you need to do is x, y, z followed by a, b, c - how could you not know that? (Often implied in these responses: you're clearly a clueless noob). This is quite simply a profession that wouldn't recognise 'simple' if it came and bit it on the arse (or ass).
pottertheotter 6y ago
I've been learning Vue this year (I'm new to anything JavaScript so that means I also had to learn JavaScript, Node, NPM, We pack, etc.). I'm getting a lot better, but it has been a pretty frustrating experience. There are so many different layers and they are constantly changing what they do and don't use in another layer. I've been working in Python for the last several years. There's definitely a learning curve there, and I get frustrated with things all the time, but the whole JavaScript ecosystem seems like such a mess compared to Python. One of the things I miss the most about Python when working in JavaScript is the documentation. And I mean the core documentation from Python.org. The Tutorial is amazing [0]. And you can download the entire documentation already in PDF. Maybe I'm one of the few, but when I'm learning something new it is such a better process if I can leave my computer and read through a tutorial and mark it up. [0] https://docs.python.org/3/tutorial/index.html https://docs.python.org/3/tutorial/index.html

franciscop 6y ago

I totally agree with the author here, but also would love to give some context since we have lived something like this before on Javascript IMHO: Callback hell around 2015. It used to be that if you wanted to do something async you'd have to create a new callback. This led into callback hell[1], which was specially bad back then on the backend. Luckily after a migration that has taken many years, now most of the libraries use async/await instead of callbacks. There was some time where this was extra difficult because some code was using callbacks and some other code was using async/await, but it's almost totally solved in 2020. Which brings us to the article on hand. This is probably one of the biggest issues, and a fake promise in Javascript right now: reuse code on the back-end and front-end. The front-end side has been using `import` for almost a decade with Webpack and friends but this was not easy on the back-end, so there was not a practical way of reusing the code in a project. Luckily since last year Node.js supports import/export, and React supports it in libraries. It took a while because it was not an easy issue. I expect that more and more libraries will start to work only with import/export, and hopefully in 1-5 years this will also be a non-issue. [3] http://callbackhell.com/ http://callbackhell.com/

wvenable 6y ago
> Luckily after a migration that has taken many years, now most of the libraries use async/await instead of callbacks. Is that true? I was looking to port one of my C# projects to TypeScript/Node and it uses gRPC and it's not async/await compatible. That's a pretty major library in my opinion. In the end I didn't end up porting my project because the lack of elegance compared to the C# version was too depressing -- the C# code made heavy use of async and porting without that was just too messy. I'll take another shot at the project once this problem is totally solved.
- yawaramin 6y ago
  Well, it's true for libraries that were using Node-style callbacks ('nodebacks') which had an upgrade path to promises[1] and from there to async/await. If some library was doing a completely different style of async, then unfortunately it won't get that easy migration path but it can probably still use the Promise constructor[2] to wrap the async operation in a promise. [1] https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/Promise https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

qudat 6y ago

> just run it in the browser Yikes. I really do not think that was the solution to this problem and only added a ton of complexity. JS is in a unique position because it can run both code in a browser as well as a server-side/scripting language. In order to do that with any level of success, tooling is required. This tooling (dev server, webpack) builds on other tooling (node, babel, typescript) which is where all this complexity lives. Furthermore, some packages are not worth installing and if you run into issues with that package, then try something else. We have no information about the package they tried to install and since the JS ecosystem encourages people to publish to npm for virtually anything, this is one area where you really have to be careful. The lesson here is the same lesson with installing something like left-pad: be careful what you install and read the source code to understand what it is doing. Most of the time, these packages can be inlined easily. Just because a library exists, doesn't mean you should use it. Most of the time for JS I'm reading the library's source code to see if I can a) inline it or b) use it as inspiration to build specifically what I need.

masswerk 6y ago
> JS is in a unique position because it can run both code in a browser as well as a server-side/scripting language. In order to do that with any level of success, tooling is required. Mind that this was not that much of a problem back in 1997 with Netscape Navigator and Netscape Enterprise Server. I think, the real issue here is that the JS ecosystem is targeting an abstract implementation, rather than a real world one. Much of the tooling is just about turning the abstract implementation into a real world standard and, in a second step, about packaging (i.e. linking).
- bobthepanda 6y ago
  > Much of the tooling is just about turning the abstract implementation into a real world standard and, in a second step, about packaging (i.e. linking). So long as you have browsers in various states of compliance and paying customers using those browsers, this will always be a problem.
mikeryan 6y ago

durnygbur 6y ago

Looks to me like a regular workflow and typical gotchas... ability to resolve this and similar is what pays the salary. Is Android, QT, Django, or Java development any more straightforward? Anegdotally my perception is that people oftentimes think "It's just stupid JavaScript, let me paste it into HTML and run in a web browser, oh wait... why it doesn't work?!". If you think it's confusing then add Angular to this tiny app (it's from Google so it must be good, right?).

Joeri 6y ago
If you think it's confusing then add Angular to this tiny app Ironically had they run ng new followed by npm install the import instructions would have worked out of the box. In today’s javascript landscape you have to pick the template to start your project from, because starting from scratch is way more difficult.

juped 6y ago

I'm a dedicated Javascript hater, but I don't think this is a Javascript problem. This seems to be how people (not me) have decided all software should be organized now. I don't get it. I really don't.

chadcmulligan 6y ago
My thoughts are its to make something boring and uninteresting into something complex and special - the process of complification I like to call it. Maybe its to charge more to, like the old lawyers charge by the word scam.
- thrwaway69 6y ago
  It's the result of code reuse and modularity taken to the extreme.

jameslk 6y ago

So basically the entire series of issues can be rooted to the fact they're trying to run TypeScript code in Node/a browser. This doesn't seem like an issue with "today's JavaScript" but rather a symptom of either not reading the docs or the module not having good docs. I wouldn't be able to compile Java code with a C++ compiler. Also that the package is published to Node Package Manager with only a TypeScript distribution seems very odd. I do agree that the Node ecosystem could be easier to use, especially with the myriad of transpilers and build tools. But this doesn't seem like a very compelling anecdote to demonstrate it. Unless the point is that NPM package authors should not be able to publish their package in languages other than Node-flavored JS?

0xfffafaCrash 6y ago
One of the problems with the js community is the idea that it is a good idea to name just about anything that is js-ish in a file with a .js extension. I love Dan Abramov, but I think a large part of the blame for this can be placed on his feet for encouraging the use of js extensions for jsx. This sent a lot of people down a dark path. File extensions serve a purpose. Even more so if you don’t have a standardized header line disambiguating the contents of the file. When you rely on tribal knowledge and sophisticated build tools that rely on strange assumptions or the requirement to parse whole files with different syntaxes just to know what you are looking at you have a problem. If the c++ community had a tendency to name their java files with cpp, would you be so forgiving?
- jameslk 6y ago
  To be honest, I don't run into much JS code that doesn't have proper extensions, but that's just been my experience for the past 6 or whatever years I've been using Node.js. If I use JSX, I use .jsx as an extension. Likewise for TS and TSX. And CoffeeScript in years past. I can't recall coming across any NPM packages that couldn't run in Node. So I can't really relate. Maybe it's confusing that there's different flavors of JS though with the same file extension: browser-flavored JS and Node-flavored JS.
  - 6y ago

jpsimons 6y ago

The problem is, these are the Node team's stated goals for ES Modules: > It is worth mentioning that many of our design decisions were made with two primary goals. Spec compliance and Web Compatibility. It is our belief that the current implementation offers a future proof model to authoring ESM modules that paves the path to Universal JavaScript. Please read more in our documentation. Sorry guys, those are the wrong goals! Just make CommonJS and ESM be mix and match interoperatable. ESM wasn't designed to be a local disk build system. Just have CommonJS behavior with ESM syntax for god's sakes.

ikaria91 6y ago

Literally my experience trying to use something to calculate distance between two points

layoutIfNeeded 6y ago
Have you tried Math.sqrt((a.x - b.x) * (a.x - b.x) + (a.y - b.y) * (a.y - b.y)) maybe?
- quickthrower2 6y ago
  Even better: npm i pythag npm i complex-sqrt // then var pythag = require('pythag'); var sqrtrt = (z) => require('complex-sqrt')(z,0); let x = 3 const y = 4 var result = sqrtrt(pythag(x, y))
  - layoutIfNeeded 6y ago
    I can't tell if you're joking :S
- deleted 6y ago
  [deleted]

ikaria91 6y ago

Literally what I went through as well just trying to use a distance between two points module... I wish I was a cool front end kid.... but this type of experience is exactly what turns me off from front end dev

lerax 6y ago
I wish that type of experience would be uncommon, rare, exceptions... But in my perspective is the real true state of front-end today. Everything is broken from a outside perspective, so much changes happened that for me learning the overall Common Lisp specification (from 1000+ pages) it's more easy to do JS dev stuff on browser.

lerax 6y ago

This is so shitty and sad. I wish front-end dev could be more fun, with less pain, confusion and suffering. I'm losting the hope over the years about any browser stuff. :[

methodin 6y ago

Seems like this should be directed at the particular packaged and not the ecosystem as a whole? I do feel the pain of "I just want to try this out" and it's assumed I have webpack and all the other tooling already setup to do so, though.

hypewatch 6y ago

HTML/CSS/JS has been stretched so far beyond what it was originally designed for. JavaScript’s tooling will only get harder to work with as we push it to handle more. Eventually we’ll need to find something better than HTML/CSS/JS for developing in the browser.

de_watcher 6y ago
Yea, the original intent of js was to write small snippets of code to stitch HTML together. The neat "software distribution system" - the web browser became very popular. The wide adoption of the browser has forced js into the realm of the general purpose languages because it was the language of that VM-browser.

axegon_ 6y ago

For years on I kept saying that Java is the worst language ever because of the tons of unnecessary boilerplate and it's "you're doing it my way or you are not doing it" approach. But over the last year I've come to realize that javascript has become much worse. A good engineer and community are identified by their ability to say "OK, you know what, this turned out to be a very stupid idea, let's start over and scrap this". However w3, mozilla, opera and every other organization behind js have turned into a full blown North Korean dictatorship and everyone who suggests that there should be alternative, they get chased down with pitchforks and never heard from again. And even if they have a constructive argument as to why everything that is going on is wrong. I'm sure that sooner or later this will bite back those organizations really REALLY hard. Basically we are in the baby boomer era of js - 30 children, 17 cars, all at least 6 liter v8's, hardly getting across the street without refueling, etc. And I'm betting that in a few years time they will be the web-equivalent of climate change and holocaust deniers.

ahupp 6y ago

Today's JS ecosystem reminds me of how people used to talk about Lisp: "Extend the language however you want, just write a macro!" And in practice that means there's a million little language variants floating around there; you can have different import semantics and language features and type systems and it's all glued together with a big pile of configuration and tooling. Obviously this flexibility has been good for progress of the JS ecosystem as whole, but I hope the next 10 years are more sedate than the last 10.

benboughton1 6y ago

I never really got the modern web app stack and Typescript/javascript compiling until I was forced to use it through Angular CLI. Then it sort of all made some sense. Having a defined structure in a complex stack helps novice people a lot. Before that it was all open up index.html template and import my js files for my projects. I am currently going through the same thing with Python/Django Rest Framework. Another fairly well defined toolbox that some wouldn't like - but it helps with learning good practices and you can lean on a community of developers that have thought long and hard about how things are well structured.

quickthrower2 6y ago

I had the same frustrating experience when I tried to drive a manual car without driving lessons. Car kept kangarooing uncontrollably, kept stalling, keeps rolling down the hill unless I press one of those metal things near my feet...

mrmonkeyman 6y ago

The title computer scientist is meaningless here. These are engineering tools, not academic abstractions. It's akin to an architect complaining about the state of drill bits or carpentry tooling. You need experience. Is that hard to grasp? You cannot lay a tile floor neatly the first time either.

fit2rule 6y ago

I just don't use Javascript, for precisely this reason, ever. Nothing is worth the hassle - no fancy libs to do spacing, or anything. This is not progress - as someone who has been professionally programming for 30+years, this state of affairs is atrocious. Its the equivalent of buying a 5-bedroom house for your kids to grow up in, only to go in to your kids room after 20 years and realise they are insane and should be committed.

gfxgirl 6y ago
It could be worse. I could be any other language / dev env. Trying getting a C or C++ open GL app to compile. the first hits are often 20+ years old NeHe tutorials. Every few years the libraries change, the dev environments change, and unless you're already an expert in them you have no idea what you need to change in the project to get them working again. I've run into this issue in every language. Nothing special about Javascript here.
- fit2rule 6y ago
  20 years later, I can still write an SDL app using just the SDL repo and my C compiler, with GL features and all the other bells and whistles that made me choose SDL in the first place. Its there, it builds, it runs. There isn't a single Javascript project I've done in the last 10 years that I can return to and run again - they've all been borked by the eco-system. I dread the idea of even opening a package.json file to see what's wrong...
  - Gibbon1 6y ago
    Couple of weeks ago had a customer cross compile a project written in C. That was last compiled 8 years ago. Compiled perfectly with gcc 9.2
  - ptx 6y ago
    Try targeting Windows Script Host (i.e. cscript.exe) for your next project - it's still there and mostly unchanged since Windows 98. :) The language supported is ECMAScript 3 with some minor COM-related quirks, but with a few utility functions it's not too bad for simple scripts.

jacobedawson 6y ago

"Lo and behold, a pile of unnecessary error conditions, cryptic errors, and lack of proper feedback.". Sounds like literally every initial experience I've had with a new language / library / framework (also, life in general tbh). Usually reduced by RTFM.

zapf 6y ago

I have done close to a decade of work in js, with jQuery in 2008, all the way to react and webpacker madness. I hope someone builds a wasm based front end framework. I did a quick search and MSFT seem to be on it with their Blazor framework. Unfortunately, I am not in a hurry to go learn ASP.NET or C# anytime soon. Maybe we need a frontend framework in Golang that compiles to WebAssembly. I am rooting for Golang here, cause after a decade in Ruby/Python/JS, I am really enjoying going back to typed languages. But even a python/ruby to wasm web frontend framework will be awesome. Anything that keeps me away from node hell.

onion2k 6y ago
WASM compiles to what is effectively a normal JS library that exports some functions. You don't need a bundler to use that in an app, but as the complexity grows you might want one. It's likely that WASM frameworks will make that a simple process, but it'll probably end up working by using something like Webpack behind the scenes just as things like create-react-app do now. Take a look at https://rustwasm.github.io/docs/wasm-pack/ https://rustwasm.github.io/docs/wasm-pack/ for an example of what people are working on to do this. wasmbyexample has an example of how you can do it in Go right now - https://wasmbyexample.dev/examples/hello-world/hello-world.go.en-us.html https://wasmbyexample.dev/examples/hello-world/hello-world.g... - you'll need to write that index.js file yourself, and that's when you'll be back to using modern JS tooling as soon as you scale up to a real app.
- zapf 6y ago
  Thanks for those links. I found them really educational. Does seem like we need some more tooling to avoid as much webpack pain as we can.

irrational 6y ago

So, this doesn't seem to be an issue with JavaScript per se. The issue seems to be with the insane environment people have built up around JavaScript. Typescript, node.js, npm, etc. If the code really had been plain vanilla JavaScript that a person could use from an external JS file (just like we did for 20 years) then none of this would have happened.

root_axis 6y ago

All the hand-wringing over the difficulties of js just doesn't seem to track with the reality I live every day. I've been hiring engineers for years and by far the most common skillset comes in the form of contemporary js framework knowledge, especially among juniors. Ask them to debug a native app build and they panic like the output on the screen is hieroglyphics instead of a log of useful information that they can leverage to solve their problem. Many times they're so confused they won't even google the errors because they can't distinguish the error text from the compiler info logs, and that's working with swift/kotlin, I can't even imagine what things would be like if we had any c or cpp projects. This stuff just isn't that hard.

brailsafe 6y ago
I can't really tell what you're getting at here. It would definitely track that your juniors know only this stuff, because often times that's all they've been exposed to and usually for a specific type of labour. It's not really generalized knowledge. It's also not difficult, but it's not trivial to explain or get started with, unless of course you're starting at the highest level and glossing over the details. It arguably should be, and at one point it was very trivial.
- root_axis 6y ago
  > it would definitely track that your juniors know only this stuff It doesn't track with the narrative that it's difficult to get started with, in fact, it shows that the opposite is true since these skills are very common among novices. Native application development is much more challenging learning curve for novices. >details. It arguably should be, and at one point it was very trivial. Create-react-app and similar tooling make things very trivial, but the suggestion that things were trivial "at one point" and no longer so is obviously false since whatever trivialities you're referring to work just fine today as they did in 1998.

aabbcc1241 6y ago

As it has .js extension, beside typescript, it maybe flow.js script that require babel transpilation as well.

self_awareness 6y ago

No offense to anyone, but this image wraps up how JavaScript, HTML and CSS looks from my (outsider's) perspective: https://www.desktopbackground.org/download/1280x1024/2013/02/25/536059_cat-riding-fire-breathing-unicorn-photos-for-desktop_1680x1050_h.jpg https://www.desktopbackground.org/download/1280x1024/2013/02...

tiborsaas 6y ago

I had very similar experiences with Rust and C++ lately. In Rust, all I wanted is to play an audio file... failed. In C++ all I wanted is to play an MP3 file... failed. With an hours of work I figured out how resources worked in Visual Studio and got a WAV file playing. In Rust I installed a creative coding crate, it had 314 dependencies and the deps folder was 540MB. My openframeworks C++ project is 1.6GB after a bit of playing around in it :) But yeah, node_modules is heavy. Bottom line is, when you are new to an environment and you aren't prepared to fight a battle, you will bleed out quite fast.

canada_dry 6y ago
Python... subprocess.Popen(['cvlc','--play-and-exit','{filename_here}']) (just being cheeky)

jaylossless 6y ago

True...Story.

deleted 6y ago

[deleted]

warpspin 6y ago

I can sympathize with that. Actually I miss the times where you could just drop a script into your project and have it work and still change it if necessary without having 40MB of build time dependencies.

oweiler 6y ago

The most ridiculous thing is the guy in the comment section recommending deno.js.

jaeming 6y ago

Seems like the issue here was a lack of documentation. Almost every npm package worth their salt details the various ways to get started with something along these lines: - In the Browser: - Using Parcel/Webpack/Rollup.js...etc - From a CDN - In Node: - Using CommonJS - `const funcName = require('somePackage')` - Using Native ES Modules ...etc

z3t4 6y ago

The JavaScript ecosystem was perfect before 2015. Everything just worked! Then either Hanlon's razor or sabotage. Instead of using the existing standard module system, a new module system was invented that was so alien to the JS ecosystem that now 5 years later it's still broken. I wish ES6 modules where reverted and removed from the JS standard. Then the standard body not only completely changed the syntax of the language itself, but it also now requires a preprocessor/transpiler...