Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Create React Apps with No Configuration

facebook.github.io

Post reply on HN
Print view View original

211–220 of 250 posts

Re: Create React Apps with No Configuration

#211

Post by pests »

enraged_camel wrote: post #107
Touche wrote: post #79

Earlier quoted context omitted.

I think the problem is that React is developed as more of a Node/JavaScript project than as a web project. You see this in stuff like depending on `process`, a thing that exists in Node but not on the Web. So the Web is a compilation target; not the platform that React is developed for. From there it's easy to think about everything in terms of JavaScript, and not making the Web the intended target for usage.

Yeah, along these lines, I also hate how most of the examples/tutorials online assume your server is Node.js. I'd love to find some official documentation on the best ways to use it with Asp.net and Rails, for example.

That's usually because those tutorials are also setting up sever side rendering. Node.js is only needed for that and for running the various (optional) build tools.

When doing a SPA I often set up Node.js to serve the index and provide server-side rendering and then never touch it again. Any actual API/WebSockets/RPC interfaces the app needs can be serviced by any plain old Ruby, Python, PHP, etc app backend. Since I usually use PHP from old habits, I use a Symfony API-only application.

I posted about this in a top level comment, but don't forget React can control any element in your DOM and not just the entire body like most SPA's are setup. You can continue using whatever languages/frameworks templating and view systems and augment views as needed that would be better handled by React.

Re: Create React Apps with No Configuration

#212

Post by pests »

Do not forget React is not equivalent to an SPA.

Almost all SPAs give the entire body over to React but its also possible to choose a smaller DOM node and add React progressively to any existing website view that would benefit from the React paradigm. In this setup (at least) server-side rendering is no longer needed and thus simplifies setting up the build process.

So its not all or nothing, you can pick and choose where to use React based on your needs and requirements.

Re: Create React Apps with No Configuration

#213

Post by k__ »

orf wrote: post #210
k__ wrote: post #202

Earlier quoted context omitted.

For me the creation of ember cli was like admiting their framework didn't work as good as they intended.

I'm sorry, Ember has come a huge way in 2 years. We've got 2.0, which was a big leap forward, a whole bunch of concepts were refined/removed or changed. Also you're flat out wrong: Ember-cli isn't really anything to do with the framework. You don't need it to write Ember apps, it's just the communities command line tool for managing Ember projects . That's all.

This is only theoretically right.

Practically, there are Ember modules/extensions/features that require Ember-CLI to work or are a huge pain to work with, if you don't use the CLI...

for example animation libraries or glimmer.

Re: Create React Apps with No Configuration

#214

Post by hex13 »

anthonybullard wrote: post #188
danabramov wrote: post #120

Earlier quoted context omitted.

>However I do wish the React team would pick between ES6 classes and `React.createClass` We’re going with ES6 classes. Expect createClass() to go into another package some time this year. (Obviously we’ll provide an automated “codemod” utility to convert your existing code.)

Please say it isn't so! Class is terrible syntactic sugar to please old Java programmers. I'd be really interested in why this decision would be made. Im just getting going in React and am looking to make a move away from Angular, because Angular 2 is so hyper focused on classes and decorators. I like React because it's closer on the purity scale to something like Cycle.js. But nevermind me, React is a great tool, an…

Syntactic sugar? But `createClass` is a lot worse syntactic sugar than ES6 classes.

React.createClass (and angular.directive or similar guerilla solutions) are harder to analyse statically. And without static analysis you won't have proper tooling (IDE autocompletion, "go to definition" feature, dependency graphs, linting etc.).

So. Welcome language standards or goodbye static analysis. I'm seriously happy that both React and Angular go into ES6 classes and resign from guerilla coding...

Re: Create React Apps with No Configuration

#215

Post by hex13 »

JoeCortopassi wrote: post #40
mumphster wrote: post #36

Earlier quoted context omitted.

None of that is needed for a real world production frontend app, with the exception of maybe tests.

Granted, some things like hot module replacement and generators are not necessary, most of the others are (isomorphic rendering, code splitting, sass, dockerization). I'm not saying you need those things for your personal react app going into production, but when dealing with bigger teams for a critical app they really become important tools

1. Sass is not as needed as it used to be (native CSS variables, PostCSS, CSS Modules, Radium, inline styles etc.).

