用Ember项目运行Yeoman和Rails的优缺点和可行性?(Cons/pros and feasibility of running Yeoman and Rails with an Ember project?)

我正在研究Ember-Rails应用程序。 我之前使用过Yeoman来构建非ember-rails应用程序和js插件,并且我希望能够在处理我的Ember-Rails项目时体会到Yeoman(特别是Grunt的livereload)的好处。 但是,我不确定Ember,Rails和Yeoman是否完全兼容,以及它们的角色和职责是否重叠。 例如:

依赖管理 - 我知道Bower用于依赖管理。 Bower是否影响资产如何通过导轨资产管道加载? 通过Bower加载依赖关系而不是使用Rails gems有什么优点/缺点?

Livereload - 是否像使用多页面应用程序(例如,不使用js框架的html网站)一样使用单页面应用程序(如Ember中内置的应用程序)实现livereload功能? 是单独的模型/视图/控制器重新加载或整个应用程序通过Rails资产管道重新加载和/或重新编译?

现有项目 - 将Yeoman整合到现有的Ember-Rails应用程序中时是否存在缺陷? 我们正在生产Ember 1.3.0-beta和Ember Data 1.0.0-beta。 如果您有使用最新Ember版本的经验,Ember-auth和Ember-data是否与Yeoman兼容?

如果任何人有将Ember,Rails和Yeoman结合的经验,或者如果您了解前端和后端如何与这样的堆栈进行比较,请分享您的想法! 您是否建议将Yeoman设置(例如Grunt)的一部分与Ember-Rails应用程序集成,而不是整个Yeoman?

谢谢。

I am working on an Ember-Rails app. I have used Yeoman previously for building non-ember-rails apps and js plugins and I would love to be able to realize the benefits of Yeoman (especially Grunt's livereload) when working on my Ember-Rails projects. However, I am unsure as to whether Ember, Rails, and Yeoman are fully compatible and whether they overlap in their roles and responsibilities. For example:

Dependency Management - I understand Bower is used for dependency management. Does Bower affect how assets are loaded through the rails asset pipeline? What are the advantages/disadvantages of loading dependencies through Bower instead of using Rails gems?

Livereload - Does livereload function with a single-page app (like one built in Ember) in the same way it does with a multi-page app (for example, an html site that doesn't use a js framework)? Are individual models/views/controllers reloaded or does the whole app reload and/or recompile through the Rails asset pipeline?

Existing Project - Are there pitfalls when integrating Yeoman into an existing Ember-Rails app? We're running Ember 1.3.0-beta and Ember Data 1.0.0-beta on our production. If you have experience with up-to-date Ember builds, are Ember-auth and Ember-data compatible with Yeoman?

If anyone has experience combining Ember, Rails, and Yeoman, or if you understand how the frontend and backend would compare with such a stack please share your thoughts! Would you recommend just integrating part of the Yeoman setup (e.g. Grunt) with an Ember-Rails app instead of the whole of Yeoman?

Thanks.

最满意答案

我不是Rails和Ember的家伙,但这里是我对使用Yeoman的可行性的一般想法:

不使用Yeoman:可行性

从我结合Yeoman和Django的经验来看,我必须说,它只能在中型或更大型项目中获得回报。 在较小的,特别是在紧迫的期限内,并没有太多关注代码质量和技术。 使用的解决方案(如大学项目),你可能会更好地坚持使用裸露的Rails(手动下载JS库并将它们提交给Rails项目结构)。

原因很简单:使用前端框架(Yeoman)微调全栈框架(Rails)可能非常耗时。 特别是如果Rails是由CoC原则驱动的。 它似乎在一些设置后仍然有效,但随着项目的发展,您将会发现更多的障碍,您将不得不更多地篡改waaaaaaay。

我认为不值得投资的缺点和不足:

Livereload 我非常喜欢它,起初我很惊讶它,但过了一段时间后,我发现我不会花很多时间在IDE中编辑HTML和CSS,而是在另一个屏幕上自动刷新静态页面。 在大多数情况下,我仍然需要按Alt + Tab并触发某些操作,执行一些点击操作,因此,无论我添加一个Ctrl + R命中,都没有任何区别。 在某些情况下,您最好使用本地文件夹映射(Chrome Dev Tools)或Web代理(例如:Fiddler)。 有些情况下Livereload可以做出出色的工作,例如,如果您仅编辑CSS,则不需要执行完全重新加载。

至于你的问题:

对我来说,如果它检测到JS的变化,它会重新加载整个页面。 但也许是因为我使用JetBrains IDE(文件系统缓存)和CoffeScript(编译为JS)。

Yeoman最适合SPA 。 你可以接受使它成为一个SPA,而不是一个往返程序?

Bower - 尝试为github项目提供依赖性管理 凉亭为你的应用做什么基本上是从github下载东西。 这里没有火箭科学。 如果下载的东西的结构是非标准的,那么Bower / RequireJS / Grunt-bower-install对于接下来该如何处理没有血腥的想法,即如何注入所有内容以便不会出现错误。 对于大多数流行的图书馆凉亭只是工作,对于高度自定义的图书馆,你将最终手动注入下载的东西。 应该指责的是没有正确包装有用的github项目的人。

此外,我听说bower_components因bower_components凉亭问题而承诺bower_components的工作流程,但从未bower_components ,也许问题已得到解决。 如果不将第三个库提交到源代码的可能性绝对是一个优势。

注意:正如我上面所指出的,这是bower如何帮助您开发应用程序 ,但是bower已经成为前端社区的标准,例如http://ngmodules.org/是建立在其上的,所以它是一个重要的工具。

Rails汇编管道可以获取任意github项目吗? 是。 它可以注入库引用到你的HTML? Duno,我不是Rails的家伙。

发电机 有些人可以做得很漂亮,比如为你配置整个heroku相关的东西。 太糟糕了generator-heroku不能按预期工作(尝试它像2个月前)。 Travis发电机也是如此。 在这种情况下修复很容易,但请看下一点。 至于Angular生成器(我是Angular家伙,不是Ember家伙,对不起:-)) - 它只添加了2个文件并将它们包含在index.html ,此外如果你使用的不那么直接的语法来创建JS框架相关东西(样品: 咖啡中与角度相关的东西 )发生器很可能不会知道它。 好的,你可以向生成器提交一个补丁,但是随后AngularJS团队决定在下一个版本中改变语法 - 你明白了吗? - 再次,看下一点。 更重要的是,如果您的项目使用布局,其中代码由功能/模块 (例如管理模块,配置文件设置模块......)构成,而不是按类型 (指令,控制器,...)框架特定的生成器赢得'工作。

稳定性 Karma正在迅速发展,Angular,Angular-UI和大量前端工具,框架也在不断发展。 尽管他们在这里做得很好,但Yeoman很难跟上最近的变化。

采用Yeoman: 前卫

Yeoman提供了一些非常酷的东西,例如:

掉毛

即时编译coffeescript,SASS / SCSS等

CDNifying 当您希望在本地下载库以便脱机开发并且仍然受益于CDN的专业人员时非常有用。 如果没有Grunt,你最终会编写脚本解析你的HTML

自动JS / CSS缩小 咕噜为你做。 你只需要正确配置它。

鼓励你的前端和后端的分离和低耦合 至于你的问题:我怀疑你可以单独使用Yeoman来管理Rails的一部分。 在Yeoman&sth中的Web应用程序的好配方是: https : //stackoverflow.com/a/19425461/1432478 。 这是Django,相应地适应Rails。

我的想法

在大多数纯粹基于Spring MVC,Rails,Django等的小项目中,你根本不执行Grunt所做的任何事情(因此设置的时间花费更少)。 有些情况下,生产技术先进的前端是必须的。 例如:最近我发现我的银行账户管理系统不会缩小JSes。 即使有趣的评论仍然保持原样。 我没有执行任何匆忙的提款,但我希望他们至少有服务器端验证。 :-)

