Hacker News Reader

Comment by azangru | Hacker News Reader

> Frankly the tooling around JavaScript is horribly confusing, especially for someone who learned HTML 22 years ago.

Why wouldn't the said someone take a day or two to update themselves on javascript tooling in order to get less confused? There are so many great resources available.

View on HN

The browser itself takes far longer than a day or two to learn to program even without tooling, considering that content is roughly the size of MDN; there is so much js tooling and documentation and of such wide variety that a year or two would not be enough for even a light review (roughly the content of github/js). And even that is not enough time to develop heuristics for deciding between approaches. And it doesn't begin to touch tooling, like editors, or deployment and runtime.

Here is a video of a lovely man who invented Erlang, Joe Armstrong, expressing confusion about how to build a "modern" javascript program: https://www.youtube.com/watch?v=lKXe3HUG2l4 (hilariously he was using grunt - a tool which is now entirely out of favor).

Come on, this isn't that hard if you have minimal, or even outdated, web dev knowledge. There is like 3 major frameworks (Angular, React, Vue). Spend a few hours to look how it is to work with each one, make your choice and follow a tutorial. Congrats, you've made your first Single-Page App.

Of course if you've never written a line of code in your life, or if you're angry at the thought of using a dependency manager, you're going to have a hard time. And not only with the web stack.

In their defense it’s been a year and I’m still learning React. Please don’t act like it’s something you understand in a few hours because it’s not. You might be able to copy-paste the example code and get something that works and sorta seeing what happens but to really understand takes a lot of time.

Assuming that this vanilla js should be familiar for anyone who has only ever written js that interacts with the DOM api:

    document.body.innerHTML = `
      <div>
        Hello world
      </div>
    `;

the React equivalent is no more complex:

    const HelloWorld = () => (
      <div>
        Hello world
      </div>
    );

    ReactDOM.render(<HelloWorld />, document.body);

Add to this a couple of high-level concepts, i.e. that a React component re-renders if its arguments (props) or its internal state change, and you are 70-80% there. Learn the useState and the useEffect hooks, and you are ready to be productive. If you aren't ready for build tools yet and just want to play with the library, take Preact, which has a syntax option that does not require a build step [0]

How many hours should this take?

[0] https://preactjs.com/guide/v10/getting-started

The problem is that React might not exist over a couple of years.

I program for decades. Most of my old stuff using frameworks - say for example, Angular or Jekyll - doesn't work anymore. If I update I end up in a dependency hell that's even worse. It's like XSLT in XML. It will pass. :-)

> The problem is that React might not exist over a couple of years.

I agree with you in principle, but I think I disagree in details. Programming using standard web apis certainly feels more future-proof, and all the power to those who have adopted web components. But React doesn't look like it's going away within the next decade. And even if Facebook somehow implodes, and no other company steps up to support the work of the React core team, React's api has been copied by Preact, which has Google's backing; and JSX has spread even wider. Importantly, React in itself is larger than DOM — it is a reconciler that can be used for canvas/webgl (react-three-fiber), for mobile applications (react-native) and windows applications (react-native-windows). So there is a good indication that React will be with us for a while.

But again, I completely agree that many projects that get started with React don't need to have been.

> I program for decades.

Two decades ago, Perl was a good choice :-) And look where it is now.

We are lucky with the rigorous backwards compatibility of HTML, CSS and javascript. But planning for decades may be a bit of an extreme. I wouldn't like to inherit a frontend project that was written two decades ago and hasn't changed since then.

And yet you completely just proved my point.

If you think one gets to know React or Angular because one can follow a "Getting Started" tutorial for a couple of hours and get it to show an example page then you're in Dunning Kruger territory.

I never said that a tutorial was enough to master a framework, please.

The comment I was replying to was saying:

> there is so much js tooling and documentation and of such wide variety that a year or two would not be enough for even a light review

There's no need to learn the entire ever-evolving JS ecosystem. You pick a sane starting point (a framework tutorial) to get you up and running in a few days, and from there you learn what you _need_.

The trouble for newcomers starts at _which_ framework to hang your hat on. Unless that decision has been made for you by your employer choosing between, Vue, React, Svelte, Alpine, Angular or some additional ankle biters is overwhelming. What's the selection criteria? What's the payoff vs complexity cost of each? What's the support level? Is it coming in vogue (Svelte) or out of fashion (Angular)? Does it mandate additional tools/transpilers/packagers etc and how many? How hard are they to learn? Do they play well with some other tooling that is being used (say Typescript)? Finally how does it all get packaged as an app/website to publish?

It's a complicated mess and even seasoned JS developers struggle to answer the above questions. Oftentimes the justification for choosing a framework is that they had read about it in a forum like HN and wanted to try it. Nothing wrong with that for someone who lives and breathes those things but most people want to just get a CRUD UI up, these things are a massive time sink for what they purport to offer.

