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

The three pillars of JavaScript bloat

43081j.com

Post reply on HN
Print view View original

161–170 of 301 posts

Re: The three pillars of JavaScript bloat

#161

Post by KronisLV »

prinny_ wrote: post #155

Everyone trash talking the JS ecosystem without contributing the slightest to the conversation would benefit a lot if they read https://www.artmann.co/articles/30-years-of-br-tags in order to understand the evolution of the language and its tooling. Nobody argues what we currently have is great and that we shouldn't look to improve it. Reducing it to "JS developers bad" is an embarrassing statement and just shows ign…

> “JS developers bad“

I found it to be a nice post that documents why things sometimes are bad. It didn’t feel accusatory at the developers themselves, but seemed to serve as a reasonable critique of the status quo?

Re: The three pillars of JavaScript bloat

#162

Post by n_e »

prinny_ wrote: post #155

Everyone trash talking the JS ecosystem without contributing the slightest to the conversation would benefit a lot if they read https://www.artmann.co/articles/30-years-of-br-tags in order to understand the evolution of the language and its tooling. Nobody argues what we currently have is great and that we shouldn't look to improve it. Reducing it to "JS developers bad" is an embarrassing statement and just shows ign…

[dead]

Re: The three pillars of JavaScript bloat

#163

Post by n_e »

KronisLV wrote: post #161
prinny_ wrote: post #155

Everyone trash talking the JS ecosystem without contributing the slightest to the conversation would benefit a lot if they read https://www.artmann.co/articles/30-years-of-br-tags in order to understand the evolution of the language and its tooling. Nobody argues what we currently have is great and that we shouldn't look to improve it. Reducing it to "JS developers bad" is an embarrassing statement and just shows ign…

> “JS developers bad“ I found it to be a nice post that documents why things sometimes are bad. It didn’t feel accusatory at the developers themselves, but seemed to serve as a reasonable critique of the status quo?

I assume they were talking about the comments here, not the post which I agree is great.

Re: The three pillars of JavaScript bloat

#164

Post by jsmith99 »

Maxion wrote: post #58
auxiliarymoose wrote: post #20

I really think writing dependency-free JavaScript is the way to go nowadays. The standard library in JS/CSS is great. So are static analysis (TypeScript can check JSDoc), imports (ES modules), UI (web components), etc. People keep telling me the approach I am taking won't scale or will be hard to maintain, yet my experience has been that things stay simple and easy to change in a way I haven't experienced in dependen…

Did this for a project in 2022. Haven't had any drama related to CVEs, hadn't had any issues related to migration from some version of something to another. The client has not had to pay a cent for any sort of migration work.

Is the lack of CVE because the implementations you wrote are better written and safer than those in the standard libraries or because no one has checked?

Re: The three pillars of JavaScript bloat

#165

Post by righthand »

cobbzilla wrote: post #44
cwnyth wrote: post #26

Earlier quoted context omitted.

Cf. Vonnegut's rule #4 of good writing: > Every sentence must do one of two things—reveal character or advance the action. Or Quintilian's praise of Demosthenes and Cicero: "To Demosthenes nothing can be added, but from Cicero nothing can be taken away."

Is there no room for describing the setting? Must every utterance that sets the atmosphere also advance the plot or reveal character? Is there no room for mood?

The “mood” should reflect the character not the author’s desire to detail out the room.

Re: The three pillars of JavaScript bloat

#167

Post by follie »

prinny_ wrote: post #155

Everyone trash talking the JS ecosystem without contributing the slightest to the conversation would benefit a lot if they read https://www.artmann.co/articles/30-years-of-br-tags in order to understand the evolution of the language and its tooling. Nobody argues what we currently have is great and that we shouldn't look to improve it. Reducing it to "JS developers bad" is an embarrassing statement and just shows ign…

I find the mindset of trying to understand and accept bad fine in moderation but as defeatist when taken past the end of the block. It doesn't matter why JS is bad and will harm your future prospects if you approach it with too much acceptance. We always need to be examining the practice in front of us and the theory that would be a better replacement for it and trying to make the leaps at the right times to keep getting paid while not becoming part of the problem ourselves.

Science advances one funeral at a time applies to software with things going at a faster pace so a good software engineer needs to fake a few funerals or really be senior at 4 years to be dead by 7.

Re: The three pillars of JavaScript bloat

#168

Post by robocat »

auxiliarymoose wrote: post #20

I really think writing dependency-free JavaScript is the way to go nowadays. The standard library in JS/CSS is great. So are static analysis (TypeScript can check JSDoc), imports (ES modules), UI (web components), etc. People keep telling me the approach I am taking won't scale or will be hard to maintain, yet my experience has been that things stay simple and easy to change in a way I haven't experienced in dependen…

Rendering components is the easy part. Another goal of frameworks is to provide the model (reactive updates): https://mjswensen.com/blog/the-single-most-important-factor-...

What do you use for model updates?

Re: The three pillars of JavaScript bloat

#169

Post by foldr »

jsmith99 wrote: post #164
Maxion wrote: post #58

Earlier quoted context omitted.

Did this for a project in 2022. Haven't had any drama related to CVEs, hadn't had any issues related to migration from some version of something to another. The client has not had to pay a cent for any sort of migration work.

Is the lack of CVE because the implementations you wrote are better written and safer than those in the standard libraries or because no one has checked?

Presumably the latter. However, mindlessly bumping package versions to fix bullshit security vulnerabilities is now industry standard practice. Once your client/company reaches a certain size, you will pretty much have to do it to satisfy the demands of some sort of security/compliance jarl.
Post reply on HN