Yeoman是促进所有家务的解决方案的完美结合。

只使用Grunt? 当谈到应用程序组装时,恕我直言,Yeoman是Grunt。 你可以免费获得Livereload和其他东西。

如果:

你很幸运,找到了似乎适用于你选择的Web框架的示例配置,或者设法自己配置一个 没有最后期限

那么你应该试试看。

如果你将在多个项目上工作,那么配置它的一次可能会通过将配置复制粘贴到未来的项目中而得到回报。 但请记住,前端技术正在迅速发展,这就是为什么网络中的大量样本无法正常工作的原因。

进一步阅读:)

http://blog.tfnico.com/2013/07/considerations-for-javascript-in-modern.html

Java世界在这里,但我希望一些概念将是有用的:

http://addyosmani.com/blog/making-maven-grunt/ JavaScript的Web应用程序和Java服务器,建立所有在Maven或使用Grunt的Web应用程序?

I'm not Rails&Ember guy, but here are my general thoughts about feasibility of using Yeoman:

Not using Yeoman: Feasibility

From my experience in combining Yeoman & Django, I must say that it starts to pay off only in medium-sized or bigger projects. In smaller ones, particularly with tight deadlines and not much attention paid to the code quality & tech. solutions used (like Univ. projects), you'll be probably better off sticking with bare Rails (downloading JS libraries manually and committing them accordingly to the Rails project structure).

The reason is simple: It might be really time-consuming to fine tune both full-stack framework (Rails) with frontend-framework (Yeoman). Particularly if Rails is driven by CoC principle. It might seem to work after some setup, but as the project evolves, you will spot further obstacles and you'll have to tamper waaaaaaay more.