If, like you say, these people aren't frontend specialists and don't pick frameworks on the basis of what appears on the front page of HN, why should they reach for a framework as their first port of call anyway? Many conversations on HN seem to turn into an argument between old-school developers, who declare that there's nothing better than good old jquery and Bootstrap, and more hip developers who immediately drag in React, Vue, or Svelte. The middle-ground option of starting with plain modern JS and plain modern CSS is offered relatively rarely. Which is strange — this should be the default for those who are disoriented by the plethora of options on the frontend.

Especially since you suggest that such developers just need to get a CRUD UI up and running. You don't need a js framework for that.

So I've looked into React and the problem I have with it is that it's lauded as "simple" because it's "just a view kit."

However, there are an infinite amount of questions one has to answer when starting a new project:

- I see that state management libraries are in a lot of tutorials and talked about online. Which one do I pick? Redux? MobX? Something smaller? Do I skip it entirely? What are the consequences of that?

- Okay, so how do I deliver "pages" in React? Do I pull in React Router as well? I saw an article on using Hooks to replace RR. Do I do that instead?

- How do I handle authentication? Do I use JWT? Which library? I saw some comments on Hacker News that says JWT is terrible. Do... do I pick something else? I kind of need auth so I cant's skip it. What if I need to do OAuth?

- Do I use TypeScript? What is the scope of work for implementing it into my build pipeline? Is it worth it?

- Build tools. Sure, WebPack is the most popular but a lot of tutorials are for outdated versions. A lot of the times I'm googling "how do I do X webpack" and just get different JSON blobs to plug in.

It's just... so much. I just don't care. I don't want to configure Gulp or WebPack or whatever. I don't want to extensively research every dependency I have to pull in to get a working app. There is Facebook's create-react-app and that's a good start. Vue and Angular don't suffer as much from this because they focus more on being complete packages.

Doesn't matter to me though. Phoenix LiveView provides enough interactivity for me.

All fair questions :-) But you don't sound like a frontend developer. Are you writing something with a UI so complex that you would need React, Vue or Angular to implement it?

Because one tried and the ecosystems is such a mess that there's no real logical place to start.

If you are tainted by old knowledge, then there are things that you wouldn't even imagine is required. Why to I need NPM? JQuery and Prototype didn't need a package manager. You have a ton of tools, different tools for different frameworks even.

The more I look into modern JavaScript the more confused I get.

> Why to I need NPM? JQuery and Prototype didn't need a package manager.

But that is a question that can be asked of any language. It's a given that any modern language would have a package manager. Ruby has gems, python has pip, rust has cargo, and so on. PHP didn't use to have a package manager, to the chagrin of many professional web developers, until finally there was Composer, and the php community breathed a collective sigh of relief. Package management is good. It helps you define all your project dependencies in a sane way in a configuration file, and put that in source control, rather than download all the dependencies locally and store those in source control.

Javascript had different package managers. It had bower. It had meteor packages. It had something else as well. It had different module formats. It has a rather convoluted history. Luckily, with the popularity of node, we now have only a couple — npm and yarn. Or just one, which is npm, if you consider only the standard tools that come bundled with node.

My last job did not use maven. We checked in the required jars into the repo and everyone cloned their copies from there. Builds took seconds and were always predictable.

My current job uses maven and I'd swear a good 20-30% of developers time is spent wrestling with maven dependencies. Especially on a new project.

> there's no real logical place to start

One way — if you are at all interested that is — is to look for someone who can guide you through the current tooling landscape. For example, I believe Cory House's course on Pluralsight on choosing appropriate tools for a frontend project [0] should be informative in this regard. There are also free tutorials about this subject — for example on egghead.io [1]

The other way is to find the documentation on any of the popular tools: webpack, rollup, snowpack, vite, esbuild, etc. — and just follow along trying to set up a toy project and, by doing so, figuring out what the purpose of the tool is. See the recent Google's site on the comparison of modern tools [2] to find out what each of the tools is supposed to do for you:

[0] https://www.pluralsight.com/courses/javascript-development-e...

[1] this one might be useful: https://egghead.io/courses/how-to-use-npm-scripts-as-your-bu...

[2] https://bundlers.tooling.report

If what you're primarily building is a web page with light interactivity, there's nothing wrong with jQuery (or a more declarative modern alternative like Alpine.js). React et al are intended for applications with enough complexity that trying to manage it procedurally becomes miserable and unmaintainable.

There's a lot wrong with how npm is used (primarily the never-ending recursive dependencies making proper auditing of the code you use all but impossible), but including tons of script tags on every page and hoping you got the right plugin order without introducing any conflicts was hardly the pinnacle of development.

There are two problems with modern JS, imo. First is all the people insisting you need to use some grotesquely complex setup running on Kubernetes to host a blog that gets a hundred page views per month. The second is that most frontend frameworks want to take over your entire app, and in some cases really want your backend to be running node too. It's usually possible to start small and enhance as you go, but it's not easy.

Reply on news.ycombinator.com