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

301–310 of 391 posts

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

#301

Post by soliton4 »

i wonder if this kind of pattern emerges natuarlly from a community of experts. think of how you need lawers who studied for years, to understand whats going on with laws and regulations a similar pattern most certainly emerged within the german tax system. maybe the complexity of the health system is (in part) a similar pattern.

i hypothesis that a community of expert will reiterate on the rules that are present within the community, over and over, until only experts who studied the topic for years can even begin to deal with it.

perhaps there is even a self regulating mechnism. you need to understand a system to a certain degree in order to contribute. at some point the group who can contribute consists soley of experts who studied their field for years. those experts will then contribute and make it slightly more complex. the complexity raises but only to a degree that allows a group of experts to "catch up" with the complexity in order to contribute themselves. if it gets "to complex" it runs out of contributers

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

#302

Post by jmull »

No doubt: The standardization of modules in Javascript was a real screw up.

I hope the people involved are embarrassed enough to figure out how they are going to avoid fails like this in the future. (But I suspect they pat themselves on the back and each other it was a total success.)

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

#303

Post by TameAntelope »

lucidguppy wrote: post #189
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/

X is not hard, you just have to Y. Be careful of these statements, you have to understand why a person says X is hard. The OP stated he did extensive work trying to get it to work and found it difficult. You posted one link out of thousands. When talking about these things - its not like there's a problem with one solution. There's one problem with thousands of answers that are frustratingly close to correct, but not…

Having just gone through all of this (two years ago), it isn’t “hard”, you just have to stop assuming it’s easy and will only take a bit.

Also Parcel is easier by a factor of 10, skip Webpack entirely.

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

#305

Post by reificator »

IshKebab wrote: post #91
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…

I don't think the Rust team are unaware of supply chain attacks, so you don't need to warn them. It's just that there's no easy solution. Or do you have some easy solution they aren't doing. Just to pre-empt you, namespacing doesn't solve the issue and manually vetting authors/crates is not something the Rust community wants.

Namespaces do not solve the issue but they do mitigate a specific vector, while also removing a perceived need to preregister crates.

There’s no downside beyond “it requires development time and maintenance” like any other feature.

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

#306

Post by corrral »

tyingq wrote: post #288
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…

There are some ecosystems where the experience is different. Perl, for example, does have deprecations, but not many. It's fairly common to be able to run 30 year old code unmodified, or with very minor changes. Of course, it has it's own issues, but it is very stable across time.

One shock if you go back and forth between Javascript and, say, Java, is adjusting your library evaluation criteria.

It's not weird for a Java project to include a library that hasn't had any updates in 4+ years. Sometimes those sorts of libraries are even considered the standard for whatever thing they do.

Meanwhile in JS you have to assume a library with no releases in the last 6 months has already bitrotted to death.

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

#307

Post by krapp »

the__alchemist wrote: post #290
krapp wrote: post #273

Earlier quoted context omitted.

> I'm making this distinction because you can use JS in what it access at without invoking build tools and dependencies. Theoretically, yes. Practically, no, because almost all javascript code is written in typescript, packaged into modules and distributed on NPM nowadays. There's the tiniest inking of a "vanilla js" movement out there, but otherwise all of the libraries and tutorials and advice assumes that ecosyste…

https://developer.mozilla.org/en-US/docs/Web/JavaScript You don't need any of those to invoke client-side UI changes.

I know how javascript works, I was writing javascript before JQuery was a thing.

The problem is, there's no ecosystem around plain javascript anymore. You either write everything yourself or, as OP discovered, have to work with NPM packages.

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

#308

Post by dahauns »

maxloh wrote: post #162
hudo wrote: post #81

My experience also. As a backend engineer trying to create a front end app, the whole toolchain of JS, bundlers, minifiers, Typescript, React... is basically; works if you have one magical init script that wires up everything, and much more than you really need since its tailored for more complex apps, but if you need just simplest thing, like run Typescript app in browser, well, good luck with that! Hundreds of tuto…

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!

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

#309

Post by dahauns »

TameAntelope wrote: post #303
lucidguppy wrote: post #189

Earlier quoted context omitted.

X is not hard, you just have to Y. Be careful of these statements, you have to understand why a person says X is hard. The OP stated he did extensive work trying to get it to work and found it difficult. You posted one link out of thousands. When talking about these things - its not like there's a problem with one solution. There's one problem with thousands of answers that are frustratingly close to correct, but not…

Having just gone through all of this (two years ago), it isn’t “hard”, you just have to stop assuming it’s easy and will only take a bit. Also Parcel is easier by a factor of 10, skip Webpack entirely.

>Having just gone through all of this (two years ago), it isn’t “hard”, you just have to stop assuming it’s easy and will only take a bit.

So it isn't hard - it's just not easy and it's time consuming. Wait, what?

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

#310

Post by Jasp3r »

longrod wrote: post #243
Jasp3r wrote: post #232

Earlier quoted context omitted.

The whole issue of JavaScript is that the standard library is worthless, so people have to write additions to keep yourself sane as a developer. This makes it seem that there are 5 billion ways to do something, because there are. Just use TypeScript, it will fix all the issues you have with the language itself. Typing + build time errors + import/export syntax. If you want to run some this in the browser, and don't u…

Typescript doesn't solve any of the mentioned issues. You can't use CommonJS modules if you are targeting ES6+. And you can't use ES6 modules if you are targeting CommonJS. The only thing really useful about Typescript is types + generics (to some extent). If you install any library that's either only ESM or CommonJS, you can't run your program. It simply doesn't work.

I have never had this issue in my life. If you have issues with module bundling, use a module bundler.
Post reply on HN