Live data from Hacker News

The JavaScript ecosystem is delightfully weird

fly.io

181–190 of 248 posts

Re: The JavaScript ecosystem is delightfully weird

#181
post #171

Earlier quoted context omitted.

> 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 featur…

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.

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.

Re: The JavaScript ecosystem is delightfully weird

#182

Earlier quoted context omitted.

> 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.

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.

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.

Re: The JavaScript ecosystem is delightfully weird

#183

Earlier quoted context omitted.

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)

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.

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.

Re: The JavaScript ecosystem is delightfully weird

#184

Earlier quoted context omitted.

JavaScript, The Good Parts by Douglas Crockford symbolises this well today https://www.reddit.com/r/ProgrammerHumor/comments/621qrt/jav...

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…

The joke is about the size of the books in the photo, not about JavaScript features.

Re: The JavaScript ecosystem is delightfully weird

#185

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 d…

> 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 &…

I’m the same here. React with TS just makes sense as it is. We have a mix of class and functional components which can easily be understood. State lives here, logic goes there, render, done! It does become tricky when you start adding things to its simplicity like Redux, useEffects, useContext, useReducer, locationState, params, props, classes, StorageProvider (and the list goes on) without a clear standardized code guide for each scenario/patterns.

Re: The JavaScript ecosystem is delightfully weird

#186
post #48

Earlier quoted context omitted.

How do you build web applications?

There are plenty of ways these days to build rich web applications without writing much JS. LiveView, Hotwire, Reactor, LiveWire, Blazor...

Not really against JS as a language, everything against the current state of its ecosystem

Re: The JavaScript ecosystem is delightfully weird

#187
post #112
post #53

Earlier quoted context omitted.

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.

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.

I can't disagree with the "no one wants" part unfortunately, no matter how good my counter-arguments can be.

Re: The JavaScript ecosystem is delightfully weird

#188
post #53

Earlier quoted context omitted.

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.

> 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".

Well, I agree if your experience was around codebases that tried to fit JS in the OOP category.

Re: The JavaScript ecosystem is delightfully weird

#189

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 d…

> the entire javascript ecosystem in general. The trend-based, article-driven development, the new framework/pattern you have to learn/unlearn every six months

Maybe it’s worth logging off Twitter for a while and understand that you can just not pay attention to these ‘trends’ and learn a new pattern every six months and you’ll be absolutely fine. Yes, ecosystems and communities can encourage this, but individuals also have got to take some responsibility for opting themselves out (or into) this hamster wheel.

I’ve seen this React Server Components stuff on the periphery for a while now, but I don’t really understand it and I don’t intend to for a while. I’ll let the twitter us hype beasts sort out what they want to do with it and I’ll circle back and check out what it’s like in a few years.

Re: The JavaScript ecosystem is delightfully weird

#190
Controversial opinion rant below:

I think the weirdness is a cycle kicked off and perpetuated by how accessible web development it.

It's a good thing that it doesn't take a comp sci degree to build a completely functional, professional looking and/or profitable JavaScript powered application.

In addition to the exclusivity of JS in the browser - the ease of becoming productive has been a large driving force of its widespread adoption. The cost effective nature (cross platform, ease-of-development, abundance of skill) has played a large part in its ubiquity.

This large number of developers has resulted in a large market for tool makers.

Tools are difficult to profit from, so toolmakers adjust their business models and marketing to suit.

As a result, a lot of developers write self promotional blog posts sharing "best practices" and plenty of impressionable decision makers dive head first into well marketed trendy tools/technologies that _may_ offer a benefit but often not proportional to their cost (vendor buy-in, additional complexity/reduction in project maintainability).

For example, front end projects tend to prematurely optimise with huge foundational features like SSR - without considering their use case, the performance trade offs (caching, amongst others) and other more ergonomic/cheaper/more effective, optimisations.

Despite not requiring it, developers tend to highly _highly_ couple their presentation logic to their application logic to the point where throwing away and rewriting an application is not an unreasonable sounding endeavour. People don't write an application that uses React, Vue, Angular - they write a React/Vue/Angular application.

The current meta has moved away from boring obvious procedural circuits to dense, clever, fancy functional circuits which I (controversially) find difficult to grok, modify, and debug. I certainly use functional code (like functional components are nice for simple use cases and .filter/.find are nice shortcuts), my feeling is that deep functional chains are perhaps overemphasised now and difficult to mentally simulate when reading (which you must do inside-out, holding each step in your head).

Testing is also a huge pain point. Developers tend to make extensive use of features like module mocking (`jest.mock('./filename')`) and avoid any form of dependency injection (not talking about DI frameworks, just simple property injection). If there is a hell, module mocks were sent to us from there. So many times I have made changes to a file where module mocks prevented tests that would otherwise have failed from failing. They are hard to track down, fail at runtime and... cries

Today, when I consider joining a new company and hear a project uses React, NGRX, Redux, Next.js, SSR, and a few others - I can almost immediately assume it's going to be a contribution and maintenance nightmare.

I still love front end even though it is an endless source of headache-inducing eye rolls watching people shoot themselves in the feet while confidently claiming it's the best way to run faster.

Post reply on HN