I'm trying to decide if I should use Angular CLI for a new project. My primary reason for doing so would be to avoid the hassles of setting up a new project right now and instead focus on learning the new Angular and building the application.
I'm coming from Angular 1.x so the hassles for me stem from learning all the new tooling in addition to the new Angular. Most of the docs reference systemjs but webpack seems like the direction the community is moving in so I would like to go that route.
I would prefer to learn and become comfortable with the Angular toolchain (including webpack) but I'd like to push that off a little if possible. I generally don't prefer "black boxes" like the CLI.
I would like to start by using the CLI and then break away at a point in the future when I have time to invest in learning more about webpack, etc. My question is: What limitations does the CLI put on me, can I easily break away from it in the future, and generally what else should I consider before using it as a quick way to get started?
I started working with Angular 2 while it was in Alpha, long before Angular-cli was available. During this early stage I struggled with the build environment - I was using systemjs and a whole pile of self-built spaghetti code of gulp tasks to handle transpiling, minifying, bundling etc. For every hour I spent writing angular code, however, it seemed I was spending two hours on the build environment. Did I learn alot? Sure. Was it a good use of my time? Not very.
The angular-cli changed all of that. It was built by the Angular team to accomplish all of the development and build tasks that an angular developer needs. It is always improving and when there have been problems they have been address quickly. I now can create an ng2 project in a few minutes with "ng new projectname --style=scss." I can run immediately in development mode with "ng serve." Changes automatically get compiled. I can build for production with "ng build -prod -aot" and have my entire ng2 project ready for production in minutes with Ahead of Time (aot) pre-compilation and tree-shaking.
So my advise to anyone would be this. If you want to quickly get into the serious work of building ng2 apps, and not waste your time re-creating the build and production environments yourself, then use angular-cli.
If you have time to burn and want to learn more about what's underneath the hood with angular2, then have a go at it yourself; you will certainly gain a better understanding of things; but you'll just end up using angular-cli anyway.
I am going to argue against using the CLI.
I have been using Angular 2 from the early days before RC. Indeed there was a lot of confusion back then, having to deal with all these packaging solutions (require.js, system.js, webpack). I got to admit that it was not a pleasant time back then, and it drained a lot of time.
BUT
Nowadays, I have a strong skill set in setting up builds and deployments. I have experimented with lots of possible ways to configure it and to achieve greatness. Recently we had to develop a plugins architecture for our webapp at the office. Guess what, knowing webpack has saved my skin big time. I was able to find an initial solution which was not that great. Eventually, after polishing it and taking advantage of webpack, we have created a really nice solution, with minimal code, without interfering in either webpack or angular architecture.
There is no chance that I would have been able to do this without all the pain of having to deal with webpack constantly. I hear very often misconceptions from my peers about how webpack and angular works. I do my best to explain stuff, but nothing beats doing it yourself. I'm sorry to say, but hiding behind the CLI will do you no good. A senior developer that I can trust to create new architecture must have solid webpack, angular and typescript know-how.
If you do not understand these tools properly you will be relegated to the menial tasks of applying existing patterns never to be trusted to go out there in the wild jungle and creat the new architecture for others to follow. You need to be able to think for yourself and to take your own decisions.
Conclusion
See whether or not the CLI is the tool for your current task and choose accordingly. Don't just blindly follow the first advice you see. If you are in charge of a project and you have to call the shots, knowing webpack is a must.
I am in same situation as you, but after doing a lot of research on the subject, I have come to the conclution, that it is perfectly fine to use the CLI to build Angular 2 projects.
The CLI is supported by the Angular team and in constant development with a big community - even turorials and the NG2-Book use the CLI as the configuration.
The CLI use Webpack integrated and exposes the configuration through the CLI json, but I read that soon it is possible to use command 'ng eject' to eject the webpack config file itself (if needed).
I believe the future (even now), that it's normal to use the CLI with integrated webpack, instead of using Webpack as a seperate bundler.
Related
We have a modular monolith application, each module being an extjs app. Modules share alot of features / functionality, therefore the most of code is sitting in a common extjs package that gets imported into each module, the module themselves are relatively thin. We also provide an accessibility build, ie., everything is built at least twice (once with normal theme, once with high contrast), but for some apps more (some logic is managed through extjs macros to exclude / include different regions at build time).
The end result is agonizing build time. ~10 apps, each built at least twice, each build lasting just under 2 minutes. It's all because each app is built from scratch. Is there a straightforward means to build it together? So that instead of rebuilding extjs code / common package code / themes 10 times, it would be just built once and reused in build process of all apps?
This looks very relevant "saving and restoring sets" . But it seems to be some lower level feature, which would as far as I understand it come useful if we were reimplementing build process from scratch and tossing out app.json. Is there a clear way how to incorporate it into existing higher level features like sencha app build?
You could go ahead and build the packages (if any) separated from the application, then drop the packages in the owning directories of the build. However, Sencha CMD and the way the class system and resolving the dependencies works makes it really hard to untangle the build process, so it's hard to give a general advice here.
You might want to look into the package loader of Ext JS and the "uses" configuration option for the app.json.
Create react app is an awesome way to setup a new react project. However i can see it forces certain decisions onto you that come baked in, eg using Jest rather than other test runners such as karma/mocha. As I am setting up a new greenfield project with React, am trying to identify is the best practise to stay with it and accept certain constraints or do most teams end up ejecting and in the parlance of brexit "take back control" and what the reasoning is.
create-react-app actually has a lot of sensible defaults and make it an ideal starting point. But they also regularly update things to stay in sync with where the industry is going. So that's great. And it is maintained by some of the same people responsible for React.
The biggest drawback (and strength) is that it doesn't include many other libraries. You have to add those yourself.
But if you do that you occasionally find that you need to add or tweak a small thing in the Babel/Webpack config.
Luckily there is a middle group. Using libraries like react-app-rewired (https://github.com/timarney/react-app-rewired) allows you to make small changes to the Webpack config without ejecting just yet.
Once you do that you will want to be very careful with upgrading react-scripts. Because every time you do it might break your Webpack changes to their script.
But only once that pain is too much would I consider ejecting.
I am from a microsoft background where I always used to keep server and client applications in separate projects.
Now I am writing a client-server application with express as back-end and react js as front-end. Since i am totally a newbie to these two tools, I would like to know..
what is the general practice?:
keeping the express(server) code base and react(client) code base as separate projects? or keeping the server and client code bases together in the same project? I could not think of any pros & cons of either of these approaches.
Your valuable recommendations are welcome!.
PS: please do not mark this question as opinionated.. i believe have a valid reason to ask for recommendations.
I would prefer keeping the server and client as separate projects because that way we can easily manage their dependencies, dev dependencies and unit tests files.
Also if in case we need to move to a different framework for front end at later point we can do that without disturbing the server.
In my opinion, it's probably best to have separate projects here. But you made me think a little about the "why" for something that seems obvious at first glance, but maybe is not.
My expectation is that a project should be mostly organized one-to-one on building a single type of target, whether that be a website, a mobile app, a backend service. Projects are usually an expression of all the dependencies needed to build or otherwise output one functioning, standalone software component. Build and testing tools in the software development ecosystem are organized around this convention, as are industry expectations.
Even if you could make the argument that there are advantages to monolithic projects that generate multiple software components, you are going against people's expectations and that creates the need for more learning and communication. So all things being equal, it's better to go with a more popular choice.
Other common disadvantages of monolithic projects:
greater tendency for design to become tightly coupled and brittle
longer build times (if using one "build everything" script)
takes longer to figure out what the heck all this code in the project is!
It's also quite possible to make macro-projects that work with multiple sub-projects, and in a way have the benefits of both approaches. This is basically just some kind of build script that grabs the output of sub-project builds and does something useful with them in a combination, e.g. deploy to a server environment, run automated tests.
Finally, all devs should be equipped with tools that let them hop between discreet projects easily. If there are pains to doing this, it's best to solve them without resorting to a monolothic project structure.
Some examples of practices that help with developing React/Node-based software that relies on multiple projects:
The IDE easily supports editing multiple projects. And not in some cumbersome "one project loaded at a time" way.
Projects are deployed to a repository that can be easily used by npm or yarn to load in software components as dependencies.
Use "npm link" to work with editable local versions of sub-projects all at once. More generally, don't require a full publish and deploy action to have access to sub-projects you are developing along with your main React-based project.
Use automated build systems like Jenkins to handle macro tasks like building projects together, deploying, or running automated tests.
Use versioning scrupulously in package.json. Let each software component have it's own version# and follow the semver convention which indicates when changes may break compatibility.
If you have a single team (developer) working on front and back end software, then set the dependency versions in package.json to always get the latest versions of sub-projects (packages).
If you have separate teams working on front and backend software, you may want to relax the dependency version to be major version#s only with semver range in package.json. (Basically, you want some protection from breaking changes.)
Questions: What is the correct / proper structure of Frontend and Backend together? How do I publish whole project after It's done? Will it just work if I copy it all to some host? (I know I have to modify DB paths and stuff, I'm worried about all the updating that composer does.. or am I understanding it all wrong)?
Short explanation of how I got here: I'm a student developing a Time management web application (Projects, Tasks..). I have knowledge of PHP (Slim), JS (JQuery, Angular), HTML, CSS (Bootstrap), SQL. My development flow was first creating a database and setting up an Apache server (Linux). After that I started coding by simply creating a folder, adding sub-folders for backend (DB operations..) and frontend (js, css, view, images...) when I needed them. All the includes were downloaded when I needed them (jquery, bootstrap etc.). I never used composer/ npm /bower.. Which brings me to this:
Current situation: I was about to upgrade form Slim 2 to Slim 3. In the last 6 hours of googling I've completely lost motivation and at the moment I feel like I have no idea what I'm doing. Almost every article/tutorial I read gives me different information: Composer? Bower? npm? Yo?... I feel like I'm doing it all wrong. I tried few of those seeds that create a clean project for you.. WHAT ARE ALL THOSE FILES. I even tried one that creates clean structure of Angular and Slim in one project. Needlessly to say I'm completely lost. I feel like I did all those 100 hours of coding while I should be studying for nothing, since i have no idea how to properly use it.
I'd really appreciate any tip, suggestion, links to stuff that'll help. I feel like all the knowledge of coding I have is just useless since I have no idea how to use it properly. Thank you
This is very simple to work with composer and npm for Slim3 and Angular2
both are different files and main folders
For Slim you will use composer to download all files in vendor folder
For Angular you will use npm to install all files in node_modules
folder
Even the required file is different composer.json for slim and package.json for Angular.
I use Slim with Angular 4 now inaa project and every thing is going smoothly
I don't know what kind of problems you faced, but I'm sure both can work together
My question may be inapropriate but I'm asking anyway. When I check some websites developped with angular, with the code inspector you don't see the applications JS files (app.js, controller, ...). But when I'm checking mine I see everything and it can bring a large security issue.
Do you know the way of "hiding" them please ? Thanks in advance.
Picture showing what i'm talking about
You need to bundle your files in one single file. During this process you can even minify and/or uglify your code so that it is more hard to read. This should be done for production only because in development, you want to be able to debug your code with readable code.
You can use tools like gulp which is pretty easy to master and can do a lot of great automated stuff for prod and dev environment.
Here is a nice Getting Started with Gulp or go to the Official Website
If you make a search in SO with "gulp bundle", im sure you will find some similar questions.