I can understand needing some abstraction layer for common operations like retrieving DOM elements, attribute manipulation, etc., but jQuery is a pretty massive library that seems like a lot of overkill for Ember.
After looking through the source code, there are only about 30 or so uses of jQuery in Ember and it looks like the majority of jQuery usage is simple selector calls, some events, and some DOM traversal.
Ember.$(rootElement).off('.ember', '**').removeClass('ember-application');
...
elem = this.$();
...
this.$().appendTo(target);
...
Ember.$(window).on('hashchange.ember-location-'+guid, function() {
etc.
Are there any other reasons Ember requires jQuery for every application?
Could these few uses be embedded into Ember and jQuery removed as a dependency?
The question was extremely well explained by Tom Dale (Ember Core Developer).
Essentially he says:
Ember.js requires jQuery for two reasons:
We rely on it heavily in the Ember/Handlebars integration for inserting and modifying DOM elements. I personally am not interested
in dealing with cross-browser DOM manipulation bugs, but the jQuery
team excels at it.
By having a standard DOM manipulation library in jQuery, developers can move between different Ember.js apps and rely on the fact that
they have a battle-tested, cross-platform library underneath them.
If you are concerned about size, I'd recommend investigating the new
jQuery 2.0, which has the ability to do custom builds without features
such as animation.
Makes a lot of sense to me.
Update:
Recently Erik Bryn (Ember Core Developer too) wrote a very interesting comment about the framework and mentioned the state of the art of jQuery usage in Ember projects.
Pasting the comment:
It's a common misconception that Ember.js is monolithic. I can assure
you that isn't actually true. You can pick and choose the parts of
Ember that you want or need (for example, the router is totally
optional). Our build tools even support picking and choosing which
packages you want. You can use it today without jQuery (you will need
to shim and have an event delegation library, or even easier use a
super-lightweight custom jQuery build).
Only Ember's view layer depends on jQuery. It was used more heavily historically than it is now. In the future, we could as you suggest, roll functionality into Ember itself, although we do not want to maintain cross-browser compatibility in Ember that jQuery is already taking care of. Another path, with jQuery 2.0, would be a way to create trimmer build of jQuery containing just the portions that Ember uses.
If there are no-compromise ways to replace instances of jQuery usage in Ember core, you should propose the changes as issues on GitHub.
Related
I am trying to move an application from using tornado templates (to be more accurate, it's jinja with an adapter) to ember.js.
It is my understanding that ember.js has very strong opinions on how to compose the final rendered product. In practice, it seems that the whole application must be generated from ember templates on the client side. The server side just provides data in REST format.
Is it possible to have ember work and take control only on some parts of a page that is mostly rendered by tornado templates (a la jquery plugins), or do I have to completely switch to ember?
Welcome, glad you're looking hard at Ember! You're right, Ember has definite opinions on how things should work :-) Despite that, it is indeed doable to migrate over in chunks.
You have a few options on how to handle this.
1. Build out from a single div on a page
You can see this in action on the builds page on the main Ember site (which is a small Ember app). Source for it is available here: https://github.com/ember-learn/builds/
Of interest is the fact that you can define the rootElement that you want Ember to render in to (see https://github.com/ember-learn/builds/blob/master/app/app.js although we should actually move that line to the config file). Once you have Ember on the page it is then possible to have it both interact with external Javascript or to have external Javascript call in as needed.
2. Sprinkle Ember components on to a page
If you need Ember to control multiple parts of the same page, you may want to look at https://github.com/mitchlloyd/ember-islands That addon is designed to work with server-rendered pages, so may not fit your setup. But it's another example of how to refactor in.
3. Use the new GlimmerJS (alpha)
You could also start refactoring into Ember using the newly announced GlimmerJS. The goal for this library is to allow folks to sprinkle in Ember and then as they need page routing and other aspects of Ember, allow them to switch over. So it may fit what you are after.
Note however that the GlimmerJS layer (on top of the Glimmer vm) is still quite new. What is there works well, but much of the Ember polish is still being added. So shipping to production could take some work ...
I've come across a few Ember component libraries but don't see much activity in their repositories. This is raising some doubt as to whether I should use one in a brand new project.
Are people still using component libraries in new [Ember CLI] projects?
Example component libraries I've found:
Ember Components
Ember UI
Ember Widgets
Any experience with any of these lately? Any new kids on the block?
Or are you creating your own components as required?
There's not a perfect answer to this question. However, there are some factors I weigh when deciding whether or not to use a component library and which one:
Do I need it? Ember has a number of built-in helpers (for example input helpers) that can often do what needs to be done.
How many of the components that ship with the library will I use? There's nothing to gain by unnecessarily adding page weight, it will only degrade users' experience.
How easy is each component to override/extend? In my experience, it's inevitable when using a component library that there will be something that doesn't work the way I need it to. So it's critical the components can be extended or overridden.
Does the library ship with CSS? If so, is it well written and/or optional? Libraries that ship with their own styles can be a pain because the styles will likely not match the aesthetic of your application. How well the styles are written determines how much hacking you'll have to do in order to achieve the result you want.
How active is the development and how many stars does it have on GitHub? If the library doesn't have a lot of active support, it's likely going to quickly get outdated. This can paint you into a corner if you want to upgrade ember itself and the component library is no longer compatible. It can be a significant effort to remove/replace one of these libraries.
There are probably more things to consider, but my point is the decision should be well thought out and deeply question whether or not you need a component library at all.
I have used ember-material-lite extensively. It's a good option if you want to follow Google's Material Design spec. Another nice thing about it is you can easily override both the component JS and Handlebars files for each component in your application to extend/modify their behavior.
This is more of an exploration question.
We have been using breeze.js in our projects for a while and have been quite satisfied with it; it ties nicely into concepts we already know and use (change tracking, metadata, backend agnostic...)
Now we are evaluating the possibility to move our front-end from backbone/marionette/knockout stack to ember.js (which seems to be more of a complete framework than a "pick-only-what-you-need" approach in backbone). We are exploring to possibility to keep using breeze.js as our data management layer on the client-front.
But how can the integration of models returned from the server (server stack: node.js + mongoDB) be done with models defined by ember.js?
A typical ember model definition could be:
var Person = Ember.Object.extend({
Property1: 'foo',
Property2: 'bar'
});
where you can see the extension "Ember.Object.extend"
Breeze.js upon receiving data from server attach a AspectEntity to them (and if Knockout is defined, wrap properties in observables ). How could returned objects somehow be "transformed" into ember.js objects?
Maybe the way we approach this problem and the way we think about this integration is totally wrong or that we should entirely reject this "ember-breeze" combo. From google search we have not found cases where breeze is used with ember.js or some guidance. That is why we come to the stackoverflow community: is it possible? what are the possible pitfalls to look ahead?
There does not seem to be much in the way of existing solutions. The Breeze.js User Voice has some 2-year-old issues that never got much traction; support from that library does not seem to be imminent.
I would recommend exploring Ember-Data as your data management layer. It supports many (if not all) of the concepts you mentioned, and it's the default recommended data library for Ember applications.
That said, as far as trying to make Breeze.js work, you could probably take the objects returned from Breeze and turn them into Ember.Objects using Ember.Object.create, but you'd have to build a layer between Breeze and Ember that essentially serializes between Breeze objects and Ember objects in both directions.
I have a lot of experience with AngularJS and I'm also playing around with Web Components and Polymer for a long time now.
What I really love about the these libraries and technologies, is the fact that they let me build my own components.
AngularJS gives me something called "Directives" and Web Components consists of a set of specs where one is called "Custom Elements", which pretty much does how it's called.
So with these I can do something like:
<my-element></my-element>
This is where the web goes, this is what everybody loves about HTML. Declarative tags that are easy to read and encapsulate functionality and behaviour. Also very nice: once Web Components are fully supported in the browsers, I could for example very easily remove my directive and rely on a web component, that looks and works the same without changing any code.
I know, that EmberJS has something called "Ember Components" which lets you basically build your own kind of components too. However, using them in HTML looks something like this:
{{#my-component}}
{{/my-component}}
Is it possible in EmberJS to also use components declaratively as tags?
I actually hate that about html. I hate the structure etc, but that's just my opinion :)
No, there isn't, your component should be declared in a template using the handlebars syntax, and compiled to js. (you can dynamically create views/components, but that's far from declarative tags).
You'll be able to do that when Glimmer 2 ships with Ember. It was supposed to be in with Ember 2.x, but for some reason its still pending. With that you can use angle brackets to define components.
<my-element></my-element>
I'm trying to optimize my company's application.
Tha architecture at this time is composed of different folders (inside common folder) for different sections of the app (for example Managing Bills, Managing Canteen, Managing Events etc etc).
Every js and css are included in the first page of the application (login.html) because I'm using the simple page template of jQuery Mobile.
Now I'm considering to add some other components to make the app easier to mantain and maybe speed it a bit.
What do you think about:
RequireJS to divide each section in a module so i can load only the javascript of a particular module at run-time instead of loading within login.html
Inline #imports for CSS files to produce single composite CSS
uglify.js to Minimize file sizes
Handlebars.js to realize fragments of html reusable
Do you think is a good way of work for an application that will become greater by adding new sections?
Do you think of other tools?
Thank you
This is a very broad question. I think you're on the right track... I'll list some libraries that could be worth trying:
Require.js - Will give you the ability to have 'modules' and dynamically determine and load dependancies. Alternatively some people prefer patterns such as the Revealing Module Pattern, jQuery Plugin Style or Common JS style modules. For what it's worth I recommend Require.js.
Bower is a package manager, you can use it to bower install [package]. They have a lot of packages here and you can also link it to your own repo. This could be helpful for managing dependancies.
Uglify.js and Google Closure Compiler are both good for minifying your code. Remember that some minification configurations such as advance mode could break your code. Run tests against the minified version of your source code.
QUnit is good for doing JavaScript unit tests. There are many other alternatives like Jasmine, which is what the Cordova guys use.
Lodash is another (faster) implementation of underscore.js that will provide a lot of utility methods for working wit arrays, objects, functions, etc. It also includes templating support. There's a good talk by the author here.
There a MV* JavaScript frameworks that could help more than jQuery (DOM+AJAX+Animations) or jQuery Mobile (Mostly UI) such as: Dojo, AngularJS, Backbone and Ember.js.
For UI you may want to checkout Adobe's topcoat repository and website. There's also Twitter Bootstrap and Foundation which allow you do to responsive design out of the box. If you're set on jQuery Mobile I personally like this Flat theme.
JSDoc and YUIDoc are good alternatives for documenting your JavaScript code.
I have no idea how many of those tools will interact inside Worklight Applications. It should be fine, since Worklight doesn't impose a certain set of JavaScript libraries you have to use. However, I haven't personally tried most of them inside Worklight Applications.