8 ms·

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

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

javajosh 6y ago
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 https://www.youtube.com/watch?v=lKXe3HUG2l4 (hilariously he was using grunt - a tool which is now entirely out of favor).
- scambier 6y ago
  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.
  - dawnerd 6y ago
    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.
    - azangru 6y ago
      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 https://preactjs.com/guide/v10/getting-started
      - MrQuincle 6y ago
        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. :-)
        azangru 6y ago
        > 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.
  - abraxas 6y ago
    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.
    - scambier 6y ago
      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_.
      - abraxas 6y ago
        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.
        azangru 6y ago
        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.
  - OhSoHumble 6y ago
    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.
    - azangru 6y ago
      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?
mrweasel 6y ago
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.
- azangru 6y ago
  > 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.
  - abraxas 6y ago
    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.
- azangru 6y ago
  > 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-environment 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-build-tool https://egghead.io/courses/how-to-use-npm-scripts-as-your-bu... [2] https://bundlers.tooling.report https://bundlers.tooling.report

javajosh 6y ago

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 https://www.youtube.com/watch?v=lKXe3HUG2l4 (hilariously he was using grunt - a tool which is now entirely out of favor).

scambier 6y ago
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.
- dawnerd 6y ago
  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.
  - azangru 6y ago
    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 https://preactjs.com/guide/v10/getting-started
    - MrQuincle 6y ago
      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. :-)
      - azangru 6y ago
        > 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.
- abraxas 6y ago
  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.
  - scambier 6y ago
    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_.
    - abraxas 6y ago
      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.
      - azangru 6y ago
        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.
- OhSoHumble 6y ago
  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.
  - azangru 6y ago
    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?

mrweasel 6y ago

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.

azangru 6y ago
> 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.
- abraxas 6y ago
  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.
azangru 6y ago
> 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-environment 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-build-tool https://egghead.io/courses/how-to-use-npm-scripts-as-your-bu... [2] https://bundlers.tooling.report https://bundlers.tooling.report