7 ms·

One of the worst problems I see for the new JS developers is the tooling-overload. Being an experienced developer, I know why that tooling is required - but new

by smdz 10y ago

One of the worst problems I see for the new JS developers is the tooling-overload. Being an experienced developer, I know why that tooling is required - but new devs are just overwhelmed with the information out there (and understandably so). And most of the todo-list projects tend to over-simplify the tooling. It takes time to learn the tooling and understand its importance In a typical React app (+TypeScript), I have atleast 40 dependencies in package.json (frontend-only). I know exactly what each dependency is required for. And each time I have a new app, I create that package.json one line at a time - just to make sure I don't add unnecessary dependencies. But for a JS newbie, knowing what dependency is what and why - is pretty overwhelming, tedious and uncomfortable. This is assuming they already spent time learning JS and the frameworks in the first place. Its easier to give up that important learning when you have to deliver "just a landing page in Angular" and answer to managers. After few iterations, the result is a disaster that is difficult to maintain, buggy and much more difficult to add features. Ultimately that adds to the development/maintenance cost. I know why the JS tooling is complex, but sometimes I wish JS projects were as simple (and controlled) as creating C# windows apps using VS - where the tooling is mostly hidden

novaleaf 10y ago
I know js devs hate monolitic frameworks, but as I also come from C# land I find the cognitive cost of "what micro framework should I choose?" to be annoying. So I created my own monolithic framework (npm xlib) which is basically a collection of my commonly used modules and my own helper utils.
nip 10y ago
In the case of React, the team behind Create React App [1] is doing an excellent job at taking care of all the build system, with only one Dev dependency: a script, which allows developers to focus solely on their non dev dependencies while providing all the necessary tooling to focus on doing their job: crafting software. You can "eject" from this beginner friendly mode if you want to have more freedom. Funny thing is that we "ejected" on our current project, but I'm contemplating moving back to CRA as it just makes developing our React app super easy and stress-free. [1] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app
- smdz 10y ago
  CRA helps starters with plain React, but I believe CRA doesn't come in default with Redux (react-redux), react-router, redux-thunk. And useful (arguably opinionated) stuff is missing like react-hot-loader, redux-logger, sass-loader, font loaders, customized webpack and webpack-dev-server. Also it does not differentiate between smart and dumb components. For large complex SPAs, all that stuff is very useful.
  - acemarke 10y ago
    Correct, because none of those are needed for use with React itself, and different applications will use a wide variety of different libraries (Redux vs MobX, etc). Also, the phrase "doesn't differentiate between smart and dumb components" is pretty irrelevant in this discussion, because that's merely a conceptual distinction. I did actually open up a discussion a couple days ago asking for discussion on what kinds of "official Redux-based addons" might look like: https://github.com/reactjs/redux/issues/2295 https://github.com/reactjs/redux/issues/2295 . Possible ideas include things like a small "redux-starter" wrapper library that sets up a store with sensible defaults. Dan Abramov also tossed out a list of ideas for a hypothetical more in-depth integrated library built on top of Redux's core behavior.
  - nip 10y ago
    But that's the point of CRA, just taking care of the build tools. React-redux, React-router, Redux-thunk are all dependencies (as opposed to dev-dependencies/build utils) that might or might not be needed.
coldtea 10y ago
>One of the worst problems I see for the new JS developers is the tooling-overload. Being an experienced developer, I know why that tooling is required Being probably even more experienced (or at least older in the business) developer, I don't. :-)
- Yokohiii 10y ago
  I know babel is always required if the coder lives in the future and struggles with todays state of things.
  - acdha 10y ago
    Kind of but you can use it differently: I like writing pure modern ES6, APIs, etc. and using Babel only to compile ES5 + polyfills for old browsers. You can develop directly in most current browsers, avoid lengthy compile times, etc. and there's zero lock-in if you prefer a separate tool next year. That's quite different from some of the dreadnaught-weight frameworks which need a huge toolchain to run Hello World. That can be worth it if you have a huge complex application which uses all of that functionality but otherwise it turns simple projects into ongoing time commitments.
- nramadas 10y ago
  Most tools solve very specific problems that usually only matter on large scale production apps. Webpack, for example, is fantastic if you need to create split points in your code to absolutely minimize the amount of js you send to the client. Or, if there is a chunk of js code (like React, or jquery) that rarely changes and could benefit from being part of a separately cached bundle. IMO, the biggest problem the js world has is that the folks keep creating solutions for really _big_ problems, but no one cares about creating solutions for folks that just want to get something done quickly.
  - coldtea 10y ago
    >Most tools solve very specific problems that usually only matter on large scale production apps. Webpack, for example, is fantastic if you need to create split points in your code to absolutely minimize the amount of js you send to the client. Or, if there is a chunk of js code (like React, or jquery) that rarely changes and could benefit from being part of a separately cached bundle. Yeah, I know what they do and what they are used for. I don't know why they are needed. Browsers could have solved this problem from the start, with proper incremental module import syntax in JS scripts.