Cons & things I consider not worth this time investment:

Livereload I like it very much, I was amazed with it at first, but after some time I see that I don't spend that much time editing HTML&CSS in IDE and watching static page on another screen automatically refresh. In majority of cases I still need to do Alt + tab and trigger some action, perform some click, so whether I add one Ctrl+R hit in-between doesn't do any difference. In some cases you'll be better off playing around with Local Folders Mappings (Chrome Dev Tools) or web proxy (e.g.: Fiddler). There are cases where Livereload does a brilliant job though, such as for instance not needing to perform full reload if you edited only CSS.

As for your questions:

For me if it detects changes in JS it reloads whole page. But maybe it's because I'm using JetBrains IDEs (filesystem cache'ing) and CoffeScript (compilation to JS).

Yeoman is best suited for SPAs. Would it be acceptable for you to make it a SPA, not a round trip app ?

Bower - Attempt to provide dependency management for github projects What bower does for your app is basically downloading stuff from github. No rocket science here. If the structure of downloaded thing is non-standard, Bower/RequireJS/Grunt-bower-install has no bloody idea what to do with it next, i.e. how to inject everything so that you won't get errors. For most popular libraries bower just works, for highly customized ones you will end up injecting downloaded stuff manually. The ones to blame are people who don't package useful github projects properly.

Furthermore I heard of workflows where people commit bower_components due to problems with bower, never experienced personally though, perhaps the issues were fixed. If so possibility of not committing 3rd libraries to source code is definitely an advantage.

Note: As I pointed out above, it's how bower helps you developing your app, but bower has become somewhat a standard in the frontend community, for instance http://ngmodules.org/ is build on top of that, so it's a important tool.

Can Rails assembly pipeline fetch arbitrary github project ? Yes. Can it inject library references to your html ? Duno, I'm not Rails guy.

Generators Some could do a beautiful job, such as configuring whole heroku-related stuff for you. Too bad generator-heroku doesn't work as expected (tried it sth like 2 months ago). Same was true for travis generator. In this case fix was easy, but see the next point. As for Angular generators (I'm Angular guy, not Ember guy, sorry :-) ) - it just adds 2 files and includes them in index.html, furthermore if you are using not so straight-forward syntax for creating JS framework related stuff (sample: Angular-related stuff in coffee) generator will most probably not know about it. Ok, you can submit a patch to generator, but then AngularJS team decides to change the syntax a little bit in the next release - you get the idea ? - again, see the next point. What is more, if your project uses layout in which code is structured by feature/module (e.g. admin module, profile settings module, ...), not by type (directives, controllers, ...) framework-specific generators won't work.

Stability Karma is evolving rapidly, so does Angular, Angular-UI and loads of fronted tools, frameworks. It's really difficult for Yeoman to keep up with most recent changes, although they do a nice job here.

Employing Yeoman: Being cutting-edge

Yeoman provides some really cool stuff such as:

Linting

Compiling coffeescript, SASS/SCSS, etc. on the fly

CDNifying Really useful when you want to have libraries downloaded locally in case of developing offline and still benefit from pros of CDN. Without Grunt you would have ended up writing scripts parsing your HTMLs

Automated JS/CSS minification Grunt does it for you. You only have to configure it properly.

Encouraging separation and low coupling of your frontend and backend As for your question: I doubt that you'll be able to manage Rails part solely with Yeoman. A good recipe for a web app in Yeoman & sth is: https://stackoverflow.com/a/19425461/1432478. That's for Django, adapt it accordingly to Rails.

My opinion

In majority of small projects based purely on Spring MVC, Rails, Django, etc. you simply don't perform any of things done by Grunt (hence there's less time expenditure for setup). There are cases when producing technologically advanced frontend is a must. e.g.: Most recently I discovered that my bank account management system doesn't minify JSes. Even funny comments are left as they were. I didn't perform any rushed money withdrawal, but I hope they at least have server-side validation. :-)

Yeoman is a really good combination of solutions facilitating all those chores.

Using only Grunt? IMHO No. Yeoman is Grunt when it comes to app assembly. You get Livereload and other stuff for free.

If:

you're lucky and found sample config that seems to work for the web framework of your choice or managed to configure one on your own don't have deadlines to hold

then you should probably give it a try.

If you will work on multiple projects, chore of configuring it once might pay off by copy-pasting config to future projects. But keep in mind that frontend technologies are rapidly evolving, that's why tons of samples from the net simply don't work out of the box.

Further reading :)

http://blog.tfnico.com/2013/07/considerations-for-javascript-in-modern.html

Java world here, but I hope some concepts will be useful:

http://addyosmani.com/blog/making-maven-grunt/ Javascript web app and Java server, build all in Maven or use Grunt for web app?

更多推荐