Hacker News Reader

Comment by austin-cheney | Hacker News Reader

Most developers in JavaScript struggle with asynchronous things. Instead they hope to solve everything with classes and when that fails they need frameworks to do anything. So, I recommend solving for that first instead of jumping into innovative syntax features.

My recommendation is to create a new language that’s focused exclusively on functions and how to organize them. Organization is an advanced skill learned from experience that is not immediately benefitted from high intelligence and most developers fail in that regard. Think in terms of lexical structures, events, return types, data structures, process flow (technical and business), and call stack.

If you can really dominate concepts of organization by language design the best supporting syntax innovations will shift to more specifically meet your needs.

View on HN

Are you referring to frontend mostly? Would a language like Elm be a good fit for what you're referring to in terms of organization?

One of the additional goals I have is to be able to write type safe APIs between frontend and backend similar to trpc (elysia framework).

That does pose an interesting question. Why is the front end so much more reliant on frameworks? Is it the environment or the people doing the work? Regardless the problem and the result are often the same. The inability to organize logical structures as necessary to complete a flow of business processes hinders which goals one aspires to achieve.

In my experience writing large applications in JavaScript the front end (in the browser) and the back end are less different than people typically consider. It could be that many people struggle with the DOM, but anyways it’s all APIs and event handling.

I'm sure there's a billion reasons for frontend frameworks not really worth debating here, but I was curious about this:

> It could be that many people struggle with the DOM, but anyways it’s all APIs and event handling.

Without a framework, how do you usually like to handle cross-component/cross-screen state in the frontend? Like where do you keep track of logged-in state, dark mode, the shopping cart, etc? Do you just like to put that in the backend, or is there a neat way to organize such data in vanilla JS in the frontend?

I keep state in a single object. State management is ridiculously simple but people tend to make it more challenging than it needs to be. I then send the data stored in that object out of the browser as determined by the app for storage at the server. Restoring state is as simple as embedding the state data directly into the static html so that it’s always there as fast as possible every time the page is requested.

Sounds like using "window" as a big global variable, but cached on the backend almost like a manual cookie?

Well typed, I'd imagine the dev ex would be similar to a monolithic React context. Seems like it'd work.

Reply on news.ycombinator.com