But of course many users prefer Sass. But Sass in its CSS syntax (SCSS) is (if I'm correct) just super set of CSS. You can always start project using vanilla CSS and when project will grow, you can add Sass.

There are two approaches to develop new projects: big design up front and YAGNI principle (you ain't gonna need it). I prefer YAGNI and I'm glad that Facebook generator is so minimal. But I don't know what they are planning to do with this project. I think this project would be a lot worse if they forced to use Sass(or Radium or any opinionated CSS solution).

2. code splitting? If I understand correctly it's Webpack feature needed mainly for production, not development. So why to add this on the very beginning of your project?

Re: Create React Apps with No Configuration

#216

Post by shados »

danabramov wrote: post #207
acemarke wrote: post #194

Earlier quoted context omitted.

React's lifecycle methods and other similar features require some kind of "object instance" to exist. Since React was created prior to ES6, the React team created their own "inheritance"-ish approach, which is something that every JS library out there was doing as well. One of the main arguments for classes being included in the ES6 standard is that it's a common approach that libraries can converge on and use togeth…

Exactly. We don't like classes, but we don't like "pseudo classes" (createClass) even more. Better the devil that's standardized. We already offer a way to create stateless components with just functions. We will keep exploring that space and eventually might have a class-less solution we like that satisfies all our use cases.

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 of stateless component functions, things like the good old ES3 module syntax honestly would be more flexible/powerful (giving you a closure to do things like private members, etc)

Instead we have people using babel with all sorts of plugins, tacking on 3rd party decorators and utilities, and a bunch of other cruft just to mimic features JavaScript have had from the beginning. And then (talking out of my rear here), it possibly put pressure on the TC39 to waste time discussing features we seriously don't need.

Re: Create React Apps with No Configuration

#217

Post by shados »

acemarke wrote: post #194
anthonybullard wrote: post #188

Earlier quoted context omitted.

Please say it isn't so! Class is terrible syntactic sugar to please old Java programmers. I'd be really interested in why this decision would be made. Im just getting going in React and am looking to make a move away from Angular, because Angular 2 is so hyper focused on classes and decorators. I like React because it's closer on the purity scale to something like Cycle.js. But nevermind me, React is a great tool, an…

React's lifecycle methods and other similar features require some kind of "object instance" to exist. Since React was created prior to ES6, the React team created their own "inheritance"-ish approach, which is something that every JS library out there was doing as well. One of the main arguments for classes being included in the ES6 standard is that it's a common approach that libraries can converge on and use togeth…

It does not need a class, it just need to be able to keep track of some kind of references. There's a million functional ways to do this without needing class.

React really should have gone from createClass to . It already supports the module pattern. They easily could have expanded on that.

Re: Create React Apps with No Configuration

#218

Post by ebryn »

orf wrote: post #78
sotojuan wrote: post #38

Earlier quoted context omitted.

Don't forget: https://www.ember-fastboot.com/ Also two commands to get server rendering working.

I personally use Django as a backend for my Ember stuff, which means I miss out on the whole fastboot experience. It does look really nice though.

Django / other backends aren't mutually exclusive with Fastboot. You can use them together.

Re: Create React Apps with No Configuration

#219

Post by hex13 »

shados wrote: post #216
danabramov wrote: post #207

Earlier quoted context omitted.

Exactly. We don't like classes, but we don't like "pseudo classes" (createClass) even more. Better the devil that's standardized. We already offer a way to create stateless components with just functions. We will keep exploring that space and eventually might have a class-less solution we like that satisfies all our use cases.

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 language, but they're dynamic, which is unfortunate because to know what exactly is happening in this code you have to run it. for IDEs/editors it's hard to look at your code and guess "well, it's module pattern, I see! You mean this and that". Tooling operates usually on static analysis of syntax. They use JS parsers to parse code to AST(Abstract Syntax Tree).

And here's the thing: ES6 classes are visible in AST, there is something called ClassDeclaration. This means that every programmer can install some ES6 parser from NPM and analyse ES6 classes. This means that there will be better linting, better autocompletion etc.

On the other hand - JavaScript parsers don't understand module pattern or other homegrown idioms. It's harder to analyse them statically. Especially if they rely on dynamic aspects on language. ES6 parser doesn't run your code. That's why ES6 classes, because they're static, are better for parsers, and consequently, enable better tooling, IDE support, autocomplete etc.

Situation maybe were a little bit different if we had tooling for some sort of dynamic analysis (if tools were running code in sandbox and gathered data in runtime, not from syntax etc.).

But because currently most of tooling is syntax based I think ES6 classes (and e.g. ES6 modules) are just better for analysis.

Well... to contradict what I said early I must say that actually it's often possible to analyse such things like module pattern, createClass etc. But:

1. not always with 100% certainty of the result

2. there are too many idioms. If every framework, every team and every programmer has own way of writing JS, own module syntax, own class syntax etc. it's very hard to support all the frameworks and provide tooling for all people...

Post reply on HN