Hacker News Reader

Also originally from C++, now been working with the likes of React for about five years. After grappling with Redux, React Router, Immutable, Typescript, Flow Typing and a hundred other libraries, my solution was to go back to basics: build applications with vanilla JS, using a bare minimum of libraries and a lot of standard browser APIs. In my case, basically React only. How do I do client-side routing? addEventListener('hashchange'). Type safety? Unit tests. Mapping actions to components? onClick: dispatch(new CustomEvent('foo')) etc.

Edit: Parcel for module bundling and transpile, but I'm waiting for JS native modules. Eventually React too, will go away in favor of Web Components.

That speaks a lot towards React - it's "the basics" now. It's basically supplanting what Jquery was known for.

I totally agree, but that it's "the basics" now.

I remember a time when jQuery was considered so standard that every StackOverflow question about "How do I X in JS?" had as the top voted answer "Use $X() in jQuery". All that accumulated knowledge is now essentially a graveyard. I feel React too will be supplanted by something more closer to a WHATWG standard in the future.

But jQuery was just syntactic sugar on top of a broken API. For all intents and purposes, React _fixes_ HTML and DOM. The reason we _have_ such complexity in the front end these days is because _we can_. We've eschewed all the bullshitty parts of web development (global styling, unpredictable browser APIs, hand-holding DOM through complex interactions) and opened ourselves up to actually writing applications.

The problem, as I see it, is front end developers are still expected to churn out features like they used to in large scale organizations, but we've matured as developers. It's no longer throw a .js file, a .css file and an .html file at a browser and woo hoo you have a site. It requires more time and bootstrapping, but the promise is code that breaks less often and is easier to maintain. It also means we have front end developers that are now specialists in different facets of frontend, such as builds, data layer, typing, feature development and framework design. Notice these are meta jobs.

In order to meet the demands put upon us by our former velocity, we often have to resign ourselves to blackbox libraries and such, which don't always contribute positively to one's stack. Just today we ditched a node module we'd been using because the owner refused to update it. We should be building more internally than we do.

Building your own frameworks and libraries is always a minefield. Too often I’ve seen it done badly.

Unless you’re a big company best to use what’s already out there if you can reasonably

React in itself is a simple (and ugly, if you ask me) templating library. The real mess comes with the many libraries around it.

The worst offender for me are reactive stores. I'm reviewing a simple candidates' programming assignment (in Angular, though). There is a simple taks to perform. The horrendously complicated and generally broken ones are those where the candidates decided to use a reactive store. Just tons of unnecessary code impossible to follow and decipher.

That’s usually down to the developer. Not the tooling.

So many of your points are strawmen.

> every month new libraries you have to use, always a new framework or cloud service on the horizon, always a new hype in the making

Did your job actually make you switch frameworks or use new libraries every month? Or is this just a trope you're repeating. That's not a problem with JavaScript, but a problem with your management.

And BTW, there are three big frameworks that are all like 5 or 6 years old. React isn't exactly new.

> Think you can still write in the old fashion? Nope, PR declined!

I read posts every day where people talk about JavaScript's horrible language design. Now the language is expanding and solving a lot of those problems, all while maintaining full backwards compatibility, and you're complaining that it changes too often? The last major language update was in 2015, and everything else has been an annual gift of a couple of new features, all of which are developed with the input of the community, and you're still complaining?

The truth is, a lot of people are using JavaScript and it's very flexible, so, yeah, people come up with design patterns all the time. Some of them are good and stick. Some of them are not. But part of the fun of being a JS dev is you can choose to explore that or not.

> JS is deprecated, it's Typescript now!

TypeScript isn't my thing, but again, people are constantly complaining about JavaScript for not having classical language features like strong types. Then an alternative comes out, and is embraced by a large portion of the community, and again with the complaining! Just don't use it! And BTW it seems bizarre to complain about TS being too verbose when you are a C++ dev.

I'm not saying you can't enjoy C++ but your reasons for hating JavaScript just sound like repeated tropes. If you get better at the language (and this applies to TS too), it will stop being so opaque.

Respectfully, I think it's unfair to say these are straw points. Perhaps there is some hyperbole in suggesting you need to use every new framework. You really do not. But as devs we are highly encouraged to stay abreast of these sorts of shifts. The industry is always in motion, and modern JS can be particularly brutal. In fact, ECMAScript itself recently moved to a much more rapid release cycle.

The market, if not your particular company, requires that you know the latest iterations/tooling of your chosen framework. Even if you're not forced to use the very latest versions, just being aware of all of that movement has cognitive overhead. If you choose not to pay much attention, you can quickly fall behind the curve. There is an inherent anxiety to that reality, whether it's legitimate or not.

Multiply the number of different tools in a given stack by the frequency of major updates to each, breaking changes between different tool/plugin versions, and you can start to grasp why people often complain about FE dev. These tropes are repeated for a reason.

> I guess the title is inappropriate, JS is deprecated, it's Typescript now! Not sure for how long, but the jobs where you can write JS are disappearing. So web developers are now forced to write in another language, with all it's brand new issues and pain points. Nice! Did I have problems with types in JS? Hardly, but that doesn't count, I now write about 20% more code to get the same result and regularly spend a few hours to get a basic line of code working because the TS compiler complains.

Typescript is a superset of JavaScript and your type issues could just be because you lack understanding of how type coercion works in JS. Additionally your tsconfig settings could be overly strict.

I had a similar experience when switching from JS to Dart. I am not using any framework just plain old DOM as my projects tend to be smallish. But programming in Dart is a real joy.

> Not 1 year you can write the same kind of code (professionally), every month new libraries you have to use

Huh, that's weird, because I've been writing in Angular & React and using the same basic libraries for years now. And before that it was jQuery and Handlebars and a lot of the same basic libraries for years.

I've made two large shifts in JS development over a decade.

Not sure why you seem to need to switch every month?

What I'm hearing you say is that the rapid increase in flexibility of choice within the JS ecosystem has a tradeoff of enabling dilettantes to further muddle the mixture.

I would argue that we should not be intentionally relying on technical design decisions to bust through difficulties which are more related to human factors and office politics than software architecture or implementation.