Hacker News Reader

> and now ES6 classes and all the rest are deprecated, because Dan Abramov had another idea for again a new design principle that's just less than a year old: Hooks.

This is so off the mark it’s not even funny.

- Dan did not develop the hooks api

- he is also on record saying that people don’t need to re-write their components with hooks

- class components have not been deprecated in React

It is indeed not funny, and you're off the mark as well:

> Dan did not develop the hooks api

I didn't say he developed it

> he is also on record saying that people don’t need to re-write their components with hooks

So? In my daily work I see it all the time. You think I have a say in that when I have a gig at company X?

> class components have not been deprecated in React

You've got a point there, indeed not officially deprecated, but in practice(again) at company X, you cannot do classes anymore.

Annoying, but sometimes a better idea comes along. I think me and many others initial reaction to the hooks presentation was 'yeeaaaassss'. Still in mostly es6 class codebase of course, so haven't had a chance to do too much with them yet, but as long as they're not gonna break backwards compatibility, yes please.

If people won't even listen to the developers of the tools they use, and insist on "out with the old, in with the new" when those developers are pleading with them not to create extra work for themselves... Whose fault is that?

There are even linting rules to ban use of class components, IiRC.

You’re not wrong. Hooks are being pushed HARD for new code.

Honest question - what’s the point of all this change? At the end of the day, people are building web pages with these frameworks?

John Carmack has an excellent article on static analysis (unrelated to this topic), but there’s this excellent quote:

>It is important to say right up front that quality isn't everything, and acknowledging it isn't some sort of moral failing. Value is what you are trying to produce, and quality is only one aspect of it, intermixed with cost, features, and other factors.

These JS frameworks and build tools provide far more than just code quality, but what all benefits are they providing that outweigh the cost of, “here is XYZ that you must now figure out, and before you can figure out XYZ, you need to learn A, B, and C”. Stated differently, what exactly is the value?

Junior developers make this mistake and unfortunately so many more tenured developers as well. I can understand you want to use the shiny new thing. How often do you replace your toilet or kitchen sink though? Is it worth it?

To me, the JS ecosystem has become to complex. Even if you’re building for Amazon or Google scale, you want to think twice about not only the shelf life of these various frameworks but also what are their dependencies, what are their failure modes, and at the end of the day, how are they giving you an ROI if you use the new X framework of the month or year CS Y.

Nothing like that has happened in the Angular ecosystem, the API is stable for 3 years, and a pleasure to work with.

I think this obsession with functions and the functional paradigm is counterproductive in the React ecosystem.

Sometimes, the best way to represent something is a class. When you have some data and a series of closely related fucntions that modify the data and are highly related to the data, it's better to use a class.

This hooks API thing is anything but functional, way too much magic. Its stateful programming diguised as functional.

Indeed, hooks are pretty much the furthest thing from functional programming there is. In functional programming, functions can safely be called any number of times from anywhere in the program, and they'll always return the same result for the same arguments.

Hooks, on the other hand, crash and burn at runtime if you call them outside a React component function, or in a different order or number from how you called them the first time your component was rendered.

TypeScript was and still is a very necessary addition over plain JS, but everything else you said is spot on. This ecosystem is very much a Red Queen's race, you have to learn all sorts of tooling that will be deprecated and forgotten in two years or less.

The thing is, we don't need to learn Bazel either. We will just keep running the command "ng build", and internally the CLI will be using Bazel instead of Webpack, but that is transparent for us users.

We only see the CLI commands on our end, and the Angular CLI internally will use whatever build tool is best for the job at a given time, and will keep evolving over time.

It's such a relief that we don't need to learn build tools in the Angular ecosystem anymore and can focus on application development only.

Sure... I have never heard of Bazel, but it sounds very black boxish (JS goes in bundles come out!). That is basically the same thing webpack promised in comparison to gulp/grunt. A lower config JS build tool, which is always great until it isn’t. At a certain maturity you will need to dig into your projects build tool.

Bazel is the open source version of googles interns build tooling. It’s not new, but using it outside of google is. It’s also not JavaScript specific, it’s completely language agnostic. You define the rules for building, and bazel will execute it. You can run your entire companies build system off of it.

Sounds like Make

It covers a lot of the same ground, but IMO is much easier to use all around.

> At a certain maturity you will need to dig into your projects build tool

The command "ng build" takes in typescript and produces optimized lazy-loaded bundles, and there won't be the need to customize that, there aren't a thousand ways to produce bundles after all, there is one optimal way for a given ecosystem, and it does not make sense for each project to reinvent a build system that all it does is transpile, concatenate, minify, compress, etc. like every other project.

Any additional build steps besides bundling are usually very simple can often be done either via npm scripts, or a simple shell script.

Can you give examples of things for which you would absolutely have to customize the build system?

Code splitting, live reload, things that come up like: we have some components that are using react native web, they will be imported into both web and native mobile applications, how do we prevent native sub dependencies of that component from being imported? What if you have multiple bundles but only want angular in one?

The Angular CLI has support for both code splitting and live reload out of the box. ng build creates the main bundle plus the lazy-loaded bundles, and ng serve spins up a development server with live reload ready to go.

The Angular CLI also supports multiple applications with shared components. You can build a web application that uses shared components, and a separate mobile application that uses the same shared components and has its own separate build.

The React and Vue ecosystems are going in the same direction with their CLIs, but I don't think the Vue CLI or create-react-app are quite as powerful yet.

Once they are, it will be the end of tooling fatigue, and no one will have to create their own custom build anymore (other than a shell script or so).

Until you want something that’s a liiitke bit different than what the dev’s usecase was

> Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only gets worse.

No comment regarding the "peak" but 3 years ago is when the very influential How It Feels To Learn JavaScript In 2016 post came out. https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

None of the tools you mentioned are unsupported as of now, though. I recently updated a browserify based project from years ago to 16.3 in an afternoon and it just worked.

I remember the days I was afraid to do npm update the dependencies, I was copy pasting build script configurations for new projects, I used to use code mods every other month to make huge refactors (and badly), packages disappearing, every project inventing how to manage state (not just react)... All of this is past for me. Yeah of course it's just a data point but there's the fact that you can start a complex web app project with one command these days and not care about core dependencies. I expect it'll go only better. Maybe it's me getting experienced but I certainly wasn't a beginner few years ago, not even close. I'd love to hear what kind of difficulties you are having with your projects though, it's very possible that I'm missing something.

> None of the tools you mentioned are unsupported as of now, though.

I mean working as a professional, doing my next gig. Do you think I can still use my Grunt or Gulp skills there? The landscape is now again very different than it was a year ago. I cannot even code in ES6 anymore, all the jobs are TS and React Hooks at the moment. When I say I prefer JS over TS my colleagues think I'm not smart and skilled enough to understand the benefits of TS. There is not much choice unfortunately, independent of being supported or unsupported.

React Hooks doesn't preclude ES6 though?

Really, they're just functions that have some weirdness/magic about when you call them.

I love them, but that's not really what this thread is about, of course:)

It's not like you've been coding with Javascript and now you need to learn Haskell though. Companies love to sprinkle newest trends in their job ads with the technologies they used in their last 100 LOC pilot project and you discover in your first day that there are many big projects which use gulp, grunt and others with ES3, some without async support etc.

I got a friend in Silicon Valley (I'm in Germany and here the attitude is more towards reliability and stability) and even there he got many interviews and a new job without listing many of the newest libraries/languages in professional capacity.

Plus, I'd suggest you try Typescript with an open mind. It's amazing.

I happen to be in the interview gauntlet at the moment for full-stack JS type jobs so I hear what you are saying but it seems to cut both ways.

Most places using React are expecting me to be familiar with hooks and everyone using Javascript is asking about familiarity with Typescript. But at the same time they genuinely seem impressed/surprised that I have been using async/await for over a year on my latest professional projects.

I want to say this in a nice way but it is difficult. I feel Javascript developers suffer from an inferiority complex. It's like they need to feel what they are doing is "real code" or something. That seems to translate in this crazy pace of replacement of technologies. I think it gives the impression of innovation. To me it feels like an unsteady eco-system still trying to find its footing. The vacillation from OOP to functional and back again feels like uncertainty. From DIY systems like gulp to all-in-one systems like webpack. It's a sector full of people desperate to look like they know what they are doing while they act like they are still trying to figure it all out.

All that being said, working in JS in 2018/2019 is significantly more pleasant than it ever was in the past. I find creating back-end Node.js services to be quick and easy and writing front-end systems using React bearable. Despite high volatility there is definite progress.

While the JavaScript ecosystem is on the volatile side, learning new tools and frameworks every few years is just part of our job. Only in very boring tech jobs would you only have to learn new things maybe once every 5 years.

I wouldn't really bother wasting time "mastering" something like Webpack or what replaces it - as the other commenter said we just end up using an abstraction over it anyway.

The problem with changing tools to fend off boredom is that it has a very short lifespan. Pretty quickly your brain realizes that it's not learning anything fundamentally new and it protests. Hence fatigue. If possible, it's better to focus on the problem domain and try to make the best of that for entertainment. If not then maybe just accept that it's better to be a bit bored than fatigued.

It’s not learning a new frameworks and tools. It’s the fact that these tools are usually fragile, and quite frankly not very much new is in there.

Also, what’s your goal? To learn new tools over and over again? Or to crate something that that people will use?

You sound like a music “producer” (read - tech hobbiest) who keeps switching tools, synths, and hardware instead of just creating music.

Yes, I don't even think the most important issue is that we as developers have js fatigue. The biggest issue is that we are developing web applications that are outdated before they are even released. Our software relies on thousands of dependencies that are constantly changing or even dying off. Updating an application that was built two or even just one year ago is often not a trivial task. So while the frameworks and tooling have thankfully improved, in general the cost of developing and maintaining an application seems to be much greater than in the past (e.g. PHP MVC app with some jQuery sprinkled in).

It's blogs and sites like Udemy. Their business model depends on people needing to learn new technologies constantly. So when they tell you "MVC is dead" or "Rails is dead", there is a direct profit motive in it for them. They tell you everyone is using Backbone.js, so you move. Then the next year it's Angular. Backbone is outdated, no one uses it anymore. Then the next year it's React.

The blogs drive the technology shifts in order to get clicks. And every time the technology shifts, Udemy sells a million tutorial videos at $10 a piece. Everyone gets up to speed on the new thing just in time for the blogs to find new clicks and Udemy to find new videos.

Meanwhile the real world still runs on Laravel, Rails, Flask, and Postgres.

The reality of the situation is that JavaScript was designed at a time when there was NO CLUE that it would become the de-facto client-side language for decades.

So now the ECMAScript standard is pushing JavaScript towards a "proper" language, but we need additional tools (TS, Babel, etc) to write in an even more "proper" language/syntax that will give us something that the browser still needs to understand (JavaScript).

This isn't a fun process for those of us who have been developing a long time. Look, JavaScript has classes! And modules! Ok, that's good I guess, we're getting there. But that's not learning, that's just getting closer to something we are already familiar with as software engineers.