Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lea.verou.me

Post reply on HN
Print view View original

311–320 of 391 posts

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

#311

Post by wly_cdgr »

alexb_ wrote: post #72
alexb_ wrote: post #63

This thread is also a good read: https://twitter.com/Aella_Girl/status/1522633160483385345 Shows that a lot of people, ESPECIALLY programmers, vastly overestimate the competence of the average person when it comes to whatever they are an expert at. You may think that this person is silly - but that is tainted by your past experience of already knowing it warping what you think the baseline average knowledge level is…

Was going to edit this in but it quickly turned into a related rant about the state of things: if you don't want that, scroll past. The real problem is that there's no more room for the technological "middle class". We've gotten to the point where you cannot be SLIGHTLY interested in computers, want to make a quick app for yourself, or make something small to share with the world. You either have to have no interest…

There's space in tools like Godot, which has a relatively stable API, tight and helpful integration with its custom scripting language as well as support for both C# and C++, solid docs, first-class support for 2D, the ability to export to mobile as well as web and desktop, and the ability to toggle between a continuous rendering mode suitable for games and a reactive rendering mode more suitable for apps.

GameMaker, too, has a very stable API for its proprietary scripting language and, though it is made with 2D gamedev in mind, can work just fine for simple apps for personal use.

Defold is worth mentioning as well

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

#312

Post by wly_cdgr »

aahortwwy wrote: post #116
alexb_ wrote: post #72

Earlier quoted context omitted.

Was going to edit this in but it quickly turned into a related rant about the state of things: if you don't want that, scroll past. The real problem is that there's no more room for the technological "middle class". We've gotten to the point where you cannot be SLIGHTLY interested in computers, want to make a quick app for yourself, or make something small to share with the world. You either have to have no interest…

This just isn't true, though. I have quite a few non-technical colleagues who know just enough Python to Get Shit Done. My father (a writer) taught himself R for research purposes and is productive with it. Universal Paperclips has a super-basic JavaScript codebase[0] but was a really popular game. Thing is, if you search "how to do X in Python" you're going to get a bunch of resources aimed at professionals because…

Oooooh did you just call Frank Lantz super-basic kek

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

#313

Post by greggman3 »

aeturnum wrote: post #300
gernb wrote: post #31

sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error. repeat the same with xcode and any project in c, c++, objc, swift okay how about ruby? oh I have old…

I agree that the C family has some similar problems but I think you're missing part of what makes Javascript uniquely frustrating. Javascript is deployed in many different environments and you need to learn not just how to include a library in each environment, but also how to interact with that library. Also unlike C or other languages - Javascript has a hard time warning you about when you've imported something the…

I get it's frustrating but ... do you expect any Lua to run in every environment Lua is used in? AFAICT no 2 Lua's are alike and nearly ever use of it has it's own APIs and quirks. I have the same issue with C. You can find some C that will run anywhere. You can also find lots of C that is platform specific and unless you're an expert you'll be just as frustrated trying to get it to run on a different platform. Seems the same to me.

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

#314

Post by ByteJockey »

lelanthran wrote: post #97
whostolemyhat wrote: post #66

Earlier quoted context omitted.

> why should ECMAscript care about what node does? Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day?

> Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day? They shouldn't pay any attention to it. The language spec should drive the implementations, not a single implementation driving the language specification. Normal exceptions for languages that have a spec based on a reference implementation.

That's fine in a language with a bunch of implementations, but JS only has one (relevant) implementation.

V8 powers Chrome, all Chrome-based browsers (Brave, Edge, etc), node, and deno.

Sure, you can switch your backend to some esoteric thing based on Rhino, but unlike C/C++/whatever, your end-user's also have an implementation and it matters. And they are overwhelmingly using v8.

The Ecma International is basically naval-gazing at this point. They don't control JS, google does. Just see what happened when they added TCO to the spec and google didn't implement it.

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

#315

Post by pie_flavor »

jiggawatts wrote: post #56
gernb wrote: post #31

sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error. repeat the same with xcode and any project in c, c++, objc, swift okay how about ruby? oh I have old…

Meanwhile I've been trying to warn the Rust project team, or more specifically, the Cargo/Crates teams that they're cheerfully skipping down the easy/happy path towards the same mess. It's inevitable that the conclusion will be the same if the same steps are taken in the same direction. The counter-arguments fail to recognise the special case of "most of us are from Mozilla and we all get along[1]", "no-one has attac…

