4 ms·
> No one is going to remember all the packages they need to include each time they start a new project. They're doing what I'm doing; copy paste from the last p
by insin 10y ago
> No one is going to remember all the packages they need to include each time they start a new project. They're doing what I'm doing; copy paste from the last project, like some holy script scrawled by ancient masters from long ago.
If it hurts, don't do that then - put all your build stuff and devDependencies in a separate module and install it into your next project like any other development dependency, adding new capabilities as you need them and bumping the version number when you need to like any other tool. You can start doing it yourself [1] or use one someone else made earlier [2] - there are an increasing number of these toolkits about.
> But seriously I can't use `<SomeThing onClick={this.handleClick}/>`?
You can do exactly that if you're using React or one of the many libraries which use React-like conventions (Preact, Inferno, Mithril.js etc.), so just use one of them.
> But why do I have to write a cryptic webpack.config.js for every project? Why do I have to install Babel and webpack separately? Why do I need to install 3 other babel related packages? Why do I need a .babelrc? It's just insane. There should just be one tool, one command. "modernjs build". Done.
You don't have to, and there are lots of tools which will take care of this for you (see [2] again). That's the exact same workflow I wanted, so I created it for the types of projects I'm working on [3] - it doesn't take much extra effort to turn your own preferred build setup into a command.
[1] https://github.com/insin/ad-hoc-reckons/blob/master/CreatingReusableDevelopmentTooling.md#creating-reusable-development-tooling https://github.com/insin/ad-hoc-reckons/blob/master/Creating...
[2] https://github.com/facebookincubator/create-react-app#alternatives https://github.com/facebookincubator/create-react-app#altern...
[3] https://medium.com/@jbscript/quick-development-with-nwb-35f3fee5d837 https://medium.com/@jbscript/quick-development-with-nwb-35f3...
- fpgaminer 10y ago> You can do exactly that if you're using React No, you can't. This is broken: class Foo extends React.Component { render () { return (<SomeThing onClick={this.handleClick}/>); } handleclick () { this.setState (blah); } } It _shouldn't_ be broken. I don't agree with any arguments about the semantics of Javascript, this, scope, binding, etc. It's a pain point; something every developer runs into. It should be fixed. Instead, we have about 10 ways of working around the problem. In all the revisions of the Javascript that have gone by, nobody fixed this _very_ common usage of the language. Instead they just added more workarounds. > it doesn't take much extra effort to turn your own preferred build setup into a command. Here's the thing. Let's say, instead of selling people cars, we only sold parts. You shop on various stores for all the parts you need, depending on the kind of car you want, order them all, and then put the car together. The great thing about this is that every person gets exactly the car they want for their specific needs! And the people making the parts get to focus on a specific part, so the individual parts are will end up well designed and polished. For a car nut, that's probably great. But most people aren't car nuts. For everyone else, this system is terrible. They don't know how a car works. They go online, search around, get overwhelmed, and decide to just follow whatever random "Build a Car in 30 minutes!" guide they stumble on. They end up with a car at the end, and now they can do what they really want to do; drive from point A to point B and forget about building cars. Until one day the radio breaks. They look online for a replacement, only to discover they don't make that radio anymore. In fact, the new radios don't fit in their dash configuration. So after hours and hours scrounging through oiloverflow.com questions, they finally piece together how to replace their dash with a new dash, without having to replace their steering column configuration. Then they get their radio, and all is well. Except now they've missed the movie they were going to see with friends, so they just go to bed and don't even use the car. And the promise about each individual part being well designed and polished? It didn't pan out in practice. Some parts ended up really nice (React). Most parts just kept getting revised or forgotten and were never really thought through (react-router). Most developers just want to get from point A to point B. Go from idea to app. Fiddling with packages, compiler configurations, etc, is not productive for them. "it doesn't take much extra effort to turn your own preferred build setup into a command" is the equivalent of asking everyone to build their own car. Just give them a pre-made car! If they're the type of person to want to customize their build tools and environment, they'll do that. But don't foist that burden on every single developer.
- debaserab2 10y ago> I don't agree with any arguments about the semantics of Javascript, this, scope, binding, etc. It's a pain point; something every developer runs into. It should be fixed. Instead, we have about 10 ways of working around the problem. In all the revisions of the Javascript that have gone by, nobody fixed this _very_ common usage of the language. Maybe I'm not completely understanding you correctly, but es6 and es7 does fix many of these problems, doesn't it? In which case the problem is there is no way to make es6 or es7 code compatible with older browsers other than transpiling. I don't know how you fix that without a time machine.
- TomMarius 10y ago> In all the revisions of the Javascript that have gone by, nobody fixed this _very_ common usage of the language. It would break way too much of existing code.
- acemarke 10y agoAre you complaining that passing around a function reference doesn't maintain the `this` reference? That's... uh... just how Javascript works. That's how functions behave, that's how prototypal inheritance works, and the class syntax maintained that behavior for backwards compatibility. That has nothing to do with Webpack, Babel, React, or any other tool. That's part of the language syntax. There's several strategies for ensuring that `this` in a function refers to a particular class instance, particularly in a React app. The basic approaches are re-binding the function every time you re-render; binding each function once in the constructor; using a decorator or utility method to bind each function once; and using the Stage 2 Class Properties syntax and writing the function using the arrow syntax. See http://reactkungfu.com/2015/07/why-and-how-to-bind-methods-in-your-react-component-classes/ http://reactkungfu.com/2015/07/why-and-how-to-bind-methods-i... for an overview of the approaches.
- milesrout 10y agoIt's how it works, and it's wrong. It's incorrect. It's badly designed. It should be fixed. Let me write `'use sanity;'` at the top of a function (like `'use strict';`) and then let me use sane lexically scoped semantics.