We are currently using requirejs/backbone for development and firebug for debugging. We are thinking of moving to Ember and using ember appkit.
I noticed that because of the new ES6 javascript modules, the application needs to be pre-compiled into a single javascript file app.js.
I am concerned that this will make it difficult to debug problems because you are dealing with a massive single file instead of small ones that we have at the moment and can easily find in firebug.
Has this been an issue for people, are there any good solutions?
As kingpin2k mentions, Ember App Kit has been effectively superseded by Ember-CLI. I would recommend looking into that. Depending on your needs and planning, Ember-CLI may or may not be suitable for your situation. Some people have successfully put Ember-CLI apps in production, but this is brand new technology, so caveat emptor.
Ember-CLI provides a build system based on Broccoli that will transpile ES6-modules, compact the output into a single Javascript file, and lots more. Ember-CLI is still under heavy development, but is already shaping up quite nicely. In my opinion, the clean code organization and fast Broccoli build are really quite awesome.
Modern browsers such as Firefox and Chrome come with an integrated debugger that will show you the original source when source maps are supplied. This will eventually be provided to the browser in Ember-CLI projects as well when you run the development server. However, this functionality is currently incomplete. It is possible to get some source map support in Ember-CLI now, have a look at this issue.
In the mean time, there are more ways to debug code of course, and I suspect that before proper source map support lands in Ember-CLI/Broccoli, liberal use of console logging and such may be sufficient. Running Ember-CLI's live-reload development server means that when you change and save a file in your project, the results will be shown almost instantaneously in the browser; the Broccoli build is blazing fast.
Keep in mind that minifying and combining all Javascript code into a single output file is a common approach in single page application frameworks such as Ember, Angular, and Backbone. Debugging these applications with breakpoints and such will happen more and more through the browser's debug tools in combination with source maps.
Update
By now the Ember core team actively recommends Ember-CLI. It is quite awesome.
Related
I am a bit frustrated that there doesn't seem any decent "Ember intellisense" available in any common IDE (like VS Code, Webstorm, Atom). By "intellisense" I mean that, as long as my Ember project is a standard Ember CLI project with all the common Service, Helper folders etc., and I inject e.g. a service using myService: service(), this would be recognized by Intellisense and, after typing this.myService, I would see all functions in the service. Also, if I Ctrl+Click on the function in this.myService.myFunction(), I would expect to navigate to the definition of myFunction.
For other frameworks, such as Angular, there are plugins which support all this.
Is it really the case that I have to use "Find in Files" to find the definition of a service function?
Does anyone know of a way or tool which I might have missed, and which would support this scenario? Note that I don't speak of bare-bones features such as switching between router/controller/template, but of real intellisense for custom objects.
The situation is indeed not yet great. There are a couple things that do help quite a bit:
Using TypeScript via the ember-cli-typescript project will unlock a lot of these benefits for you. (Full disclosure: I'm a maintainer.)
There's a community-driven IntelliJ plugin which is pretty good, intellij-emberj; it has a fair number of those features and it's kept up to date by a member of the Ember CLI team.
There's a suite of VS Code plugins, including a language server, which gives a fair bit of it.
(There's certainly a lot more to be done here, and unfortunately none of the IDE developers seem interested in providing native support themselves, so it has fallen to the community to build it all.)
You can have a look at various code editors and plugins that ember community suggests,
dev tools
I wonder the same way as you, realising that there is no IDE have particularly good support for Ember.
I'm using Webstorm community version for the past 6 months, but I don’t think it’s the ideal EmberJS IDE. I wonder if there is an IDE which provides some kind of intellisense/code completion/helper suggestions.
Ember has always seemed to be a very IDE-like framework, so it surprises me that no-one here (ember community, IDE developers) is building any clever plugins for IDEA or Atom or VS Code.
VS Code plugins:
emberjs.vscode-ember - Langserver for VSCode.
lifeart.vscode-ember-unstable - Unofficial Canary Version.
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.
Ember don't seems to play well with requirejs or building with r.js without some hackery.
Bit hard to manage a large application, I like to break down my file structure as HMVC, which manages modules bit easier :
app
- blah
- modules
-module1
- controller
- model
- view.
Has anyone come up a build stack to automate the compilation into single file with dependency management?
Update: You should now be starting new projects using ember-cli, which provides all the build/dev tools plus many other useful features.
Original answer:
An example Ember project using grunt.js as a build system:
https://github.com/trek/ember-todos-with-build-tools-tests-and-other-modern-conveniences
I've used this as a starting point for some Ember apps and it works well.
Ember don't seems to play well with requirejs or building with r.js without some hackery.
Why do you want to use require.js in the first place?
As for making this all work you'll need a build tool. I recommend brunch (Node) or iridium (Ruby). Brunch is more simple and supports many different module formats. Iridium is much more powerful. It uses Minispade for modules. Require.js/AMD is not needed because your js is always delivered as a single concatenated file.
For stand-alone ember dev I use ember-skeleton as a starting point, which is itself based primarily on rake-pipeline.
https://github.com/interline/ember-skeleton
This provides the whole kit-and-kaboodle for beginning an app, but the meat of it is the rake-p Assetfile, which describes how rake-pipeline will digest all the files, filter their contents, and ultimately combine them into the final handful of files. Additionally, the combination of loader.js and the minispade filter allows the use of 'require()' statements for managing dependencies amongst your files.
I'm in the process of evaluating the Feathers UI framework as a replacement for our current Flex mobile app (there are just too many limitations of Flex, mostly concerned with performance on retina devices) and coming from Flex, there are some issues I have with a pure AS project.
One big issue seems to be the use of web services. I frequently use mx.rpc classes and interfaces such as IResponder, AsyncToken, and HTTPService, which obviously aren't available without the Flex SDK.
How come that this isn't part of AIR and remains part of the Flex SDK and how do I get rid of this issue? Are there equivalents or do I have to make a hack and import the corresponding SWCs manually?
For a non-Flex project that needs to communicate with a web service, you need two files from the Flex framework: rpc.swc and framework.swc.
You just add the SWCs to your project the same way you would any other SWCs. No MXML, no hacking necessary. I've used them in Flash CS projects and FlashDevelop AS3 projects.
I am cleaning up a build system for a product that uses Jetty. Currently the project has
javax.servlet.jsp:jsp-api:2.1
as a dependency. Given that I am using Jetty for my project I suspect using
org.mortbay.jetty:jsp-api-2.1:6.1.5
would be the better option. Am I right/wrong? Can they be used interchangeably? Does jsp-api-2.1 leverage a different implementation? Or is it simply a repackage if jsp-api to assert compatibility with Jetty?
I've been trying to find information about this on the web, so far nothing has come up.
Update: Seems like org.mortbay.jetty:servlet-api-2.5:6.1.5 and javax.servlet.jsp:servlet-api:2.1 have the same relationship.
Jetty has a long and colorful history with jsp, having no jsp implementation of our own we have leveraged other implementations often, judging by the version numbers your looking at those are very old versions where we were maintaining patches on top of the glassfish jsp implementation. I think it was a patch for supporting logging in jetty and then a bug fix or three.
Now a days we have been using the jsp artifacts from the java.net project which was spun out from glassfish a while back. However that doesn't seem to be tracking bug fixes very regularly either so we are kicking around trying the jasper implementation in tomcat.
Back on your question, the jsp-api artifacts are typically just repackaged artifacts since the api doesn't change frequently. We historically rebundled them to keep them paired with the patched implementation.
Now, you are obviously using a jetty-6 setup since your still using org.mortbay packaging but jetty6 and jetty7 are both servlet-api 2.5 so you might be able to get away with using the jetty7 jsp setup, we have a handy pom that declares these artifacts here:
http://central.maven.org/maven2/org/eclipse/jetty/jetty-jsp/7.6.5.v20120716/jetty-jsp-7.6.5.v20120716.pom
These are glassfish bundles as well, repackaged and made into osgi bundles in the process so they can be used with jetty in osgi environments....they ought to work normally though, we package them in our jetty7 distributions.