I'm currently building an angular app with browserify ends up everything is in a bundle js file including angular.js itself and other vendor libs. I am wondering is it a common practice for using browserify or I'm doing something wrong here?
Wouldn't say you're doing anything wrong; its a matter of preference.
I would personally create 2 separate bundles, application and libs, just because I prefer to have that separation in my build.
With separation, upgrading/swapping libs won't require a re-bundle of application logic, and updates to the app won't require a re-bundle of libs. Based on how your build is structured this could increase speed & efficiency, especially if you have watches in place.
Related
This may sound like a strange question, but I come from an emacs,xterm background and I am used to work a few files and have total control of what I am doing.
Now, I am going to learn react and vue, but when I examine the number of files that are generated for a project with:
npx create-react-app
vue create app
then it adds upp to 36000 for react and 19000 for vue. That is something that annoys me. Is there any way to create a project in both framework that has significally less files?
What you are referring to is scaffolding. You do not require scaffolding to use vue.
You are also using build components to minify JS code and include all types of things such as fall backs.
If you want to learn it from scratch you can start with the CDN version then move onto learning to use the templating engines and so on.
If you really want to start to learn things from scratch.
Use CDN Versions
Learn Rollup.js
Learn Vue
I've started curating an old web project based on tons of java code (old spring version) and a singular monolithic frontend module a.k.a. "The web-module" and I'm trying to upgrade the build steps and migrate old angularJS code bit by bit.
The idea was to implement Redux as a single point of truth between old and new code and Webpack for bundling new js files (vanillaJS/React) and other assets and integrating them in the old .jsp files that are littered with lots and lots of good old tags.
The old code is a mix of Javascript, jQuery and AngularJS, events are handled by jquery, I'm getting lots of funny side effects of conflicting / competing angularJS $scopes for every module I touched so far.
How does a sane individual integrate dist/ files generated by webpack into old .jsp files without messing everything up and/or losing her/his sanity? I feel kinda overwhelmed by all the things that might go wrong and I'm searching everywhere for success stories of people trying stuff like this. All I could find so far were migration guides but that's not an option with about 80-100 legacy angularJS files that would have to be rewritten for webpack so I need a solution that works side by side until I've managed to rewrite all the old angularJS Modules, one update at a time.
I am developing an application with a few modules. Each module is individually deploy-able on the server. I am using Angular for my UI.
Because I have 4 modules, I obviously have 4 different Angular projects, setup & files.
Though there are certain differences like routing, controllers, views, the external frameworks, libraries used can be very similar and I do not want to replicate all of them.
Hence I wish to have a common project/folder/directory and use these in different modules. this way I can avoid redundancy (if it can be called that). Can someone please help me understand if my thought process is correct? If so how can I achieve this?
Use a third party package manager like npm or bower. You can then add the libraries during build time with browserify or custom gulp/grunt code.
You can then bundle all you libraries into a single file and include it in you application.
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).
I have a clutter of files comprising my node/express/angular app. I want to build a more structured directory structure.
1.
Can I do this with Yeoman, now after we are 6 months into developing our app and if so, how?
2.
What are the benefits aside from the cleaner structure?
You can happily use Yeoman. I would recommend you to use Yeoman along with Grunt. I suits best you to build the minification process and removes the overhead of upgrading versions manually.
Yeoman generators are much better suited for ground-up development. That being said, you can potentially retrofit your exiting app to use one of the generators (maybe this one), but you'd be much better off running the generator in a new directory and then plugging in your existing code.