Yanking crates does not get rid of their code; you can still depend on them in your crates, you just can't upload those crates to crates.io.

Editions are not lock-in; the entire point of the edition system is to allow the version of Rust that exists in 2032 to compile every prior edition in the same project at once, and only single crates at a time have to be 2030 edition.

Before making any change that could possibly be breaking, the change is tested on every single crate on crates.io, as well as on a great many GitHub repos that aren't, in order to make sure there aren't any regressions (referred to as a crater run).

You are right that the problems you describe would be problems if Rust was implemented the way you're implying. That is why Rust was not implemented the way you're implying, but rather implemented specifically to avoid these problems.

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

#316

Post by marcosdumay »

jiggawatts wrote: post #147
vaughandroid wrote: post #73

Earlier quoted context omitted.

You've obviously thought about this quite a bit... Do you have any ideas as to how projects could avoid this problem?

I have, but to be honest I've forgotten a lot of the specific debates and their finer points. I don't have a single, definitive, clear solution -- as pointed out by others -- nobody does. It's not a simple problem. That doesn't mean that steps can't be taken to improve the situation, perhaps dramatically in some cases. 1) Enforced MFA to publish a crate -- credential theft is semi-regularly seen as an attack vector.…

> Similarly, if a crate/package changes its public signature in a breaking way, then the publishing system should enforce the right type of semantic versioning bump.

A common following-up question the Haskell people used to say when that was being discussed there is, if your build system can do that, why do you need semantic versioning for?

Still, it's better than doing nothing. There's nothing similar to Stackage or Backpack on Rust, so it would be a clear gain. It's just that you can go further.

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

#317

Post by pie_flavor »

bowsamic wrote: post #71
jiggawatts wrote: post #56

Earlier quoted context omitted.

Meanwhile I've been trying to warn the Rust project team, or more specifically, the Cargo/Crates teams that they're cheerfully skipping down the easy/happy path towards the same mess. It's inevitable that the conclusion will be the same if the same steps are taken in the same direction. The counter-arguments fail to recognise the special case of "most of us are from Mozilla and we all get along[1]", "no-one has attac…

Yep, the Rust team and even the wider community are literally just ignoring this problem under the justification of "it's too early to care about these things yet".

Rust has been designed specifically to avoid these problems, under the justification 'it's never too early to care about these things'. I wonder what on earth you have been reading.

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

#318

Post by SahAssar »

corrral wrote: post #297
donatj wrote: post #256

Earlier quoted context omitted.

I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the…

This seems like a great place to ask how the ever-loving shit you get a front-end project with simple NPM-fetched libraries to bundle into either a single .js file ready to go in a tag, or a block of tags with all the referenced .js files in a directory and ready to serve. Ideally with typescript support, but surely (ha. ha. ha. ha.) I can just tack that on top and point whatever-this-is at typescript's output direct…

For me esbuild has worked pretty well. Given a index.js as the entrypoint for your app:

  npx esbuild index.js --bundle --sourcemap --minify --outfile=out.js --format=esm
esbuild is also pretty quick and does not have a lot of npm depencencies thanks to being a go binary.

npx should download and run the binary for you and npx is almost always installed with node automatically.

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

#320

Post by maxloh »

dahauns wrote: post #308
maxloh wrote: post #162

Earlier quoted context omitted.

It is not quite hard to learn actually. You just need to go through the webpack Concepts section[0]. Documentations in the JavaScript ecosystem are quite good and explanatory compared to other languages (like Java). Not every front-end developers learn the internals of the tool they chose, like create-react-app. Most of them settled down if the solution "just work". [0]: https://webpack.js.org/concepts/

You're kidding, right? Just going through the Concepts of webpack doesn't even scratch the surface - and will arguably leave many unsuspecting devs more confused than before, by e.g. still insisting on calling itself a "module bundler". You're a build system, ffs!

You cannot learn programming just by reading. Try using it in practice. The concepts part should be enough to get you started for a simple vanilla JavaScript project.

If you need more (e.g. TypeScript/JSX/CSS support), You will need some third-party loaders or plugins. webpack itself is just a JavaScript bundler.

Post reply on HN