I’ve been using EmberJS for the past two years now and made several web apps with it, but I’m now finding it hard to get started with.
I’m currently working on a new project and I’m trying to solve the problems I’ve been having with EmberJS for the past few years, which are:
Since I’m using NodeJS + ExpressJS on the backend, I got used to the Jade template engine. The problem is: it’s not integrating well with Handlebars. So I decided for this project to switch to EmblemJS.
I’ve been compiling on the run a core.js from all my libraries/controllers/views/components/routes/whatever javascript files, but changing one line in any file, and it has to recompile the core.js. I have no solution for this yet.
Those javascript files have to be compiled in a certain order, because some of them depends on the libraries and so on. Obviously this is hard to organize. I think modules (and ES6) is the way to solve that problem.
I’ve been reading a lot about Ember CLI and BroccoliJS recently, but I still think it’s not the right solution for me. I would have to run my app AND ember serve at the same time, which makes no sense to me.
I’ve been trying to run BroccoliJS with my NodeJS server, but it’s not working well.
Overall, BroccoliJS doesn’t integrate well with my current stack, and is extremely badly documented.
Am I missing something here or all those aspects is overcomplicating the development process? I’ve been looking for solutions for two days now, with no success at all.
Anyone running NodeJS+ExpressJS+EmberJS+Emblem with no problem?
One of the main goals of Ember CLI is to make getting started with a “real” app very easy. Yes, it is opinionated, but in the end if you can follow the best-practices it should allow you to focus on building your application and NOT on building a build pipeline…
Regarding running two different commands (one for your backend and one for your frontend):
This seems like a convenience issue, you could easily create a bin/server script that just spins them both up at once.
Ember CLI runs an express server internally, and you can extend it with your own middlewares. If your current stack is middleware based (or can become so) you share your middlewares between the two and only need to run ember server during development.
I use, restify and nodejs for my backend, works great because my back end isn’t tightly coupled with my front end. your issue arises because you have tightly coupled the two
@BenjaminN It has taken me a while as well to find a solution that just works, but if you feel like upgrading to Sailsjs you can give SANE Stack a try, which we created at Artificial Labs for our client applications.
It is still quite heavily in development (see https://github.com/artificialio/sane-cli), but we have removed what where some of our biggest pain-points and are using it on multiple projects in production.
Since I’m using NodeJS + ExpressJS on the backend, I got used to the Jade template engine. The problem is: it’s not integrating well with Handlebars. So I decided for this project to switch to EmblemJS.
I’m not sure exactly what you’re doing, but your Ember’s client-side templating should be 100% separate from any server-side templating that you do. (Although with Ember, you really shouldn’t be doing much server side templating.) If you’re speaking strictly about the syntax, I wouldn’t call that a reason that Ember.js is hard to use.
I’ve been compiling on the run a core.js from all my libraries/controllers/views/components/routes/whatever javascript files, but changing one line in any file, and it has to recompile the core.js. I have no solution for this yet.
What’s wrong with that? I run my code through an ES6 transpiler then concatenate the files into a single app.js, and most of my file changes take less than a tenth of a second to recompile. Why fix something that isn’t broken?
Those javascript files have to be compiled in a certain order, because some of them depends on the libraries and so on. Obviously this is hard to organize. I think modules (and ES6) is the way to solve that problem.
This isn’t really Ember’s fault. Any sufficiently advanced codebase is going to have a complex dependency graph. If you’re writing serious code you should definitely be using some kind of module system.
I still think that Ember’s biggest problem is its learning curve, but that has been getting better in the past few months, not worse.
You could have it either way, but it is more sensible to serve the ember app directly through your backend. So they live on the same port and the same routes.
Though I would suggest having nginx as a file server on top of your node app.
I like to split the back-end into lots of different pieces though; the ember app usually lives in a CDN somewhere. Though if you want to go ala MEAN, using ember cli you can easily build on the exposed express app to build your back-end, and just use your jade for your back-end (I’m assuming email templates and stuff like that?) without any problem.
But to the OP, if you think of them as communicating through CORS, it makes more sense to have them both running at the same time.
You can still have the ember app on a CDN somewhere and simply have the index.html that loads the app served by your express/sails/node app. And if it the index.html is served via nginx you can simply update the index.html without having to restart your server or anything - or you can use the Redis approach that Luke Melia suggests.
I’m not a big fan of MEAN like architecture. I like splitting up everything into modules. I also use platform-as-a-service stuff for deployment (modulus right now) so I don’t deal with nginx or anything like that.
But yeah, it looks like lots of us are using all the frameworks mentioned, in lots of different ways, without any problems. If the argument is that it doesn’t make sense to have both your api and the client running at the same time, then looking into CORS can help understand that architectural pattern a little better.
What I really wanted to say is that I’ve also been working with Ember for years and I think it’s never been better in the tooling side. ember new your-app and you’re good to go. That’s actually what helps me sell Ember to people, just a few minutes with ember cli and the next thing you know, they’re planning to go to a meetup and thinking about publishing addons, it’s awesome.