241–250 of 250 posts
npm install -g react-app-tools
react-app new
react-app start
Earlier quoted context omitted.
One thing though, is that the standard classes are just not up to the job without a lot of stuff tacked on. Eg: the function binding problem pushes people to use class properties, which aren't yet a standard, and then they hit walls with tools that don't support them (eg: I dunno if it's still the case, but for a while class properties caused issues with Flow). createClass might not have been the answer, but on top o…
There was not such thing like ES3 module syntax. This is just programming pattern many people used: https://addyosmani.com/resources/essentialjsdesignpatterns/b... It was a great idea back then, but that was never syntax. This and similar patterns rely on the fact JavaScript is very dynamic and flexible language and enables creating closures and creating objects dynamically. These are very powerful features of langua…
Earlier quoted context omitted.
There was not such thing like ES3 module syntax. This is just programming pattern many people used: https://addyosmani.com/resources/essentialjsdesignpatterns/b... It was a great idea back then, but that was never syntax. This and similar patterns rely on the fact JavaScript is very dynamic and flexible language and enables creating closures and creating objects dynamically. These are very powerful features of langua…
Classes don't do anything about the dynamic nature of JavaScript. They spit out basically the same constructor that everybody was using for pseudo-classes in ES5. You can still do crazy things like manipulate the prototype outside the class, tack extra stuff onto instances after they've been instantiated and so on... In other words, classes in JavaScript are a poor substitute for static types, and should not be used…
class Foo {... }
// then, after class definition
Foo.A = X;
Foo.B = Y;
etc.
So... it seems that every try to make JS more static is doomed to fail... Because people will still use it in dynamic way...
Not sure how to solve this problem. Maybe we really need tooling that would run code in sandbox instead of analysing it via AST (but how to sandbox e.g. NodeJS code that interacts with file system or MongoDB? Mocking everything? Or make complete dev environments/virtual machines with NodeJS code running in it?)
(Maybe I overengineer solution ideas in my head, but I think proper tooling support is important for modern web development. It hurts me when I have to learn new large JS codebase and IDE is not helping)
> That's why a lot of React people are using flow, and a lot of Angular people are using TypeScript.
I don't like the idea of defining types for everything but maybe it's the solution (I'm not sure because I have too little experience with TypeScript to judge).
Earlier quoted context omitted.
We discussed this on Twitter Dan, fyi, no need to rehash here. But they very fact you had to spend time abstracting away WebPack speaks volumes IMO...
Sorry, didn’t realize it was you :-) >But they very fact you had to spend time abstracting away WebPack speaks volumes IMO... Speaks volumes about its poor public API. I don’t understand how this this affects create-react-app, really. But if you can suggest something better that solves the same problems, please do.
Sort of... think UNIX philosophy vs... I dunno, Windows I guess? With the way it currently does it you are always going to have a horrible public API because the approach is fundamentally flawed.
And that's before I even get into how it solves those problems.
Now is it a bad thing it exists? No, obviously not. I'm glad it does, but we can learn what not to do from it as well.
Earlier quoted context omitted.
If you don't care about the stupid arbitrary bundling system for other assets (like CSS and images) that WebPack has (and you shouldn't: it's an awful code practice) then yes... Browserify is literally better in every way (other than tree shaking)
>If you don't care about the stupid arbitrary bundling system for other assets (like CSS and images) that WebPack has (and you shouldn't: it's an awful code practice) The “stupid arbitrary” system has a number of benefits. It revs your assets for production automatically with content hashes. It saves you from filename typos because all assets (CSS, images) are part of the same build pipeline. It throws on parse error…
Yes, it does. Those features aren't exclusive to webpack though (they're really, really, really old features of webdev) and can be replaced by much less silly systems.
I mean literally everything you just listed is better handled by more mature, developed, tools.
> Having just attended EmberCamp a week ago, I was excited about Ember CLI. Ember users have a great “getting started” experience thanks to a curated set of tools united under a single command-line interface. This is one of the best things about Ember. `ember new`, `ember serve`, ember generate component my-component`, `ember build`, `ember deploy`, `ember install`. It's opinionated but it lets you get productive rig…
I've done a lot of React but have since been burned out by it. It takes so much configuration just to set up something basic like server side rendering. After a year of hacking around with React and wallowing through the pain, I decided to just use Django and django templates. React is nice for a whole company that has one app with a tough initial setup but great performance in the long run, but its hard for individu…
Would appreciate feedback:
Earlier quoted context omitted.
Sorry, didn’t realize it was you :-) >But they very fact you had to spend time abstracting away WebPack speaks volumes IMO... Speaks volumes about its poor public API. I don’t understand how this this affects create-react-app, really. But if you can suggest something better that solves the same problems, please do.
As I think I said on Twitter - it's not really that I think something solves the same problems better; it's that one tool shouldn't be solving all those problems (and in fact many of those problems aren't in the JS space at all). Sort of... think UNIX philosophy vs... I dunno, Windows I guess? With the way it currently does it you are always going to have a horrible public API because the approach is fundamentally fl…
Earlier quoted context omitted.
The only practical reason I can think of for people railing against grunt is that it used the file system for in-between steps and was thus frustratingly slow (a problem that webpack doesn't have). Code vs config is a huge bikeshed
> Code vs config is a huge bikeshed Not really. Historically it's been an indication of the quality of a system.
I'm fairly close to finishing the conversion of my `dev-toolkit` into an npm-module. It is almost no-config, has scss, server-side-rendering, hot-reload and more. I'm a one man band but will get there. It's all on https://github.com/stoikerty/universal-dev-toolkit The npm-version sits in a feature branch, just look for the corresponding PR if you're keen.
Hope anyone reading this finds it useful :)