mrweasel 10y ago
>Being an experienced developer, I know why that tooling is required In terms of JavaScript I still don't understand why all that "tooling" is required. Every time I try to understand how the JavaScript tools fit together I end up just finding a .js file I can stick in the top of the HTML. The "install with npm" on a website isn't helpful at all, because I'm not doing Node, I'm just building a website and doesn't want Node. What would help is a big poster, showing how stuff fits together. Grunt, Bower, Node, NPM, it's just a big pile of confusing.
- acemarke 10y ago
  I recently gave a "Modern Web Dev Overview" presentation that talks about the history of web dev technologies, the problems that these tools are trying to solve, and how they fit together. You might find it useful: http://blog.isquaredsoftware.com/2016/10/presentation-modern-web-dev-overview/ http://blog.isquaredsoftware.com/2016/10/presentation-modern... . Also, the "Basic Concepts and Overviews" section of my React/Redux links list points to a number of other articles that describe what these tools are: https://github.com/markerikson/react-redux-links/blob/master/basic-concepts.md https://github.com/markerikson/react-redux-links/blob/master... . To pick out just one as a good reference, see "The State of the Javascript Landscape in 2016": http://www.infoq.com/articles/state-of-javascript-2016 http://www.infoq.com/articles/state-of-javascript-2016 .
- 91bananas 10y ago
  Don't think of Node as a web server, that's what I'm guessing your understanding of it is. Think of it as a copy of JS that is available on your machine. NPM is a package manager for you guessed it, Node. You use it to install dependencies, whatever those might be for your situation. I will ignore Bower. Grunt is a task runner, say you have a task like minifying javascript files. Grunt runs this task for you. Or CSS preprocessing, any task, it'll run it. There are other things in this space too. Grunt, gulp, webpack, browserify, etc. The pieces aren't that hard to understand, you just have to read what they do. Sure you can stick a JS file in an HTML file and you're good, but when you start building more complex apps where you need common code in parts, specific code in others, this becomes ridiculous to do by hand, that's why we have build tools.
iSnow 10y ago
JS held a lot of appeal for me - coming from the Java world - because you didn't need a lot of tooling but basically a text editor and a browser. Add a handful of libraries and I started liking that goofy little language. Of course that setup still works, but if you want to do anything a bit more advanced, you descend into a living hell that feels as complicated an impenetrable as J2EE did. As clunky as the JCP is, in the last years it helped create a couple of sane standards from existing implementations. I just wish there was something similar in JS world.
- z3t4 10y ago
  I also like that all you need is a simple editor and a browser or NodeJS or both. I think the problem is going from writing static or server rendered HTML into making a web/js app, you try to reuse the design patterns from server HTML rendering, witch is like using the wrong side of a hammer. If you write a web/JS-rendered app all the HTML you need is <script src="main.js"></script>
abustamam 10y ago
I wish you could write comments in JSON files... What I would give to write the reason I kept this package at version 0.9.1 instead of upgrading to 1.0.0... But it would also be useful for onboarding new members.

by smdz 10y ago

novaleaf 10y ago

I know js devs hate monolitic frameworks, but as I also come from C# land I find the cognitive cost of "what micro framework should I choose?" to be annoying. So I created my own monolithic framework (npm xlib) which is basically a collection of my commonly used modules and my own helper utils.

nip 10y ago

In the case of React, the team behind Create React App [1] is doing an excellent job at taking care of all the build system, with only one Dev dependency: a script, which allows developers to focus solely on their non dev dependencies while providing all the necessary tooling to focus on doing their job: crafting software. You can "eject" from this beginner friendly mode if you want to have more freedom. Funny thing is that we "ejected" on our current project, but I'm contemplating moving back to CRA as it just makes developing our React app super easy and stress-free. [1] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app

smdz 10y ago
CRA helps starters with plain React, but I believe CRA doesn't come in default with Redux (react-redux), react-router, redux-thunk. And useful (arguably opinionated) stuff is missing like react-hot-loader, redux-logger, sass-loader, font loaders, customized webpack and webpack-dev-server. Also it does not differentiate between smart and dumb components. For large complex SPAs, all that stuff is very useful.
- acemarke 10y ago
  Correct, because none of those are needed for use with React itself, and different applications will use a wide variety of different libraries (Redux vs MobX, etc). Also, the phrase "doesn't differentiate between smart and dumb components" is pretty irrelevant in this discussion, because that's merely a conceptual distinction. I did actually open up a discussion a couple days ago asking for discussion on what kinds of "official Redux-based addons" might look like: https://github.com/reactjs/redux/issues/2295 https://github.com/reactjs/redux/issues/2295 . Possible ideas include things like a small "redux-starter" wrapper library that sets up a store with sensible defaults. Dan Abramov also tossed out a list of ideas for a hypothetical more in-depth integrated library built on top of Redux's core behavior.
