[HN Gopher] The JavaScript ecosystem is delightfully weird
___________________________________________________________________
The JavaScript ecosystem is delightfully weird
Author : todsacerdoti
Score : 130 points
Date : 2023-05-11 10:38 UTC (12 hours ago)
(HTM) web link (fly.io)
(TXT) w3m dump (fly.io)
| crooked-v wrote:
| Weird? Absolutely.
|
| Delightful? Try managing a monorepo with internal dependencies
| and multiple target platforms and you will immediately and firmly
| say 'no'.
| artyom wrote:
| I moved away from JavaScript because of the same reason I moved
| away from PHP.
|
| An originally decent idea gone terribly wrong.
| reidjs wrote:
| How do you build web applications?
| sodapopcan wrote:
| There are plenty of ways these days to build rich web
| applications without writing much JS. LiveView, Hotwire,
| Reactor, LiveWire, Blazor...
| artyom wrote:
| I don't. I build backend services now.
|
| But to be fair, I still maintain a relatively popular Chrome
| extension in old-school JS and that's still a pleasure to
| work with.
| isanjay wrote:
| IMHO JavaScript is neither a good OOP language not a good
| Functional language.
| artyom wrote:
| Unfortunately I think the opposite. JS was a great prototype-
| based language, but very few understood those and tried to
| fit it into functional or OOP mindsets.
|
| When they started talks about adding classes to the spec I
| knew I had to run away.
| 0x457 wrote:
| Well, then you don't think the opposite. JS is a bad OOP or
| functional language, but a good prototype-based language.
| Bad thing that no one wants such language.
| yamtaddle wrote:
| > JS was a great prototype-based language
|
| Maybe it's just me, but everything distinctive about
| prototypal OO falls firmly in the category of "please never
| actually use this in a codebase I have to work in".
| ElfinTrousers wrote:
| That would be a polite way to put it yes.
| qazxcvbnm wrote:
| Many other comments have touched upon other unusual aspects of
| the Javascript ecosystem, but there's another major aspect in the
| ecosystem at quite a precarious position, yet of which, I see
| very little discussion on, namely, the debugger.
|
| Chrome DevTools is the de facto debugger of Javascript, which
| becomes apparent once I have to take advantage of Javascript's
| capability of moving beyond the browser, on alternate runtimes.
| To debug node.js for the server and Hermes for my apps, in both
| cases I need to use the Chrome DevTools debugger which uses the
| Chrome Debugger Protocol. In the case of Hermes, the Chrome
| DevTools that comes with React Native doesn't even come from your
| local copy of Devtools, but is dynamically loaded from
| https://chrome-devtools-frontend.appspot.com/.
|
| As far as being a protocol goes, I have yet to see another viable
| implementation of a Javascript debugger. To profile my
| performance or check my memory usage, I need to use Chrome. Even
| worse, both node.js and Hermes have strange issues pop up with
| the debugger connected. In the case of Hermes, it is acknowledged
| that the Javascript runtime is not fully compatible with Chrome
| DevTools Protocol, whereas node.js occasionally exhibits
| segmentation faults with the debugger connected, or falls into
| non-terminating computation when connected to certain complicated
| programs (such as npm...)
|
| It worries me greatly that to debug my code, not only must I have
| Chrome installed, but I must be connected to Internet and trust
| that some particular domain, controlled by presumably Google,
| maintains it. I struggle to understand why no alternative
| debugger for arguably the world's most popular language exists,
| or at least a local, independent copy of the debugger that is
| untethered to the whims and desires of an entity as trustworthy
| as Google.
|
| I guess I'll be having to whip up at least the latter option
| (which seems feasible enough, if a little tedious; with ungoogled
| versions of Chromium available by some kind souls as a starting
| point) when have a bit more spare time, to keep my sanity
| checked.
| ntonozzi wrote:
| WebStorm and VSCode both have OK debuggers, but in my
| experience they are even more finicky than the Chrome one,
| which as you noted does have issues. Firefox and Safari are
| likewise fine, but not as good as Chrome.
|
| More importantly though, if you are that distrustful of Chrome,
| you probably should not be using Node because it is based on
| v8, the Chrome Javascript runtime.
| qazxcvbnm wrote:
| There are basic things to be desired with the current state
| of affairs, beyond the trust of Google, such as:
|
| 1) ability to debug locally, without an Internet connection.
|
| 2) ability to debug reliably, without fear of debugger
| features becoming 'updated' when one needs it most.
|
| The fact that no independent debugger, without the Leviathan
| that is Chrome, exists, only hides this aspect even more,
| hardly doing justice to the importance of debugging in the
| practice of software.
|
| Regards to the Firefox and Safari debuggers, they do not seem
| to be viable in practice with the alternative Javascript
| runtimes mentioned, both very popular and widely used, which
| is the reason that I claim Chrome DevTools to be the de facto
| 'Javascript debugger'. Neither do the two tools offer a
| debugger independent of the browser, as far as I am aware.
| ntonozzi wrote:
| Have you tried VS Code or WebStorm? They are both
| independent debuggers. They are quite good for debugging in
| my experience. I don't know that they offer profiling
| capabilities.
| sequoia wrote:
| @qazxcvbnm I don't understand: you don't want to use the
| chrome debugger but also don't want to use an IDE
| debugger... it's not clear what would meet your needs and
| wants, you're rejecting all the main options.
|
| Here's an overview of some of the tools in case that's
| useful: https://sequoia.makes.software/debugging-nodejs-
| talk/#55
| qazxcvbnm wrote:
| I reject the main options for the reason that the main
| options are unsatisfactory.
|
| Your link lists the Chrome debugger, IDE debuggers, and
| the node inspector.
|
| The node inspector is essentially deprecated. IDE
| debuggers more or less piggyback on the Chrome DevTools
| protocol, and although I mentioned I have not given them
| a fair try, but they definitely seem less official,
| featureful, and well-supported compared to the Chrome
| debugger. The fact is, this aspect of Javascript seems to
| have, unceremoniously, already fallen into Google's sole
| leadership, direction, and discretion, by force or by
| will.
|
| The Chrome debugger, as mentioned, exists and is probably
| the most well supported of all debuggers, and is what I
| use in practice. However, as I mentioned, even 'the
| best', which is Chrome, does not work very well, exhibits
| usability regressions per the cadence of Google (e.g.
| blackboxing used to work, but is very broken today), and
| moreover compromises basic functionality and freedoms,
| which comprises my dissatisfaction.
|
| In a better world, we would have something that is native
| to the language (not a browser), versionable, free,
| featureful (e.g. profiling and memory debugging), and
| accessible from the shell (e.g. other languages have gdb,
| pdb). It would be a good thing for a protocol to actually
| have multiple implementations.
|
| Something that may at least recover basic functionality
| from the Chrome DevTools would be to degoogle it for
| hermetic usage, and separate it from the browser proper.
| As I mentioned, I am looking forward to make that happen.
| qazxcvbnm wrote:
| I confess that such IDEs and their plugins are not my cup
| of tea and have not given them a fair chance. Though I am
| skeptical, with the many inconsistencies that runtimes
| present even for Chrome, perhaps they do work and I may
| give them a fair try.
|
| Still, unwilling tight coupling with an IDE is still
| quite unsatisfactory.
| WorldMaker wrote:
| I think Firefox's debugger is still extremely viable for web
| development. The Firefox Developer Edition even puts the Dev
| Tools nicely at hand in the toolbar and other places.
|
| It can't help enough with Node or Hermes, but those are too
| tied to v8 and thus Chromium internals to start with. (Which
| definitely leaves some questions about the current JS
| monoculture.)
| VyseofArcadia wrote:
| I wonder how much of this can be blamed on JS being a relatively
| gentle and forgiving codegen target.
| brundolf wrote:
| I think what makes it a popular codegen target has more to do
| with
|
| - The places it can run
|
| - The ecosystem it can interop with
|
| Not that it's a bad codegen target otherwise- it's high-level
| but performant for being so high-level, it's garbage collected,
| first-class functions, low-level primitives are available for
| optimizations, etc. But these on their own don't make it super
| unique
| ragnese wrote:
| How is it a better codegen target than any other language?
| That's not intended with an argumentative tone- I'm genuinely
| curious as to what you mean.
| VyseofArcadia wrote:
| It's only a half-informed thought. I work on a project that
| compiles a domain specific language to C and C++. When I
| think about JavaScript as a codegen target, all I can see is
| all the problems I wouldn't have.
| anon291 wrote:
| Javascript benefits from the major efforts put into its JITs.
| No other scripting language really has that.
| marcosdumay wrote:
| Hum... A lot of people is working on JS codegen, so there are
| all kinds of knowledge bases, libraries, and standards for
| it. Also, JS itself got some changes to support it better.
|
| So, yeah, it's a better target than most general purpose
| languages. It's surprisingly simple to generate, much simpler
| than to write on. It is also a worse target than most
| languages specialized on being generated.
| ElfinTrousers wrote:
| I suspect that if some accidents of history hadn't left JS as
| the only language you can use to script a Web browser, it would
| have died off long ago.
| VyseofArcadia wrote:
| I've been wondering about that lately. What is the rationale
| for making it necessary to run WASM binaries through
| JavaScript? Seems like a missed opportunity to not be able to
| just point a script element at a WASM blob, but I'm sure I'm
| overlooking something.
| wolpoli wrote:
| Google already tried the blob with Native Client, but I
| recall Firefox decided not to support it.
| marcosdumay wrote:
| It is one of the many things being worked on. The truth is
| that no part of the web standard bodies has WASM as a
| priority, so it moves slowly.
|
| Anyway, on practice all that means is a bit of lost
| performance on the DOM interaction. It's a big deal if you
| do a react-like framework, but the DOM has bad performance
| anyway, so people tend to not create react-like frameworks.
| dunham wrote:
| When I last looked, it seemed like WASM blobs just take
| arrays of numbers and return arrays of numbers. No objects,
| strings, or DOM elements, so I think it'd be tough to do
| web dev in wasm as it stands. And you need javascript glue
| if you want anything in the way of side effects.
|
| There is, however, quite a bit you can do in it. TeX has
| been compiled to wasm[1], it's about 600kb uncompressed 90k
| compressed (the memory image with latex loaded is about 6MB
| compressed though - latex is a beast). I think anything
| computationally intensive would be a good candidate for
| wasm (it has int64).
|
| 1: https://github.com/kisonecat/web2js
| VyseofArcadia wrote:
| Right, yes, that's how WASM is now, but what I'm asking
| is why didn't we give WASM access to the DOM? We could
| have, and we just didn't.
| dunham wrote:
| Sounds good to me, I was disappointed when I learned that
| wasm didn't do this already. (It'd be nice to have tail
| call optimization too.)
| NoMoreNicksLeft wrote:
| What else was there, besides VBscript, or whatever Microsoft
| was calling it then? Even if we're only talking
| hypotheticals, at what point would anyone have attempted to
| release an alternative?
|
| Everything was mucked up well into the 2010s with everyone
| chasing IE compatibility. And not even 3 years later, Chrome
| had taken over the world. That's a really brief window for
| anything to happen.
| VyseofArcadia wrote:
| What else was there? Plenty of stuff! It could have been a
| lisp, it could have been a flavor of pascal, python was
| around even if it wasn't popular yet. Thank heavens we
| didn't end up with a flavor of BASIC, although as you point
| out it could have happened.
| hnal943 wrote:
| js is pretty lispy. Crockford is pretty compelling that
| the reason js survived (and beat Java which was the heir
| apparent) is because of the attributes it inherited from
| Scheme.
| hnal943 wrote:
| The idea at the turn of the century is that Java Applets
| would be the way web applications would be developed. That
| was a disaster for security, ux, etc.
| hnal943 wrote:
| I don't think that's true. I find Crockford's argument
| compelling that js is misunderstood and that the core of the
| language is a diamond in the rough.
|
| https://youtu.be/47Ceot8yqeI?list=PL7664379246A246CB&t=3792
| cout wrote:
| I want to disagree, but I think you are right. Java and Flash
| were the only alternatives to javascript that ever gained a
| foothold, and both of them were second class citizens. Circa
| 2001 I tried to use Java to interact with the DOM and ran
| into a browser bug that iirc took about a decade to fix. If
| the technology had ever been usable things might have turned
| out differently (or it might have turned out the same, who
| knows).
| koito17 wrote:
| > When a bundler/transpiler encounters an import statement, they
| don't necessarily presume that the file being imported is
| JavaScript or even any of the variants mentioned above. If
| configured properly and you want to import a CSS or PNG file, it
| will happily do so for you.
|
| This is what I like to nickname "WebpackJS". Code that is simply
| invalid JavaScript and requires a carefully configured
| composition of webpack plugins in order to be used. I
| occasionally run into npm packages wanting to "import" a CSS file
| when I use them from ClojureScript, and it's always a pain. The
| good news is that these ar rare encounters, but it's still
| behavior enabled by people assuming you're using the exact same
| framework as them with the exact same Webpack configuration made
| by said framework.
| boucher wrote:
| I think there's a small but growing group of people in the JS
| ecosystem that are beginning to explore a more "platform native"
| approach to front-end development, which removes the need for
| bundlers and transpilers and embraces the fairly capable feature
| set of most modern browsers.
|
| As the OP points out, a lot of what happens now is an artifact of
| the history of how these things have developed, and about which
| things were prioritized over the years. Many of these choices
| made sense at the time but may no longer be necessary, and some
| things were definitely lost in the process.
|
| When we were developing Cappuccino, which includes its own
| transpiled to JS language (possibly the first such general
| purpose language), one of our important goals was making sure the
| compiler could run in the browser itself so no external build
| tools were needed; everything worked just dragging index.html in
| the browser and writing code in <script> tags if you wanted.
| Security changes in how browsers handle file: URLs made this
| harder to do, but anything that simplifies the process of
| actually running code is very welcome.
| philsnow wrote:
| I appreciate the summary of the changes in the javascript
| ecosystem over the last decade+; all of that happened _after_ I
| had kids and I didn 't have the motivation to keep up with it, so
| it's a complete blur in my mind.
|
| I've tried at various times to get caught up, but it seems that
| every time I find articles / blogs that talk about How Things Are
| Done at the time they're written, with only the briefest nod to
| how it's better than The Old Busted Way (probably because the
| authors, being steeped in and surrounded by javascript for years,
| think that their readers will also be similarly up to speed).
|
| Meanwhile, I feel like a historian in the year 5000, reading
| recipes from 2023 and wondering whether people used dog milk or
| cat milk (because those were the two kinds of mammals that most
| households had available).
|
| Does anybody know of other resources that go into more depth on
| the evolution (and specifically the Whys) of the javascript
| ecosystem?
| yCombLinks wrote:
| "Modern Javascript for the Impatient" does a good job for the
| language itself. It doesn't try building on non-existent prior
| knowledge. It assumes you program, but in other languages.
| chrismorgan wrote:
| > _deliberately misuses the JavaScript label syntax_
|
| Eh, deliberately _repurposes_. I don't think "misuses" is the
| right word at all.
|
| > _abuse of the bundler_
|
| This also feels too strong a wording--though the fact that these
| are at least .js files (unlike .svelte files in the other case)
| makes the term "abuse" less unreasonable.
| harha_ wrote:
| I can't help but cringe when looking at the dependency count when
| using some javascript framework to write client-side code. I
| think the frameworks and the ecosystem is overly complex and the
| same could be accomplished by embracing minimalism. I do like
| things such as babel and webpack though, but those are dev-
| dependencies which is unrelated to the contents of the final
| bundle and I can live with few dev dependencies.
|
| For my last project I wrote just plain old javascript without any
| frameworks, but I did use dev dependencies such as the ones I
| mentioned above. It was a breeze to implement things, but I do
| understand that the benefits of frameworks like React become
| clear in larger more complex projects. So all in all I don't
| really know what should I think about the current state of the
| ecosystem, nor am I really on the edge of the wave of progress,
| but the kind of feelings I often get is in the lines of 'is this
| dependency x really needed here? what does it do? oh it does this
| small little thing, why is it here??'...
| ipaddr wrote:
| Wish we had something simple like jQuery
| Etheryte wrote:
| I mean you can still use jQuery, no one's stopping you.
| They're still releasing new versions with updates, the last
| one came out two months ago if I'm not mistaken.
| potta_coffee wrote:
| Vanilla Javascript is comfortable. I think I've pretty much
| given up on the JS ecosystem. I've been going back to web
| frameworks like Django / Rails / Laravel. Obviously not the
| solution for all things but most projects really don't need to
| be SPAs.
| ilrwbwrkhv wrote:
| Just use mithril
| toastal wrote:
| The JS ecosystem also relies on npm, which is owned by Microsoft.
| Having a corporation control package management is pretty
| _weird_.
| wetpaws wrote:
| Something something pnpm, yarn, jfrog
| toastal wrote:
| I believe they don't have registry or independent mirrors.
| Which CLI tool isn't that important.
| earthboundkid wrote:
| Well, now that Microsoft has embraced and extended open source,
| I think it's time for us all to let our guards down, because
| it's not like they have some kind of "third step" to their
| business plans.
| breckenedge wrote:
| So JS is delightful because we are still not actually writing JS,
| but stuff that looks like JS? Huh.
| zaphar wrote:
| That is not what the author said. They said the JS _Ecosystem_
| was delightful. He then goes on to describe that Ecosystem. For
| some people that ecosystem is indeed delightful. They love the
| sheer complexity it takes to deploy a JS application these
| days. There is certainly a lot of choice and power out there
| for it.
|
| I personally am the kind of person who tries to ship my stuff
| as a single statically linked binary that I can just drop in
| place so I look as WebAssembly as a way to participate in the
| browser ecosystem while avoiding the whole NPM/JS Tower of
| development tooling complexity. I don't begrudge others from
| wanting to play there though.
| krapp wrote:
| It's weird how JS is the only ecosystem entirely designed
| around the premise of avoiding direct contact with the language
| you're developing in at all costs.
|
| Like, even C programmers are willing to actually write C.
| WorldMaker wrote:
| The C macro language is technically a different language
| (though today they are specified together, they originated
| once as different compiler tools) than C and _lot_ of DSLs
| get written in it because C programmers are trying to avoid
| actually writing C.
|
| There's also a lot of C programmers that prefer to use C++
| compilers in C++ mode for their C code to avoid direct
| contact with C specification bugs or some C standard
| libraries.
|
| (Plus, early C itself was designed to avoid direct contact
| with Assembly languages which was designed to avoid direct
| contact with Machine languages some of which were designed to
| avoid direct contact with Microcode languages most of which
| were designed to avoid direct contact with TTL logic and TTL
| logic was designed to avoid direct contact with the useful
| properties of transistors for computation and so forth.
| Programming is turtles all the way down.)
|
| (Also there are quibbles to be made about "at all costs". JSX
| is still a superset of JS syntax with a little bit extra
| added in. Typescript is built to be a superset of JS syntax.
| You can't write _either_ without a lot of direct contact with
| JS. Neither seems like "at all costs" avoidance to me.)
| spicebox wrote:
| Rust has a far more powerful and widely used macro system
| then JS but I don't think that means rust devs are trying to
| avoid writing rust at all costs
| ghusto wrote:
| > Nobody Writes JavaScript Any More
|
| This is how "delightful" it is, and is the reason I'm waiting for
| it to die.
|
| Every couple of years we decide on the 'no no, definitely this
| time we have it all figured out, trust us, just use X' "solution"
| to the problem of JavaScript. We have the definative 'this is how
| you do it', until the next one.
| dwaltrip wrote:
| I think this is pretty much all of programming.
|
| Or life in general.
|
| There's plenty good and plenty bad. It's no use fixating on
| things you can't change. Focus on what you _can_ do.
| superchroma wrote:
| This. It _fucking sucks_. I just waded back into it and I hate
| everything about it. VSCode barely copes, Visual Studio doesn
| 't even try and Rider was the only thing that worked which
| hasn't helped my mood.
| danielvaughn wrote:
| I don't know enough about WASM to know why it can't be exposed
| directly to the DOM, since in theory the DOM should be a
| language-agnostic interface. If that were to happen, I think
| the floodgates would really open on WASM and we'd finally start
| to see JS die.
| potta_coffee wrote:
| Javascript is not going away anytime soon, probably.
| Personally, I'm waiting for React to die.
| steve_adams_86 wrote:
| As much as I love React and it has been a positive part of my
| career, I'm starting to think there really are better
| alternatives. Its staying power may just be the sheer number
| of people supporting its ecosystem and competent enough to
| build things with it.
|
| I'm content to keep working with it, and I'm so familiar with
| it that for small tasks it's kind of my go-to. If I was
| building something I wanted to be long-live a future-
| friendly, I might be hesitant to run with React at this
| point. To be honest though, I'm not sure what's better than
| would be a clear contender for having similar staying power.
| I wouldn't complain if that turned out to be Solid.
| mathgladiator wrote:
| > I'm waiting for it to die
|
| I'm there with ya, but I wouldn't hold your breath. I'm trying
| to minimize my JavaScript exposure by using streaming, and it's
| going well enough with a minimal JavaScript "runtime". However,
| I still find myself with thorny edge cases like "I need a
| better date/time picker", "color picker", or a drag and drop
| calendar planner.
|
| I find myself frustrated with the ecosystem, and I'm debating
| how large the set of exceptions are to my ideology.
| leptons wrote:
| The only real problem with Javascript is people's lack of
| understanding of it - _and it 's not even that difficult_.
| fulafel wrote:
| Good article. There's of course editorial decisions about what to
| mention but still the in the Nobody part the JS-as-compile-target
| coverage seems a bit selective. There's of course ClojureScript,
| Elm, Scala.js, ReScript and TypeScript (the latter is mentioned
| in passing).
| weeksie wrote:
| Javascript is this generation's C++. It's a massive language and
| the only way to stay sane on a project is to agree to use a well
| demarcated subset of it.
|
| Nothing wrong with being C++. The reason JS is so massive and
| weird is because it's the language that everybody uses, or has to
| use at some point. Upsides and downsides.
| miohtama wrote:
| JavaScript, The Good Parts by Douglas Crockford symbolises this
| well today
|
| https://www.reddit.com/r/ProgrammerHumor/comments/621qrt/jav...
| pcthrowaway wrote:
| Javascript, The Good Parts, is not really relevant to today's
| Javascript, unless it's been refreshed. I remember working
| through it 10+ years ago:
|
| * `var` is no longer a thing.
|
| * Even `let` is less common now.
|
| * Using closures and prototypes to enable functions to be
| used like classes and have private variables and static
| variables, have been replaced with proper classes
|
| Nowadays if you want to use the good parts of Javascript,
| just install eslint with insane defaults and let it tell you
| if you're trying to use the non-good parts
| miohtama wrote:
| The joke is about the size of the books in the photo, not
| about JavaScript features.
| andirk wrote:
| It's mostly outdated now, thank goodness, but anyone born
| after 1990 should read it cover to cover to appreciate the
| current state of JS and why we got here. hasOwnProperty??
| Lol
|
| Looking at the book now, I still like some sections like
| "Curry" and "Memoization".
| leptons wrote:
| Sorry, but var is absolutely still a thing. It has plenty
| of valid use cases and sometimes using let just needlessly
| complicates the code.
| capableweb wrote:
| Surprise surprise, class syntax is basically just syntactic
| sugar on top of prototypes, and they essentially work the
| same way, besides bring able to have private members (which
| seems like a anti-pattern anyways).
|
| You'll able to accomplish exactly the same with both, so
| why create yet another way? Seems bit wasteful..
| WorldMaker wrote:
| The syntax sugar paves a "garden path" for the common
| experience to be the best experience. It encodes "best
| practices" from previous prototype-based code,
| _including_ private members. (They were always possible
| /always existed [as closures inside a constructor
| function, among even wilder solutions], but the patterns
| for building and using them was all over the map. It is
| nice to have standards now over a lot of ad hoc
| solutions.) I don't think it is wasteful, because it
| saves you from having to read books like "JS: The Good
| Parts" and hunt around for the right toolkit or design
| pattern to do the right things easily.
| pcthrowaway wrote:
| You could always create private members with closures.
| tdba wrote:
| _> just install eslint with insane defaults_
|
| where do I find these insane defaults?
| pcthrowaway wrote:
| lol, that was a typo, should have said "the sane
| defaults"
|
| On the other hand, it's a testament to the comment being
| written (or at least edited) by a human, and not an LLM
| right?
| von_lohengramm wrote:
| There used to be a lot of nice default packages, but I'm
| not aware of any actively maintained ones (other than
| "company X's config"). So instead...
|
| First, find the docs for ESLint and each of the
| integration packages that you've installed for each major
| dependency. Then just set each rule to the strictest
| setting. Then as you're developing, you'll start running
| into overzealous rules, prompting you to either disable
| the rule or write some override/exception.
|
| TSConfig, on the other hand, isn't extensible so you can
| just throw a couple configs from
| github.com/tsconfig/bases in your `"extends": [...]`. The
| base config `@tsconfig/strictest` might be of interest to
| you.
| danwee wrote:
| For me:
|
| JavaScript === C
|
| TypeScrit === C++
|
| You can shoot yourself in the foot writing vanilla JavaScript.
| There should be a book "TypeScript: The Good Parts" though: the
| language brings a lot of stuff that is better not to use.
| tln wrote:
| Are you talking about JS the language, or the ecosystem?
|
| JS as a language isn't nearly as big as C++ or, say, Swift...
| I'd say Python complexity is on par or even higher than JS, in
| terms of core language features.
|
| There are some language features that are outdated but it's
| hardly like the C++ situation.
| teichmann wrote:
| ECMAScript Language Specification 13th Edition / June 2022
| (846 pages): https://www.ecma-international.org/wp-
| content/uploads/ECMA-2...
|
| Working Draft, Standard for Programming Language C++ from
| 2020-01-14 (1815 pages): https://www.open-
| std.org/jtc1/sc22/wg21/docs/papers/2020/n48...
|
| I'm not sure what's the "correct" spec for the current C++
| standard is. Still a big difference between these languages,
| but 846 pages isn't exactly small either.
| von_lohengramm wrote:
| To be fair, _so much_ of the C++ standard is literally just
| being explicit about what the standard does _not_ define
| and often _who_ defines it instead. But to be fair, it
| would probably be entirely reasonable to categorize that as
| essential language knowledge and a "part of the language."
|
| Meanwhile, the ECMAScript spec really does not leave very
| much wiggle room. It (like every other web standard) is
| almost just documentation or often even pseudocode-
| ification of an actual implementation... Certainly makes
| you think.
| akiselev wrote:
| Random committee draft of the C spec from 2007 (552 pages):
| https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
|
| Intel 64 and IA-32 Architectures Software Developer's
| Manual, Volume 2 Instruction Set Reference (2552 pages!!!):
| https://cdrdv2-public.intel.com/774492/325383-sdm-
| vol-2abcd....
|
| The ECMAScript language spec is closer to the C spec than
| the C++ spec, by a large margin. I'm not sure how much you
| can deduce about relative complexity from these figures.
| andirk wrote:
| I agree JS spec is like C, whereas some JS frameworks
| like Typescript are more like C++ where it's 100% using
| JS but w/ brevity to the end user. Think:
|
| Note: I'm a moderate JS dev so correct me if I'm wrong.
| josephg wrote:
| There are far more ways to write javascript than any of us
| want.
|
| For objects with methods you can make literals, use a
| constructor with new and have prototype methods, use a class,
| or use Object.extend, or Object.create or probably other
| tricks.
|
| For async code we have callbacks or promises. And promises
| can just use the Promise class and .then(), or you can use
| async / await. And the promise class also has polyfills in
| npm if you want that instead. Or there's tricks with
| generators.
|
| Functions can be written with function foo(), or const foo =
| function(), or const foo = () => {...}. Or const container =
| { foo() {} }. Or use class methods (which have different
| syntax again).
|
| Importing external code can use commonjs (require()). Or
| import statements. Or dynamic import. In the browser you can
| use multiple script tags and have scripts assign their
| library to a global object. In nodejs code can also change
| what require does.
|
| I can keep going - don't even get me started on bundlers.
| You're probably right - the language probably still isn't as
| big as C++. But it's big enough that almost nobody knows
| every javascript feature. I was around in the early days of
| nodejs (0.4 was my first version). At the time the design of
| the language, and of nodejs, seemed simple, clear and
| cohesive. Don't get me wrong - I love a lot of the newer
| features. But javascript as a language feels like a bit of a
| bloated mess.
| riceart wrote:
| There's a 300 page book out there on on _just_ initializers
| in C++.
|
| > There are far more ways to write javascript than any of
| us want.
|
| Some of the examples you cite are due to JavaScript being
| minimalist though. For object creation there are a few
| different syntactic methods but it is straightforward how
| they compare semantically - they are basically equivalent.
| C++ has numerous methods to do similar things but they each
| have their own numerous rules and exceptions. Ironically in
| C++ there is often only one way to do something a certain
| way, as a similar syntax for initialization may (not will)
| do something completely different depending on external
| context - such as merely putting parens around a set of
| braces.
|
| The diagnostic output of the compilers alone when you
| misplace a symbol is longer than many JavaScript libraries.
|
| > But it's big enough that almost nobody knows every
| javascript feature.
|
| I don't think this is true. It just isn't that big of a
| language. The examples given certainly don't paint a
| picture of immense complexity - a few things have accreted
| during the years, it's not outside of simply just learning
| them in a few weeks.
|
| It's not just about the length of the spec (which is much
| shorter) but the complexity of those specified features
| within the system as a whole - JS as a system just isn't
| relatively that complex.
|
| > the language probably still isn't as big as C++.
|
| For anybody that does modern C++ and JavaScript
| professionally (as opposed to those that are content
| continuing to write C++ like it's CFront) this is a coffee
| spitting understatement.
| ilyt wrote:
| JS is far smaller language than C++. You don't need to agree on
| common part of _language_ , it's the rest of the ecosystem
| around that's the problem as you "need" a lot just to fix JS
| deficiencies
| weeksie wrote:
| Yes.
| throw_m239339 wrote:
| > Javascript is this generation's C++. It's a massive language
| and the only way to stay sane on a project is to agree to use a
| well demarcated subset of it.
|
| No, it's not massive compared to C++, it's actually quite
| simple. No explicit pointer management, no memory management,
| no user defined operator overloading and so on and so forth.
| The only difference between classes and function prototypes
| AFAIK is "super" late binding, otherwise one can replace
| classes with functions everywhere they want.
|
| The problem isn't javascript itself, it's the different
| runtimes that have different API. But the javascript spec is
| tiny compared to C++.
|
| As for the ecosystem, it's mostly node's that is a mess, as the
| result of core Node API being barebone. Browser API are
| actually quite extensive and do a lot of stuff, from shaders to
| XML parsing to sound generation, but this isn't javascript it's
| the DOM/Browser API.
| junon wrote:
| Coffeescript was well before "tree shaking" (the JS ecosystem's
| way of spelling "dead code removal") and code splitting, both
| being relatively new things in the bundler world ("tree shaking"
| being introduced with rollup if memory serves). Then came Acorn,
| which gave way to a whole slew of JS transformation bits.
|
| It also didn't help that Node was fixed at 0.12 for years and
| years, and we had the IO.js fork until Node was released by
| Joyent for OSS community members to take over. That caused more
| issues to boot.
|
| Also the whole bundling fiasco started with Babel, which wasn't a
| bundler at all and instead started as a means to provide
| polyfills for supporting "old browsers" (really, IE). From that
| whole thing came the concept of "evergreen browsers" which is a
| term that has largely fallen out of the common vocabulary with
| the rise of Edge.
|
| Now we have "anything is a valid feature request" TC-39, and
| "it's really just Google at this point" browsers dictating how
| the web works.
|
| It's a nightmare. As a maintainer of several large JS packages,
| and being so dreadfully burnt out on JS, there are other words
| I'd use to describe the whole thing than "delightful".
| polishdude20 wrote:
| I feel like this is a normal thing for any language that
| becomes this ubiquitous. Python, C++ , Haskell, Java don't run
| in the browser the way JavaScript does. They don't have the
| same requirements that the JavaScript ecosystem does.
| WA wrote:
| So, what language/ecosystem do you prefer nowadays if you were
| free to choose?
| junon wrote:
| I firmly believe Rust is the future.
| Scarbutt wrote:
| For web apps is just Javascript. And since you are forced to
| use it, why not run it on the server too and use less
| programing languages? Not a fan, but it is what it is.
| chrismorgan wrote:
| > _" tree shaking" (the JS ecosystem's way of spelling "dead
| code removal")_
|
| I'm not altogether against giving it a different name. It's
| _very_ limited compared to what proper ahead-of-time compilers
| manage. I'd really like to see some actual effort put into
| partial evaluation and symbolic-execution-guided code
| simplification and dead code removal. Google tried something a
| little like it in Closure Compiler's advanced optimisations
| mode, many years ago, but hasn't really kept it up; and
| Facebook tried some five years ago with Prepack, but quickly
| gave up on it for unclear reasons.
| rektide wrote:
| Qwik is interesting here, very just-in-time with running JS
| on the client side.
|
| https://qwik.builder.io/docs/concepts/resumable/
| ricardobeat wrote:
| Qwik is basically more granular code splitting combined
| with a smart loader. We were already doing this ten years
| ago, just manually without a compiler.
| EMM_386 wrote:
| > As a maintainer of several large JS packages, and being so
| dreadfully burnt out on JS, there are other words I'd use to
| describe the whole thing than "delightful".
|
| My first project that used JS was in 1996, so I've been along
| the ride every step of the way. Up until today where I am
| working with all of this on an Angular 15 enterprise project.
|
| I actually _would_ describe it as delightful, compared to what
| it was like only a short 10 years ago. 1996-ES6 was painful.
|
| I understand your pain as maintainer and am also burnt out on
| ... um ... _27 years_ of JavaScript. Yikes.
|
| But now it can just be written in TypeScript and I'll let the
| transpilers and other tools handle the details.
|
| It is _so much_ better.
| yamtaddle wrote:
| The thing about JS is that it was always terrible 5-10 years
| ago, and is always "actually good now".
|
| [EDIT] Though I actually agree that it's nearly-tolerable now
| that we have TypeScript and async/await to force what always
| should have been the default behavior.
| vlovich123 wrote:
| Not sure what language you were coding in but I remember
| actively hating it 5-10 years ago and definitely didn't
| think "it's actually good now". It was always getting
| better of course, but even these days there's lots of
| problems that would prevent me from saying "it's actually
| good now".
|
| The Web APIs are pretty lacking:
|
| * WebUSB has only been available for a couple of years
|
| * WebGPU is only now becoming a thing despite the aborted
| attempt that was WebGL
|
| * Raw TCP/UDP sockets are still experimental
|
| * WASM is still struggling to solve the scaling challenges
| to make it possible to make available a large portion of
| existing software as libraries for JS to interop with
| without overhead.
|
| * WebCrypto doesn't have streaming hash support & fails to
| standardize protocols that are relatively popular (e.g.
| ED25519)
|
| From a language level, there's all sorts of footguns/edges
| that can't be fixed due to back compat and the language is
| both slow in adopting good features but also fast to adopt
| features that don't work too well or just plain annoyances
| when switching between langauges (e.g. did any/all really
| have to be unique and called some/every?).
|
| The ecosystem also has large annoying challenges with
| TypeScript being super slow to type check even small
| projects, a mess of bundlers to pick from (most of which
| are ass slow except for ESBuild and maybe SWC), linters
| (only really ESLint in the game which is slow for TS),
| formatters (prettier which is slow but thankfully there's
| now dprint), ES/CJS bifurcation that's a nightmare to
| manage, tooling that only works with very specific
| combinations of things, etc etc etc.
|
| You can usually build something passably if you know what
| you're doing but it's a mess for someone new entering the
| field and even after having spent some time in it I'm
| finding myself futzing with project settings quite a bit to
| accomplish some slightly off the beaten path combination of
| tools.
| yamtaddle wrote:
| I mean that at any time it was extremely common to see
| something like "well yes it was bad [amount of time ago],
| but now it's actually good!"
|
| Before long that "actually good" is lumped in with the
| time when it was bad... but now, of course, it's actually
| good!
| 8note wrote:
| The thing about JavaScript is lots of people are touching
| it and are innovating both in how to use it, and for
| language features.
|
| It's always getting better, and always has opportunities to
| get better
| nextaccountic wrote:
| What do you think about Deno?
| ilyt wrote:
| I wouldn't call it delightful, I'd call it diaherra
| FpUser wrote:
| >"Nobody Writes JavaScript Any More"
|
| I code single page apps that talk to business backends using JSON
| based RPC. All in plain JavaScript with some domain specific libs
| when needed. No problems so far.
| karaterobot wrote:
| I like javascript, but I always think about the time when I was
| working as a front end developer, and a guy across the room
| suddenly stood up, walked over to the white board, and wrote
| "F*CK JAVASCRIPT" in massive letters. I believe his concern was
| around the lack of type safety (this was before we used
| Typescript). And this was someone not prone to dramatic gestures.
|
| At the time I laughed. Guy must be having a bad day. Javascript
| rules, look at this widget I made.
|
| Cut to a few years later. I am fed up with React, and the entire
| javascript ecosystem in general. The trend-based, article-driven
| development, the new framework/pattern you have to learn/unlearn
| every six months, the SPAS that made a simple web app spool up
| the user's laptop fan with all the javascript it was processing
| just to do basic stuff we could do much more simply in the 90s.
|
| I ultimately quit being a developer in 2019, switched to doing
| design full time. I still write javascript for personal projects,
| because it's the thing I'm most familiar with. But, only vanilla
| javascript.
|
| Javascript rules, but also: f*ck javascript.
| ggregoire wrote:
| > I am fed up with React, and the entire javascript ecosystem
| in general. The trend-based, article-driven development, the
| new framework/pattern you have to learn/unlearn every six
| months, the SPAS that made a simple web app spool up the user's
| laptop fan with all the javascript it was processing just to do
| basic stuff we could do much more simply in the 90s.
|
| I must be living in a parallel world cause I write React &
| TypeScript code on a daily basis (among many other things,
| including writing Python and SQL too), I've done it for a few
| years now and I quite enjoy it. Last time I had to learn a new
| "pattern" was Hooks I guess, and it was like 3 years ago? I was
| hesitant at first, I didn't have any issues with class
| components... but Hooks actually increased my productivity and
| simplified my code. Otherwise I feel like coding in React
| hasn't changed much over the years. I would definitely not want
| to go back to the technologies I was using in the 2010s.
| SkyPuncher wrote:
| I always find myself coming back to react.
|
| Its so delightfully simple at its core. Typically super easy
| to debug. Extremely composable and reusable.
| leptons wrote:
| > a guy across the room suddenly stood up, walked over to the
| white board, and wrote "F*CK JAVASCRIPT" in massive letters
|
| >Guy must be having a bad day.
|
| He was having a bad day because he was doing stupid things with
| the code he wrote that led to problems. I've never had a
| problem with Javascript's type system, or having the wrong type
| show up where it shouldn't. I accepted the dynamic nature of JS
| long ago when it first came out in Netscape, and I adjusted my
| coding style accordingly. And Javascript types are not a
| mystery, type coercion is fairly simple and doesn't produce
| unexpected results if you actually understand the language. If
| you don't understand the language (or any programming
| language), then writing things like "F*CK JAVASCRIPT" in
| massive letters on a whiteboard is something that might happen.
| tstrimple wrote:
| > I've never had a problem with Javascript's type system, or
| having the wrong type show up where it shouldn't. I accepted
| the dynamic nature of JS long ago when it first came out in
| Netscape, and I adjusted my coding style accordingly
|
| Different languages have their own strengths and weaknesses
| as well as generally accepted coding practices and sometimes
| different paradigms. I find the folks who struggle the most
| are trying to write JS as if they are still a C# or Java
| developer so they constantly run into square peg round hole
| issues and blame it on the tool. I love JavaScript. I also
| love C#. But you've got to approach how you solve problems
| with them differently. How you write long term maintainable
| code in both is different.
| krapp wrote:
| Yeah, Javascript isn't even the only dynamically typed
| language out there, but you don't see people compiling
| strictly typed supersets of Python or Lisp because they
| consider those languages unusable otherwise. With any other
| language people are willing to learn the idioms and accept
| and work with the quirks, but for some reason Javascript
| alone seems to be the exception.
| schwartzworld wrote:
| Didn't python add static typing?
| selfishprick wrote:
| [flagged]
| jsdeveloper wrote:
| So what was weird exactly? react is not JS. nextjs is not js.....
| same way spring boot is not java. JS is the way it is. Most of it
| complainants has issues as they usually come from synchronose
| language and when JS (its true power) uses its async nature, they
| can't comprehend it and think its weird, why would it do so. If
| your rational is that its slow, you should probably use assembly
| to write the most optimal code. If you want a high level language
| then JS brings most paradigm than competing languages. If you
| argue to want all features high level, low level and speed go for
| C++.
| techaqua wrote:
| > nextjs is not js..... same way spring boot is not java
|
| does spring boot bring it's own dsl and compiler?
| ElectricalUnion wrote:
| Kinda, as usual within Javaland, there's a lot of reflection
| involved into making annotated interfaces (a kinda of
| standard Java reasonably limited dsl capabilities) pop up as
| singletrons connecting to your database/OLAP/LDAP/REST-
| endpoints/websocket-clients/whatever.
|
| Same thing for serialization things, you define interfaces,
| the actual classes often just pop into existence by generated
| bytecode.
|
| It's also not unknown to bring JSP/EL (literally requires a
| Java Compiler embedded in your server to compile servlet
| objects for you on the fly) or some other, on purpose less
| fully featured template things with their own DSLs like
| Thymeleaf to do the same job.
| simultsop wrote:
| I find this like saying you are actually writing binary code,
| what you code is not any language at all.
| [deleted]
| rglover wrote:
| > The mind bending parts of this presentation are where he first
| utilizes use server to implement a client side form action, and
| then later launches a client side alert from the server using use
| client. And he closes by saying that this requires new generation
| routers and new generation bundlers.
|
| No, it just requires a basic websockets implementation and a
| normal HTTP server. If anyone else like me loves JavaScript but
| thinks the above line of thinking is bananas, join me on the
| lifeboat [1].
|
| [1] https://github.com/cheatcode/joystick
| [deleted]
| AlchemistCamp wrote:
| > _Less that 10 years ago, JavaScript sucked bad. It had no
| imports, no classes, no async, no arrow functions_
|
| No classes in JS was much better than with. As someone who used
| and contributed to CoffeeScript, I was initially excited by them
| but in retrospect, they've been a huge negative IMO.
|
| Douglas Crockford saw it immediately:
| https://www.youtube.com/watch?v=PSGEjv3Tqo0&t=300s
| moron4hire wrote:
| I'm so sick of these paradigm religious wars. There's nothing
| wrong with object oriented programming. There's nothing wrong
| with functional, either. You use them for different purposes.
| These people like Crockford who talk about "Java programmers
| are stuck in this inferior way" are the ones who are stuck and
| not all that educated on programming.
| lobstrosity420 wrote:
| They weren't criticizing OOP per se. Before the class
| keyword, JavaScript had much more powerful OOP semantics
| using metaobjects.
| AlchemistCamp wrote:
| There's also a lot to be said for having fewer footguns. One
| reason I liked CoffeeScript is that it actually _removed_ JS
| footguns such as "with", ==, etc.
|
| I'd rather either Clojure or Java to using Scala and having
| _all_ the possible complexity and interactions between
| paradigms it makes possible. Sometimes less is more.
| suzzer99 wrote:
| Wait until you have to maintain someone else's overly crufty,
| inheritance-based JS framework.
| moron4hire wrote:
| There's nothing wrong with inheritance, even in JavaScript.
| hot_gril wrote:
| Yeah, I write all my new stuff in JS (React frontend, Node
| backend) and have never felt the need for defining my own
| classes. Wasn't actively avoiding them either. React was fully
| centered around classes and they ditched all that in the new
| hooks system.
|
| I also don't understand the big deal with arrow functions. Yeah
| I use them, but they're basically regular functions except
| slightly shorter to write. `async` was a big improvement,
| though.
| jfengel wrote:
| Arrow functions have less-incomprehensible semantics of what
| "this" means. Though that's less important if you're not
| using the classes.
|
| Most users just use arrow functions as syntactic sugar. But
| it's really good syntactic sugar.
| suzzer99 wrote:
| That just described how I feel about Typescript - created by
| Java programmers so that they can feel comfortable and not have
| to learn how to program in Javascript. I was a Java dev for a
| decade. It's so much more tedious and less fun than programming
| in Javascript. I get Java recruiting emails and I shudder.
|
| I accept that in gigantic apps worked on by multiple teams, and
| libraries shared with 3rd parties, Typescript makes sense. But
| 90% of the time I see it used it's with a smallish node app or
| SPA worked on by a few people, and all Typescript does is slow
| things down.
|
| I feel like I can count on one hand the number of times I've
| gotten burnt by a run-time JS bug that a compiler would have
| caught. I just don't see that as a strong use case for the
| overhead and development drag of TS. I only see sharing lib-ish
| code across teams as a net benefit of TS.
|
| 99% of the time when the TS IDE complains over something that a
| JS linter wouldn't have caught, it's just because something
| wasn't defined properly in TS, not because it's an actual error
| in the code.
| okeuro49 wrote:
| > created by Java programmers so that they can feel
| comfortable and not have to learn how to program in
| Javascript.
|
| Well... C# .Net developers, as Microsoft found, correctly,
| that you can't build complex products easily with a lack of
| types.
|
| I also don't think many program in vanilla Javascript; it
| seems everyone is using JSX.
| rikroots wrote:
| > I also don't think many program in vanilla Javascript
|
| I enjoy coding in vanilla JS - my canvas library is 100%
| vJS, with a hand-written .d.ts file in the root directory
| in case anyone wants to import it into their TS project.
|
| That said, I also enjoy jogging along cliff edges and
| sheltering under trees during storms so I'm not the sort of
| person who should be offering programming advice...
| capableweb wrote:
| Are you really trying to say people couldn't build complex
| apps before TypeScript? I know of hundreds of examples that
| were made before TS...
|
| Complex apps still had lots of tests, which basically solve
| the same problem as TS is trying to address, without having
| to write a different language than what gets run by the
| browsers.
| sdeframond wrote:
| How would you compare the overhead of writing tests un JS
| to the overhead of doing proper TS?
|
| Obviously tests are still useful in TS, but not as many I
| think. Also, the feedback loop of a static type system
| is, IME, much faster than with tests only.
| keb_ wrote:
| > That just described how I feel about Typescript - created
| by Java programmers
|
| Close! C# programmers. :)
| WorldMaker wrote:
| > No classes in JS was much better than with.
|
| I think you experienced a different JS than I did. JS has
| always had classes, they were just "harder" to build/use and
| every "Framework" had a different mixed bag of "utilities" and
| patterns to work with it and they weren't always compatible.
| (Mixing jQuery style classes and Dojo style classes was "fun",
| for two random examples. I could go on all day about the long
| tail from MOO Tools to YUI to Backbone to...) ES2015 class
| syntax just standardized already common patterns and increased
| interoperability and cleaned up a lot of footguns regarding
| Prototype-style inheritance along a "garden path".
|
| The class syntax garden path is much nicer than the weed-filled
| hedge maze it mostly replaced.
| pier25 wrote:
| > _The class syntax garden path is much nicer than the weed-
| filled hedge maze it mostly replaced._
|
| I agree. Honestly I don't understand the obsession some
| people in the JS world have against classes.
|
| React components with state made more sense with classes than
| hooks. And yeah some people argue hooks are composable yada
| yada but if you need a React expert to write a useInterval
| hook to use a fundamental language feature, then maybe the
| model is not a great idea to begin with.
|
| https://overreacted.io/making-setinterval-declarative-
| with-r...
|
| Of course I know I'm in the minority here.
| schwartzworld wrote:
| It's because they have been bitten by inheritance issues.
| Classes are great as long as you limit or avoid inheritance
| altogether. They work so nice with typescript.
| WorldMaker wrote:
| Relatedly, it's also because of multi-inheritance issues
| specifically. React built hooks in part to handle cross-
| cutting concerns that needed some form of multi-
| inheritance (mixins and "higher-order components" which
| themselves were often something of a hack around the
| existence of strong JS mixin libraries/standards/best
| practices/meta-programming). The best hooks _are_ an
| improvement over their HOC counterparts (and many of
| their mixin counterparts): better Typescript types, fewer
| footguns, fewer composability limits (HOCs had stack
| problems where stack them in the wrong order and they
| broke or interfered with each other), easier to reason
| about (even given the weird learning curve of hooks in
| general, as black box "units" they have simpler
| mechanics and APIs than HOCs ever did).
|
| To be fair, you can build a lot of React components
| without ever feeling a need for something like an HOC and
| never deal with some of the inheritance problems that
| Hooks were built to solve so some of that "classes are a
| better way to write components" feeling is that one has
| never quite before had the multi-inheritance itch to
| scratch that Hooks solves for. It's obviously hard to
| judge a tool when you don't know if you've had the
| problem it solves for or not.
| mattgreenrocks wrote:
| I've avoided JS/TS almost entirely, and shown contempt toward it
| a bunch in the past. I'm now at a place where TS seems like a
| reasonable language for prototyping backend stuff: JS has a GC,
| big package ecosystem, sum types, static typing, good tooling
| support.
|
| Only thing that ticks most of those boxes (IMO) is Kotlin. Anyone
| been down this road before (skeptic->using in prod)?
| steve_adams_86 wrote:
| Dart appears to tick some of those boxes, but probably not the
| big package ecosystem and sum types boxes. I'm considering
| building something with it at the moment, but I'm hesitant to
| commit much brain power to something Google has a lot of
| influence over. Yet, Go has been awesome and I don't regret
| learning it. In some ways, Dart looks a bit like what I wish
| TypeScript could be, though not exactly.
|
| Something I use a lot in Rust is exhaustive matching and sound
| types, which Dart now has. It's a somewhat specific thing, but
| I like designing finite, well-scoped systems which can be
| handled and tested almost completely. Doing this in TypeScript
| is kind of possible but can be incredibly verbose and difficult
| to navigate for less experienced programmers. While the design
| patterns aims to simplify and eliminate errors, the type system
| can easily complicate it and introduce mistakes.
|
| That's such a drag in my experience. For example, stuff like
| this can happen in TypeScript:
| https://www.typescriptlang.org/play?ts=5.1.0-beta#code/GYVwd...
|
| However, TypeScript has come a long way and it gets better in
| this regard all the time.
| hot_gril wrote:
| I used to avoid JS then tried it for backend stuff, finding it
| actually the easiest way to do web backends. Most off-putting
| thing was the "callback/promise hell" erroneously recommended
| in tutorials until I realized you're actually supposed to use
| async-await. Then React Native instantly converted me from the
| horrible native iPhone dev, then got me into React (web). So
| I'll do new app projects fully in JS.
|
| I also gave TS a serious try and found it pointless.
| Complicated the toolchain, made default stuff like the Node
| profiler not work anymore, and wasted tons of time on defining
| types that didn't actually catch any mistakes. Went back to JS.
| Turns out part of its strength comes from not caring.
|
| Before that had used Java, Scala, C, C++, Erlang, Python,
| Swift, ObjC, Rust, PHP, and a little Golang.
| yamtaddle wrote:
| > Most off-putting thing was the "callback/promise hell"
| erroneously recommended in tutorials until I realized you're
| actually supposed to use async-await
|
| Async/await's pretty new, is probably why you're seeing so
| many tutorials that don't use it.
| hot_gril wrote:
| Yeah, but even new documentation sometimes uses promises,
| particularly anything related to Google like
| https://firebase.google.com/docs/auth/web/custom-auth
| yamtaddle wrote:
| The page has a 2023 last-edited on it, but the code
| snippet (if you follow the GH link) hasn't been touched
| in two years.
|
| If their JS docs are anything like their Android docs,
| Google's _terrible_ about updating examples.
| hot_gril wrote:
| async/await is still pretty old by now. Maybe they wanted
| to be consistent with even older examples. I dunno, every
| single thing Google-related uses promises, so I'm
| thinking they're partial to that for some reason.
|
| Another example from 4mo ago:
| https://github.com/kubernetes-
| client/javascript/blob/master/... (the catch at the end
| is a promise catch)
| WorldMaker wrote:
| There's a _tiny_ benefit of the doubt to be given here
| that while async /await is several years old, support for
| "top-level await" was only more recently standardized and
| took too long for common LTS versions of Node to also
| support it.
|
| All of these examples appear to be top-level and perhaps
| they didn't want to write them as async functions or
| IIFEs, especially for error-handling code.
| hot_gril wrote:
| That makes sense, someone copy-pasting async code into a
| JS console would get errors not too long ago.
|
| There's nobody to blame for this but myself, just wish I
| discovered earlier on how async/await works, along with
| other modern JS stuff that you won't see everywhere
| because it's new.
| schnable wrote:
| Well, that's one way to put it.
| davely wrote:
| I am a product of a coding bootcamp from awhile back, so
| JavaScript is really the only thing I've ever known in my career
| (outside of writing some apps in Visual Basic around 2001).
|
| Maybe it's because it's the only thing I've ever known, but... I
| like it?
|
| I guess if I hack around on a side project and want to use
| vanilla JS, it's the Wild West and there's no rhyme or reason for
| anything (and everything looks gross).
|
| But working inside various frameworks have been pretty enjoyable
| for me.
|
| Side note: there's also this hilarious video about the...
| delightful nature of JavaScript from 2012:
|
| https://www.destroyallsoftware.com/talks/wat
| qbasic_forever wrote:
| JS itself is perfectly fine and quite a nice language when you
| stick to all its modern idioms that you learned and use today.
| I think what rankles a lot of people is going through the
| history of JS when it was terrible and confusing, then
| basically just jQuery, then the explosion and confusion of
| server side/node and drama with the company behind it, and
| finally confusion and drama with moving to modern ES modules.
|
| For the longest time doing the most simple thing in any
| programming language, putting code in a separate file and
| loading it to execute, was nearly impossible in JS and required
| learning and picking sides in an opinionated loader battle. It
| was confusing and pretty bad for newcomers.
|
| Nowadays all that drama is settled and the core of modern JS is
| quite nice. I like it more than python to be honest.
| ElectricalUnion wrote:
| > and finally confusion and drama with moving to modern ES
| modules. (...) Nowadays all that drama is settled and the
| core of modern JS is quite nice. I like it more than python
| to be honest.
|
| Using a mixture of old, deprecated versions of Webpack,
| Angular, Babel, and Typescript, and a very big pile of code
| with plain bad (if not plain wrong) type annotations I wish
| that statement applied to me.
|
| Constantly attempting to keep all this nodejs stuff without
| vulnerabilities while migrating the least ammount of stuff at
| once is a daily challenge.
|
| And that comparison is pretty low bar, everything involving
| say pytorch is a flaming pile of bad waiting to explode.
| treis wrote:
| The problem with JS these days is not that what's there is
| bad. It's that there's not much there. Anything beyond the
| basics requires you to roll your own or go hunt for a
| library.
| qbasic_forever wrote:
| Very true, it's why I really like deno for server side
| since it's trying to plug that gap with a nice out of the
| box standard library. Client side it does feel like
| something like lodash is the new jQuery and just mandatory
| to use everywhere.
| mst wrote:
| And then of course you have to pick between lodash and
| ramda (I'd say "whichever your dependencies use" but
| every time I've tried to use that as a deciding factor
| the answer has turned out to be "both").
|
| It's all a bit of a cambrian explosion but it at least
| means you run into "this awful API has been baked into
| core and now we're stuck with it" less often.
| schemescape wrote:
| Anecdote: when using Metalsmith and a sampling of plugins
| to build my fairly minimal static site, I ended up with
| 18 direct dependencies and 200 transitive dependencies,
| including _6 different file name matching libraries_.
|
| I now prefer comprehensive standard libraries.
| jakelazaroff wrote:
| As in, there's not much in the standard library? What other
| options are there beyond "roll your own" or "use a
| library"?
| andirk wrote:
| Don't use?
| chrisco255 wrote:
| I always think back to this talk when I come across a
| WebAssembly Text file, annotated by .wat. Highly relevant to
| the author's prediction about the future from 2014 as well:
| https://www.destroyallsoftware.com/talks/the-birth-and-death...
|
| https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...
| keb_ wrote:
| I started writing a small static site generator for myself using
| JavaScript and QuickJS by Fabrice Bellard[1]. QuickJS is not
| quite complete, and there are some cross-platform
| inconsistencies, but overall I found it pleasant to use and its
| libc wrappers to be powerful enough. I also found that JavaScript
| is actually pleasant to use when I'm not using classes, or
| dealing with metaprogramming/Babel, or implicit globals.
| Dependencies are just pure .js files I keep in a /lib directory
| and import.
|
| I still think JS is a nice language although I tend to side with
| Crockford (before he started promoting the "next" language) in
| that JS has some good parts, and you can write clean and powerful
| software with it if you ignore most of its warts (even if you're
| using Node). My best advice is be _very_ careful with what
| dependencies you choose; and also, don 't feel pressured to be at
| the bleeding edge all the time. The Node/React world is a
| constant hype machine that flip-flops on best practices every 6
| months. Be very skeptical of them, and don't let them spoil JS
| for you.
|
| [1] https://bellard.org/quickjs/
| synergy20 wrote:
| what's the use case for quickjs? can it be used for a light-
| weight runtime for JS on resource restricted embedded devices?
|
| by the way, comparing to angular and vue2-vue3, react is
| actually the one without python2-python3-alike breakages over
| the years to me, I would say it's the best out of the 3
| options(angular,vue,react) so far, which could explain by
| market share that it remains to be dominant.
| schemescape wrote:
| Not OP, but I experimented with QuickJS for my SSG and, on my
| super slow laptop, it started up about 200ms faster than
| Deno, but ran about 5 times slower overall (and the binary
| was much, much smaller).
|
| My original motivations were: Deno doesn't support Raspberry
| Pi and I was running lots of short-lived processes to support
| incremental rebuilds using a Makefile. In the end, my
| requirements changed, so I'm not using QuickJS, but it was
| very easy to pick up and use.
|
| So: portability, startup time, and small code size seem to be
| the advantages of QuickJS.
| vmfunction wrote:
| Hmm, it's a shame that Little Javascripter is not mentioned:
| https://www.crockford.com/little.html That is really the only
| positive reason to use JS.
| pier25 wrote:
| I must be the only person left not writing TS at this point.
|
| Once EcmaScript adopts optional static types or some kind of
| standardized type annotations [1] I will probably use those. At
| least in Node, where I have more control of the runtime version.
|
| [1] https://github.com/tc39/proposal-type-annotations
| Wazako wrote:
| typing saves so much time. Especially since the flexibility of
| its optionality does not restrict, and allows for really nice
| autocompletions.
|
| Especially with esbuild which has made this simple and fast,
| one could even say it has saved javascript.
| pier25 wrote:
| I have ample experience with typed languages like C++, C#,
| Java, Kotlin, Go, AS3, Swift, etc.
|
| Maybe I just have exceptional memory but I rarely encounter a
| problem that would have been solved by using TS.
| Scarbutt wrote:
| It's about big codebases and team use, not about you.
| pier25 wrote:
| Every use case is different.
| yamtaddle wrote:
| Yep, they're a communication and documentation tool that
| happens to have pretty-good machine readability and
| correctness-checkability. Sometimes the person you're
| communicating with is your future self, is all. Sometimes
| it's just yourself five minutes from now, even.
| keb_ wrote:
| They didn't mention big codebases or working on a team,
| though. Also, you can just use JSDoc.
| hot_gril wrote:
| Even in a solo project, you import libs from others.
| Never felt the need for those libs to have types.
| hot_gril wrote:
| Typing wastes time. Teammate and I tried switching a backend
| project to TS, and I kept a mental note of time spent
| defining types vs time saved not debugging type-related
| issues. The result was some high number vs 0. Also messed
| with the toolchain, making things like Node profiling not
| work.
| yCombLinks wrote:
| If you already have an existing, functioning codebase,
| adding types is not saving you time (right now). It's akin
| to adding a lot of unit tests. You gain time later, and
| often indirectly from others not making mistakes your types
| would prevent.
| hot_gril wrote:
| Ample time passed, we added more after we were already on
| TS, and it wasn't helping. In fact it was a constant
| burden on new code.
| yCombLinks wrote:
| Alright, good luck out there. I strongly prefer types
| tomtheelder wrote:
| Is it a solo project? The time savings of typing is really
| a function of project size and number of collaborators. For
| a small, solo project it's either neutral or a negative.
| hot_gril wrote:
| It was team-sized. So, not writing open-source libs used
| by multiple companies or something, but ~10 people were
| looking at the code.
|
| At my current job we do have a lot of untyped Python used
| by tons of people, and it's fine. People can read the
| code without it asserting in every line what each
| variable is. You just make sure any widely-used APIs are
| documented properly, which typing doesn't really help
| with. Also anything modern is more microservice-oriented
| which comes with nicer boundaries, and everything has
| tests (which again typing is no substitute for). Typing
| seems like a mostly outdated thing for application-level
| stuff.
| capableweb wrote:
| Believe it or not, autocomplete is still possible without
| typing, as any user of any dynamic language could tell you.
| Seems like a poor reason to add a another full language to
| the abstraction ladder of your application.
| potta_coffee wrote:
| You're not the only one. I'm sure Typescript is nice / better,
| but I don't feel like having yet another bullshit language
| foisted on me. Also I dislike Microsoft.
| atlantic wrote:
| I'm still using Javascript and jQuery. In combination they work
| just fine. I took the time to learn TS, but I never felt the
| need for it.
| fbn79 wrote:
| I'm with you. I do not want my code transpiled. I wrote vanilla
| JS and use Typescript only as annotations
| (https://www.typescriptlang.org/docs/handbook/jsdoc-
| supported...)
| naikrovek wrote:
| not sure I'd call it "delightful" in any way, but it certainly is
| weird.
| theknocker wrote:
| [dead]
| dgreensp wrote:
| I stopped reading after the typo "JavasScript" and then the
| juvenile tone of "Less that 10 years ago, JavaScript sucked bad."
|
| I have a positive impression of fly.io overall, I mean they
| admitted they are still figuring out how to build tech at the
| level of their ambition and have it be reliable enough, but I
| might like to be a customer one day.
| recursive wrote:
| > the typo "JavasScript"
|
| You may be interested to know TC39 makes the same "typo" at
| https://tc39.es/ right in the biggest header on the page.
|
| > Specifying JavaScript.
|
| Hm, maybe it's not a typo?
___________________________________________________________________
(page generated 2023-05-11 23:02 UTC)