I don't understand why the generator-ionic (along with other ionic + Yeoman project)s are so popular.
I don't see what the advantages are in using a yeomen generator in this case, this is.
I understand why the Ionic framework is useful in a Cordova project (as we all know, the UI, ngCordova plugins, it uses AngularJS, ect) but what specifically does the Yeoman component add that a basic Ionic project doesn't already have or that cannot be easily added with a bower install.
It seems to me that the Yeoman ionic projects just seem to be unnecessary bloat and can lead to more errors and library issues. I just do not see how components like karma and grunt (as opposed to ionic using gulp) fit into help with development.
True, you can set all this up by yourself. However, imagine setting this up on each and every project that you start. Kind of cumbersome, don't you think?
That's why some people tend to create these generators - to save you (if you like) the time of having to scaffold your application every time from beginning. Usually they provide some features (about which you can read on the Github pages) or they may even enforce some kind of project directory layout (which may help with big projects).
All in all, you don't have to use them, or stress about them. For instance, I personally don't use them on every project, but I appreciate the community effort and when I want to try something quick I tend to test them from time to time to see how they've evolved.
Don't hate, donate ;) (Sure sure, I know you're not hating, the statement just seemed appropriate).
Related
I am looking to develop a React JS web app, using react-boilerplate for development
https://github.com/react-boilerplate/react-boilerplate
But the above boilerplate doesn't seem to be updated quite often, which boilerplate should be used for building simple web apps
Create React App is pretty much a single command setup with all the basic React boilerplate code for you from the command line.
Although as others have said, ideally you should look into setting up your own boilerplate to suit your own needs and maintain it as you best see fit.
There is not a simple good answer to this problem. Ideally, you should create your own boilerplate and maintain it over time, because only you will know what are your most common needs. There are no perfect boilerplates and almost every boilerplate is opinionated.
You might try to create a boilerplate for yourself from React CRA or other sources that might fit your needs in a great measure. It takes time in the beginning, but after a while you might update it every few months to make sure it is up to date and make it the starting point for all your new projects.
Sometimes a good point of inspiration would be the Yeoman Generators. Take
a look here: Yeoman Generators
React-boilerplate no longer to maintain, it has some library doesn't upgrade yet. You can try this repository, same about structure and way to use.
https://github.com/react-boilerplate/react-boilerplate-cra-template
React-boilerplate is not being maintained. You can use ARc which is a React starter kit based on the Atomic Design methodology, while I'll suggest you use create-react-app which is strongly recommended by the community.
I want to use react/redux. So I did "create-react-app test" after 5 minutes, I get a directory with 22,538 files and takes 131MB.
Meanwhile if I google, "jsfiddle react redux" and look at the first link I get a jsfiddle with just a few files it loads, all within the browser.
So why should I use create-react-app versus just loading a few dependencies in the browser? Is the overhead worth it? Is it mainly due to webpack?
I use create react app (CRA from now on) since react redux has too much boilerplate to manage things.
CRA is basically a startup-kit: that explains why has so much basic package asset in terms of import.
I can assure you that maybe you'll pay the cost to use redux on large projects (and dependencies...and packaging!!!).
Mostly depends on teams anyways, if you need to standardize how to operate on things and your team is large, Redux should be useful since this way of act avoids unexpected implementations because "there's a way" to do things.
my personal preference is not to use CRA. it was meant to be a starter kit for developers who want to learn react without wasting time on configuration and setting up the environment.
It is a fantastic learning tool if you start from scratch because all the magic is hidden from your view, you just focus on React and let cra take care of the details. but production projects are not that simple to handle. there are a lot of requirements which may come in and your cra may not support it. as it was meant to be a generic tool for learning react. you can eject it but then you should really avoid ejecting it as the config is extremely complicated.
with cra you are missing a very important base of your project. ie the webpack.
The way cra solves this problem is by hiding all the config by default, so after starting your project you are not exposed to Babel, Webpack, dev/prod environment, or any other config.
You start learning with a tool that does everything for you, but when you are ready to know how things really work under all that, what are you supposed to do?
With cra you have an eject script that can uncover all the config that is hidden beneath.
If you feel so adventurous to do it, you will find yourself into a really huge and scary config, meant to do a lot of stuff and designed to not be exposed to the end user.
if you are a senior developer then you must really try to configure your own webpack config according to your project requirement. webpack, babel, etc are very important because they are not just for react. you can use them in any modern javascript project. as a senior developer, you should really know how things are working, in case you decide to remove a library and add another you should know where and how to do it. and really should not rely on a tool that makes things simple for u.
All of this is not a hard rule to follow. but my personal experience .
Google knows best… but they're inconsistent!
The official ng CLI generates a scaffold one way, whereas the official tutorial chooses a different way.
I'm not talking just directory layout, typings.json vs types in package.json choices are also particularly worrisome.
What style am I meant to work with?
Angular 2's tutorial basically just shows the quickest and easiest way to get up and running with the framework. It omits mentioning things that could scare away a potential newcomer to the ecosystem, it is meant to be simple.
angular-cli on the other hand actively incorporates best practices, latest technologies like Webpack 2 Beta and tries to give developers a piece of software to quickly scaffold and develop scalable production apps without worrying about build-tools and configuration.
QuickStart
This is not the perfect arrangement for your application. It is not designed for production. It exists primarily to get you started quickly with learning and prototyping in Angular
angular/quickstart/README.md
angular-cli
The Angular2 CLI makes it easy to create an application that already works, right out of the box. It already follows our best practices!
https://cli.angular.io
See also: https://angular.io/styleguide
The owner of the DurandalJS project is now working at Google on AngularJS Next (v2?) in addition to keeping the current version of DurandalJS maintained. The two frameworks are converging.
http://blog.angularjs.org/2014/04/angular-and-durandal-converge.html
For a new mini-SPA project, which framework would be the best choice specifically with regard to the upgrade path?
I note that Rob Eisenberg has listed a number of tips to help existing DurandalJS users get ready for the next version, so it appears there will be an upgrade path available, but I'm wondering if the upgrade from AngularJS to the next generation framework would be simpler.
http://eisenbergeffect.bluespire.com/preparing-for-durandal-nextgen/
To be clear - I'm more concerned in making the right choice for the future (large SPA, split into multiple mini-SPAs) than for my current needs.
I'm not sure which one would be the best choice for now ... actually I'd say none of them is future save enough. Angular 2.0 is going to be definitely different from 1.0 and of course also from Durandal.
Nevertheless the framework itself maybe not that important. I think you should focus on separating code in reusable components. Whether it is a Angular Service/Factory/Provider or a clean Require Module in Durandal it actually doesn't matter. Getting it into the "NEW" Framework should be just a matter of adding the proper wrappers. As for 2-way-binding use the oberserver plugin to maintain clean POJOs.
The most important change from my perspective in NG2 will be the support of Lifecycle events, so even using those in Durandal now will be somehow supported in NG2. As for composition there for sure will be a way to simulate that easily in NG2 as well.
For current work the only two things important for the decision of the currently used Framework in my opinion are the use of RequireJS and Framework simplicity. Sure you can add it to Angular as well, there are several guides on that, but Durandal was built from ground up with RequireJS in mind. Especially in bigger projects this can save you a lot of headache from missing or wrong dependencies. As of the second argument -> porting Durandal to Angular is not that of a big deal because it's written in an easy and understandable way. Vice-versa may be a totally different story. Getting your custom Directives implemented as a combination of templating and ko-bindings can get pretty hard :)
So as a closing statement, if it's going to be a small project, but with the need for continuous support as well as update to NG2 in future, I'd go with Durandal. Besides RequireJS everything is exchangeable and adaptable. In the case of Angular I'm not sure how drastically the new DI system will change the way of development so that would be a show-stopper for me.
Btw. here is the design-document for NG2. So as you see there kinda everything that is important is gonna change:
Router
Persistance
Directives
Modularization (maybe we finally see RequireJS :) )
After having been convinced to learn and use Angular.js, I was going to start a concrete web UI application so as to launch the learning wheel of experience. ( The app is going to be some kind of personal planning, to do list, reminder, pomodoro technique oriented, and so on...)
One of the tutorial videos I have seen, by the author of Angular, is about best practices. And one of the best practices is to start with the angular-seed project.
That is what I was going to do, but after googling a little, there are already at least two other projects that claim to be the good starting point:
angular-enterprise-seed
angular-sprout
I'm beginner, but I like to invest in the long term. Should I worry about using something else than angular-seed ? I feel like it's too early to ask myself this question, but if there are already two other projects, maybe there are some good reasons.
I've found that though many people use various seed projects, the easiest & most consistent starting point for an angular app (or any javascript web app) is Yeoman.
This app is a scaffolding tool that allows you to specify generators which will build the up the kernel of your application, complete with whatever libraries you desire (via bower) and a working grunt build file (most generators come stock with a build task, server task for live editing, and testing task)
Though an app like this is necessarily opinionated, the scaffolding it produces is still very generic.
example:
mkdir my-app
cd my-app
npm install generator-angular
npm install generator-karma
yo angular
They all have different merits so it depends on what you are looking to do. I wrote angular-enterprise-seed and can speak to its relative merits.
It is server-agnostic. This is important since a core tenet of AngularJS, and one of many things that make it attractive, is that it follows the Client MVC paradigm. This means it is entirely decoupled from any and all server technologies. Many existing seeds tie AngularJS to server technologies, such as angular-sprout (NodeJS) or grilled-feta (Google App Engine/Java). In the case of the aforementioned projects, if NodeJS and/or Java environments aren't already on your system, then you will have to go through several hoops just to see the seed come up. This can be alienating to PHP and Python developers, which results in limiting the project's community.
Up and running in seconds. Because it is server-agnostic, it can be run in any container (heck the filesystem for that matter). Suggested method is running "python -m SimpleHTTPServer" from the root directory -- this comes native on Mac and Linux so there are no additional steps.
Live preview. It's cheap to check on status of the project because a live version is always hosted on github. Because it's server agnostic, this is automatically done by copying master to the gh-pages branch from a cron job.
Rich styling. It includes Twitter Bootstrap and custom/buildable LESS out of the box, along with Angular-UI, Angular-NG, fonts, and a myriad of other tools to provide rich styling and responsiveness capabilities.
Widgets. Like Angular-Seed and Angular-Sprout, Angular-Enterprise-Seed exemplifies "best practice" layout, routing, etc. But it also provides a host of pre-built components that can be taken off the shelf and immediately reused. This is a bit difficult to do as it can require the convergence of several technologies. For example, to create the grid example, I combined angular-ui, angular-ng, angular-js, and jquery styling. There are component examples for modals, pagination, alerts, grids, and more.
Angular-seed is great as an academic exercise if you want to learn how the pieces work, but it will leave you longing for a more substantial jump-off point.
I haven't used angular-sprout so I can't speak to its merits. Maybe there is some room to merge angular-sprout and angular-enterprise-seed?
I recognize that this is an older question, but it seems to have a fair number of views, so it makes sense to recommend what has recently become a very popular alternative to both Yeoman and angular-seed: ng-boilerplate. ng-boilerplate differs from angular-seed in that it's designed from the ground up for large production web apps, and therefore is a better solution than angular-seed in my opinion.
To explain the differences between the Yeoman and ng-boilerplate methods of app kickstarting, I'll quote ngbp's creator, Josh D. Miller:
Yeoman is awesome. But the problem I have with the generators for AngularJS is that they package by layer rather than by feature. If we store all controllers in a "controllers" folder and all services in a "services" folder, etc., and all our tests someplace else entirely, it can be quite challenging to reuse our components.
This is also pretty good discussion by Josh on the Yeoman angular-generator issues forum, that goes more in depth regarding the setup of ng-boilerplate vs. yeoman.
Just to be clear, Yeoman is not a generator. Yeoman is a format/system for making generators. There are several generators made with Yeoman that you can use to generate an AngularJS application. People often mistakenly refer to one or another of them as "the" Yeoman generator. But there are many. Confused yet? Yeoman isn't the only generator making system. Brunch is another one.
To answer your question, here is a very comprehensive side-by-side comparison of many AngularJS generators one can use to start making a web application with AngularJS. Currently, it contains over 200 different aspects of these things. One of them is file organization style. So you can easily see which ones organize the files by feature if that's important to you. It is to me.
There are still several of these left to be added. The two mentioned in this thread are new to me. But this comparison should give you a good idea of the options and how they compare. It's editable too, so if any of you are experts in any of these things, feel free to share what you know.
God only knows why people keep making more and more of these things instead of just helping to improve the existing ones. If you have any guesses, I would love to have that mystery solved.
EDIT: to gain access to the doc I ask that you either complete a questionnaire to share your knowledge of something or lobby the experts to do so.
Go here to do a questionnaire:
http://www.dancancro.com/technology-questionnaires/
I like using Yeoman as well. Try these to get a good scaffold:
npm install -g generator-angular # install generator
yo angular # scaffold out a AngularJS project
bower install angular-ui # install a dependency for your project from Bower
grunt test # test your app
grunt server # preview your app
grunt # build the application for deployment