- nip 10y ago
  But that's the point of CRA, just taking care of the build tools. React-redux, React-router, Redux-thunk are all dependencies (as opposed to dev-dependencies/build utils) that might or might not be needed.

coldtea 10y ago

>One of the worst problems I see for the new JS developers is the tooling-overload. Being an experienced developer, I know why that tooling is required Being probably even more experienced (or at least older in the business) developer, I don't. :-)

Yokohiii 10y ago
I know babel is always required if the coder lives in the future and struggles with todays state of things.
- acdha 10y ago
  Kind of but you can use it differently: I like writing pure modern ES6, APIs, etc. and using Babel only to compile ES5 + polyfills for old browsers. You can develop directly in most current browsers, avoid lengthy compile times, etc. and there's zero lock-in if you prefer a separate tool next year. That's quite different from some of the dreadnaught-weight frameworks which need a huge toolchain to run Hello World. That can be worth it if you have a huge complex application which uses all of that functionality but otherwise it turns simple projects into ongoing time commitments.
nramadas 10y ago
Most tools solve very specific problems that usually only matter on large scale production apps. Webpack, for example, is fantastic if you need to create split points in your code to absolutely minimize the amount of js you send to the client. Or, if there is a chunk of js code (like React, or jquery) that rarely changes and could benefit from being part of a separately cached bundle. IMO, the biggest problem the js world has is that the folks keep creating solutions for really _big_ problems, but no one cares about creating solutions for folks that just want to get something done quickly.
- coldtea 10y ago
  >Most tools solve very specific problems that usually only matter on large scale production apps. Webpack, for example, is fantastic if you need to create split points in your code to absolutely minimize the amount of js you send to the client. Or, if there is a chunk of js code (like React, or jquery) that rarely changes and could benefit from being part of a separately cached bundle. Yeah, I know what they do and what they are used for. I don't know why they are needed. Browsers could have solved this problem from the start, with proper incremental module import syntax in JS scripts.

mrweasel 10y ago

>Being an experienced developer, I know why that tooling is required In terms of JavaScript I still don't understand why all that "tooling" is required. Every time I try to understand how the JavaScript tools fit together I end up just finding a .js file I can stick in the top of the HTML. The "install with npm" on a website isn't helpful at all, because I'm not doing Node, I'm just building a website and doesn't want Node. What would help is a big poster, showing how stuff fits together. Grunt, Bower, Node, NPM, it's just a big pile of confusing.

acemarke 10y ago
I recently gave a "Modern Web Dev Overview" presentation that talks about the history of web dev technologies, the problems that these tools are trying to solve, and how they fit together. You might find it useful: http://blog.isquaredsoftware.com/2016/10/presentation-modern-web-dev-overview/ http://blog.isquaredsoftware.com/2016/10/presentation-modern... . Also, the "Basic Concepts and Overviews" section of my React/Redux links list points to a number of other articles that describe what these tools are: https://github.com/markerikson/react-redux-links/blob/master/basic-concepts.md https://github.com/markerikson/react-redux-links/blob/master... . To pick out just one as a good reference, see "The State of the Javascript Landscape in 2016": http://www.infoq.com/articles/state-of-javascript-2016 http://www.infoq.com/articles/state-of-javascript-2016 .
91bananas 10y ago
Don't think of Node as a web server, that's what I'm guessing your understanding of it is. Think of it as a copy of JS that is available on your machine. NPM is a package manager for you guessed it, Node. You use it to install dependencies, whatever those might be for your situation. I will ignore Bower. Grunt is a task runner, say you have a task like minifying javascript files. Grunt runs this task for you. Or CSS preprocessing, any task, it'll run it. There are other things in this space too. Grunt, gulp, webpack, browserify, etc. The pieces aren't that hard to understand, you just have to read what they do. Sure you can stick a JS file in an HTML file and you're good, but when you start building more complex apps where you need common code in parts, specific code in others, this becomes ridiculous to do by hand, that's why we have build tools.

iSnow 10y ago

JS held a lot of appeal for me - coming from the Java world - because you didn't need a lot of tooling but basically a text editor and a browser. Add a handful of libraries and I started liking that goofy little language. Of course that setup still works, but if you want to do anything a bit more advanced, you descend into a living hell that feels as complicated an impenetrable as J2EE did. As clunky as the JCP is, in the last years it helped create a couple of sane standards from existing implementations. I just wish there was something similar in JS world.

z3t4 10y ago
I also like that all you need is a simple editor and a browser or NodeJS or both. I think the problem is going from writing static or server rendered HTML into making a web/js app, you try to reuse the design patterns from server HTML rendering, witch is like using the wrong side of a hammer. If you write a web/JS-rendered app all the HTML you need is <script src="main.js"></script>

abustamam 10y ago

I wish you could write comments in JSON files... What I would give to write the reason I kept this package at version 0.9.1 instead of upgrading to 1.0.0... But it would also be useful for onboarding new members.