13 ms·

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

by orf 10y ago

> 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 right off the bat. I tried React but after a couple of days I just couldn't get it working, waaay to many options. So I switched to Ember and haven't looked back.

sotojuan 10y ago
Don't forget: https://www.ember-fastboot.com/ https://www.ember-fastboot.com/ Also two commands to get server rendering working.
- matthoiland 10y ago
  Also don't forget: https://github.com/felixrieseberg/ember-electron https://github.com/felixrieseberg/ember-electron One command to wrap your Ember app in Electron.
- orf 10y ago
  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.
  - ebryn 10y ago
    Django / other backends aren't mutually exclusive with Fastboot. You can use them together.
ctvo 10y ago
Kind of interesting to think about the two projects and how they diverge based on the core developers. Ember is made by folks who work on / for small and medium companies[1]. They don't have the build infrastructure Facebook does and are able to create an anointed solution in Ember-CLI because they'll use it daily. React is stuck in a place where the environment it's developed in is unique from what any other user will see. It's difficult to solve a problem when you're not in the space. EDIT: This leads to things beyond CLIs too. React is still billed as just a view library instead of a solution for building an entire app. There's no official path from view layer -> complete app (no guidance for data flow, how to communicate with the server, server side rendering, routing on the client). I think the React team needs to take a little more responsibility for the eco-system it created. You can't call it just a view library when most use cases use it to develop entire applications. You have to provide more guidance, you can't fallback to Facebook not using it that way as the default response. In my opinion most of the Great Javascript Fatigue of 2015-16 was caused by users trying to fill in the blanks left by the React team and producing one solution after another (and quickly abandoning ship as something iteratively better was released). 1 - Tom, Yehuda at tilde.io
- danabramov 10y ago
  This is a very accurate description of the problem. We’re optimistic though. I’m sure that the community will help make Create React App even better.
  - ctvo 10y ago
    Sorry I edited in a WHOLE bunch more that you probably wouldn't agree with after your reply. Apologies!
    - danabramov 10y ago
      Lol. No, I still fully agree. We think React is a tool to create great UIs, and UIs definitely include concerns like data fetching, etc. So some of this might make it into React in some form in the future.
      - shaneos 10y ago
        In the meantime, you can also try out the official Flux library from Facebook (https://github.com/facebook/flux https://github.com/facebook/flux), or Redux (https://github.com/reactjs/redux https://github.com/reactjs/redux), which offer great solutions for data manipulation and storage
        coldtea 10y ago
        I think he knows about those two options. (The guy you're responding to is the creator of Redux) :-)
        vmasto 10y ago
        And now working for Facebook, one of the most active members of the react team at that.
        10y ago
Touche 10y ago
The problem is that when frameworks develop these CLIs they tend to think only about the CLI users and it becomes larger and larger a requirement. Personally I'm a web developer, I don't want to be a React developer or an Ember developer, etc. so the more difficult you make it to use your stuff with normal web technologies the less I want to have anything to do with it.
- orf 10y ago
  > The problem is that when frameworks develop these CLIs they tend to think only about the CLI users and it becomes larger and larger a requirement Well there are two ways to modify an Ember project: create a bunch of files in various places by hand, or run `ember whatever` and have it done for you. The CLI is the preferred way of doing it for a lot of (good) reasons but if you want a new component running `ember g my-component` and having it make the component JS file, the template and the tests for you in one fell swoop is awesome. > so the more difficult you make it to use your stuff with normal web technologies the less I want to have anything to do with it. I don't understand your point? What's a 'normal web technology'?
  - Touche 10y ago
    > I don't understand your point? What's a 'normal web technology'? https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/
    - orf 10y ago
      So you want to write HTML for a living? Ok, that's cool. But things have moved on a bit since then. I mean, you're commenting on a thread about JS libraries that enable you to write awesome single page apps and saying you... don't want to write JS? If I get you correctly then I used to be like you. "Eww, javascript". Then I was forced to use Ember for a project where I work and it is amazing, nothing that the app does could even remotely be done with HTML or even a bunch of jQuery spaghetti.
      - 10y ago
bcheung 10y ago
I've been exploring an alternative solution. Currently playing around with the idea of a React app for building React apps. Basically, it's an admin for specifying routes, models, components, database schemas, views, stores, reducers, etc. They are defined declaratively and serialized. Then can be feed to either a build step or a bootstrap that can load create the app dynamically. Each type of thing that can be edited has its own dedicated UX. Not much built yet but I'd be curious if anyone else has similar ideas / solutions.
- lsiebert 10y ago
  read your comment right after I posted mine suggesting something like this wrapping the CLI.
- deleted 10y ago
  [deleted]
mikeryan 10y ago
There's a similar (in concept) idea in React Boilerplate http://www.reactboilerplate.com/ http://www.reactboilerplate.com/ There's several projects like this. Its an opinionated React startup kit utilizing Redux, React Router and Redux-Sagas. With generators, a server etc. Because React doesn't provide the whole framework there's a bunch of these to get you started so the space is more complex to navigate then something like Ember.
terda12 10y ago
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 individual hackers like me who just want to get tiny webapps up and running.
- sotojuan 10y ago
  > It takes so much configuration just to set up something basic like server side rendering. Is server side rendering basic or necessary in most "tiny" apps?
  - orf 10y ago
    > Is server side rendering basic or necessary in most "tiny" apps? Isn't it both?
- lcarlson 10y ago
  I'm going to write some examples but I've started putting down my alternative setup without flux. I think it's a much simpler/nicer setup. Would appreciate feedback: https://github.com/lancecarlson/react-mvc https://github.com/lancecarlson/react-mvc
brianllamar 10y ago
I love the opinions I get with Ember and love it for getting small projects off the ground quickly and prototyped. One thing I don't see a lot of is opinions in React on deploying. I wrote a blog post on deploying this new boiler using netlify, pretty straight forward. https://www.netlify.com/blog/2016/07/22/deploy-react-in-30-seconds https://www.netlify.com/blog/2016/07/22/deploy-react-in-30-s...
kerkeslager 10y ago
Having used Ember and React, this was my experience too. Ember lets you get up and running really fast. However, once you start doing anything outside of something it doesn't have an opinion about, you're stuck working around the framework. Good luck with that. At the end of last summer we started to make the migration from Ember to React, and we removed the last Ember code from our code base in April of this year. It has been a slow process, but it has paid off immensely in productivity. I'd rather write code to solve all my problems than have a solution that solves 90% of my problems out of the box but then makes solving the remaining 10% a hacky, unpredictable process.
- gavinpc 10y ago
  > I'd rather write code to solve all my problems than have a solution that solves 90% of my problems out of the box but then makes solving the remaining 10% a hacky, unpredictable process. So are you saying that, absent a better framework than Ember, you would have recommended migrating to no framework at all?
  - kerkeslager 10y ago
    No, when I say "I'd rather write code to solve all my problems" I'm talking about React. In React, things happen because you call a function, not because you named something the name that makes them get called, with only a handful of exceptions. You want to change the state, you call `setState`, you want to render the component you call `renderComponent`. It all looks surprisingly like writing code with a very helpful library.

by orf 10y ago

sotojuan 10y ago

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

matthoiland 10y ago
Also don't forget: https://github.com/felixrieseberg/ember-electron https://github.com/felixrieseberg/ember-electron One command to wrap your Ember app in Electron.
orf 10y ago
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.
- ebryn 10y ago
  Django / other backends aren't mutually exclusive with Fastboot. You can use them together.

ctvo 10y ago

Kind of interesting to think about the two projects and how they diverge based on the core developers. Ember is made by folks who work on / for small and medium companies[1]. They don't have the build infrastructure Facebook does and are able to create an anointed solution in Ember-CLI because they'll use it daily. React is stuck in a place where the environment it's developed in is unique from what any other user will see. It's difficult to solve a problem when you're not in the space. EDIT: This leads to things beyond CLIs too. React is still billed as just a view library instead of a solution for building an entire app. There's no official path from view layer -> complete app (no guidance for data flow, how to communicate with the server, server side rendering, routing on the client). I think the React team needs to take a little more responsibility for the eco-system it created. You can't call it just a view library when most use cases use it to develop entire applications. You have to provide more guidance, you can't fallback to Facebook not using it that way as the default response. In my opinion most of the Great Javascript Fatigue of 2015-16 was caused by users trying to fill in the blanks left by the React team and producing one solution after another (and quickly abandoning ship as something iteratively better was released). 1 - Tom, Yehuda at tilde.io

danabramov 10y ago
This is a very accurate description of the problem. We’re optimistic though. I’m sure that the community will help make Create React App even better.
- ctvo 10y ago
  Sorry I edited in a WHOLE bunch more that you probably wouldn't agree with after your reply. Apologies!
  - danabramov 10y ago
    Lol. No, I still fully agree. We think React is a tool to create great UIs, and UIs definitely include concerns like data fetching, etc. So some of this might make it into React in some form in the future.
    - shaneos 10y ago
      In the meantime, you can also try out the official Flux library from Facebook (https://github.com/facebook/flux https://github.com/facebook/flux), or Redux (https://github.com/reactjs/redux https://github.com/reactjs/redux), which offer great solutions for data manipulation and storage
      - coldtea 10y ago
        I think he knows about those two options. (The guy you're responding to is the creator of Redux) :-)
        vmasto 10y ago
        And now working for Facebook, one of the most active members of the react team at that.
        10y ago

Touche 10y ago

The problem is that when frameworks develop these CLIs they tend to think only about the CLI users and it becomes larger and larger a requirement. Personally I'm a web developer, I don't want to be a React developer or an Ember developer, etc. so the more difficult you make it to use your stuff with normal web technologies the less I want to have anything to do with it.

orf 10y ago
> The problem is that when frameworks develop these CLIs they tend to think only about the CLI users and it becomes larger and larger a requirement Well there are two ways to modify an Ember project: create a bunch of files in various places by hand, or run `ember whatever` and have it done for you. The CLI is the preferred way of doing it for a lot of (good) reasons but if you want a new component running `ember g my-component` and having it make the component JS file, the template and the tests for you in one fell swoop is awesome. > so the more difficult you make it to use your stuff with normal web technologies the less I want to have anything to do with it. I don't understand your point? What's a 'normal web technology'?
- Touche 10y ago
  > I don't understand your point? What's a 'normal web technology'? https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/
  - orf 10y ago
    So you want to write HTML for a living? Ok, that's cool. But things have moved on a bit since then. I mean, you're commenting on a thread about JS libraries that enable you to write awesome single page apps and saying you... don't want to write JS? If I get you correctly then I used to be like you. "Eww, javascript". Then I was forced to use Ember for a project where I work and it is amazing, nothing that the app does could even remotely be done with HTML or even a bunch of jQuery spaghetti.
    - 10y ago

bcheung 10y ago

I've been exploring an alternative solution. Currently playing around with the idea of a React app for building React apps. Basically, it's an admin for specifying routes, models, components, database schemas, views, stores, reducers, etc. They are defined declaratively and serialized. Then can be feed to either a build step or a bootstrap that can load create the app dynamically. Each type of thing that can be edited has its own dedicated UX. Not much built yet but I'd be curious if anyone else has similar ideas / solutions.

lsiebert 10y ago
read your comment right after I posted mine suggesting something like this wrapping the CLI.
deleted 10y ago
[deleted]

mikeryan 10y ago

There's a similar (in concept) idea in React Boilerplate http://www.reactboilerplate.com/ http://www.reactboilerplate.com/ There's several projects like this. Its an opinionated React startup kit utilizing Redux, React Router and Redux-Sagas. With generators, a server etc. Because React doesn't provide the whole framework there's a bunch of these to get you started so the space is more complex to navigate then something like Ember.

terda12 10y ago

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 individual hackers like me who just want to get tiny webapps up and running.

sotojuan 10y ago
> It takes so much configuration just to set up something basic like server side rendering. Is server side rendering basic or necessary in most "tiny" apps?
- orf 10y ago
  > Is server side rendering basic or necessary in most "tiny" apps? Isn't it both?
lcarlson 10y ago
I'm going to write some examples but I've started putting down my alternative setup without flux. I think it's a much simpler/nicer setup. Would appreciate feedback: https://github.com/lancecarlson/react-mvc https://github.com/lancecarlson/react-mvc

brianllamar 10y ago

I love the opinions I get with Ember and love it for getting small projects off the ground quickly and prototyped. One thing I don't see a lot of is opinions in React on deploying. I wrote a blog post on deploying this new boiler using netlify, pretty straight forward. https://www.netlify.com/blog/2016/07/22/deploy-react-in-30-seconds https://www.netlify.com/blog/2016/07/22/deploy-react-in-30-s...

kerkeslager 10y ago

Having used Ember and React, this was my experience too. Ember lets you get up and running really fast. However, once you start doing anything outside of something it doesn't have an opinion about, you're stuck working around the framework. Good luck with that. At the end of last summer we started to make the migration from Ember to React, and we removed the last Ember code from our code base in April of this year. It has been a slow process, but it has paid off immensely in productivity. I'd rather write code to solve all my problems than have a solution that solves 90% of my problems out of the box but then makes solving the remaining 10% a hacky, unpredictable process.

gavinpc 10y ago
> I'd rather write code to solve all my problems than have a solution that solves 90% of my problems out of the box but then makes solving the remaining 10% a hacky, unpredictable process. So are you saying that, absent a better framework than Ember, you would have recommended migrating to no framework at all?
- kerkeslager 10y ago
  No, when I say "I'd rather write code to solve all my problems" I'm talking about React. In React, things happen because you call a function, not because you named something the name that makes them get called, with only a handful of exceptions. You want to change the state, you call `setState`, you want to render the component you call `renderComponent`. It all looks surprisingly like writing code with a very helpful library.