I just started looking into dotless for my VS2012 solution and it seems that the less is compiled down to css every time a request hits the less file. This seems like a waste of cycles - I'm not going to be changing my CSS that much, and if I do, I'll deploy again.
Is it possible to use LESS as a developer-only tool to generate css that the clients download directly? A compile-on-demand version that I would use only when I make changes?
I don't see the benefit of compiling per request... if anyone can shed some light on that as well, I'd appreciate it.
You can using bundling and minification in .NET 4.5 to bundle and minify your LESS files into CSS.
Here is a quick guide on how to do it. Bundling and minification with dot-less
Related
I need to be able to edit vue build files in production. Its faster to modify production files on fly instead of finding right version of productioncode, changing it, building it and then deploying.
I tried prevent vue-cli and webpack to bundle it but that didnt work.
Problem is that vue build is not much readable to change. Is there any way to have build files in more readable format?
This is not a great idea. But if you need to, I would recommend petite-vue.
Or check out Vue's dokumentation on using it without build tools
I've been developing in Aurelia-CLI for about 3 months and like it so far. I think it's a solid framework and obviously escalating in support and usage. That's a good thing!
Before I develop much more of my large app, I'm wondering if I'm using the best build system. I've only tried Aurelia-CLI and am not really familiar with Webpack or JSPM, and therefore I don't know what I'm missing. Are there any clear advantages or disadvantages in using either of the other two build systems, or is using the CLI the most clean and supported approach? Since I'm developing independently, I don't have any external constraints.
Thanks for your help.
UPDATE
This answer is almost two years old. Feel free to research updates and provide another more complete answer and I can replace this answer or point to that answer. Thanks!
Aurelia CLI
Aurelia CLI is great for getting started. It's important to understand that under the covers the CLI is using require.js but proxies the configuration through aurelia.json in your application. This means that you need to understand how to configure aurelia to work with require.js at the moment. Once you need to start configuring to match your workflow or change build steps up it gets a bit cumbersome at the moment. We are working to improve this. There are many features planned for the Aurelia CLI but given at the time of writing this that it is in an alpha / beta state it should generally be used on proof of concept or other smaller apps, not production-ready large scale apps yet.
WebPack
WebPack is arguably the most popular kid on the block at the moment. WebPack is not a module loader, but a bundler. It's important to understand this because while we strive to make Aurelia work great with all module loaders WebPack by default is not in charge of loading modules so a dynamically loaded application requires the developer to expand on this. WebPack is strong in creating optimized bundles and can be easy to use as long as you are comfortable with configure WebPack. WebPack has considerably more GitHub stars due to the popularity from React using WebPack it's hard to say whether the choice is better when using Aurelia simply because of the number of GitHub stars.
JSPM / System.js
Some of the skeletons use JSPM and System.js. The reason is that these are the closest to 'spec compliant' solutions. JSPM tries to help as much as possible when loading from the JSPM registry. If not yet available in the registry you can load from NPM or GitHub directly. From a module loading perspective you use a config.js file that is (usually) automatically maintained when installing dependencies to improve the developer workflow.
Side biased note
On most larger apps at the moment I typically prefer using JSPM / System.js simply because I have a great understanding of the tooling and prefer the control that I am provided. I work on a great number of Aurelia apps that are in production and typically reserve CLI for smaller proof of concept apps and WebPack is a great alternative but I prefer the flexibility and understanding I have with JSPM / System.js at the moment.
The CLI isn't currently feature complete, but it is a much simpler setup. Webpack can basically do anything you want to do, but you'll be maintaining your webpack configuration just as much as you maintain your Aurelia code.
Ok, maybe not just as much, but you'll have to learn Webpack to use webpack. The Aurelia CLI is simple to get started, but has some definite limitations. For example, CSS files that reference external resources won't work w/the Aurelia CLI, but they should work fine with Webpack.
First, I can understand if this post gets shutdown due to its subjective nature.
I believe it's time to re-visit the answers about Aurelia CLI being a second-class tool. I respect both PW Kad and Ashley Grant immensely, but I am just not convinced that a statement like this is true anymore:
There are many features planned for the Aurelia CLI but given at the
time of writing this that it is in an alpha / beta state it should
generally be used on proof of concept or other smaller apps, not
production-ready large scale apps yet.
Notably, I have a production application that way back in the day I started with Aurelia CLI, and changed it to JSPM precisely for the reasons noted. But recently, I rebuilt the same app from scratch using the CLI and I realize that it is much easier to use, particularly managing modules and publishing! And this is an app with Google Maps, Google Analytics, Auth0, DevExpress, Bootstrap, etc.
Just think it is time to give Aurelia CLI a little love. It's ready.
Aurelia CLI is the most preferred option with this announcement.
http://aurelia.io/blog/2017/08/18/aurelia-cli-webpack-update/
Now It has more flexibility for your choice of preferences.
I am curious to know why when I create a new Aurelia project, each project installs +600 node_modules. Understandably, the modules collectively don't take up a lot of space, but are all of these modules necessary? I was under the impression that Aurelia's aim was to help developers move away from depending on 3rd party libraries so it seems odd that each project comes with a massive dump of 3rd party libraries.
My guess is that you are starting your project from CLI - which comes preset with HTTP server, ES6/2015, SASS, live-reloading and more.
I created clean Aurelia project and looked at the package.json - there were 5 dependencies and 34 dev dependencies. Using all of above mentioned tools is somewhat standard in today's JS web development, and generating project from CLI reduces time needed for upfront setup. All of these features come with their own dependencies, and that's why node_modules/ folder grows rapidly.
The bottom line is - you could start new Aureila project with much fewer dependencies. On their home page you can find starter project with just three. But that also means that you won't have access to most of the tools used today.
Also, and correct me if I'm wrong, I haven't got the impression Aurelia ever aimed to move devs from third party libs and modules, just to be modern, fast, and unobtrusive.
All modern web frameworks have a host of tooling. The reasons in no particular order -
1. Transpiling ESNext or TypeScript - if you want to write in Future JavaScript but have it work in all browsers, you need this step. Both Babel and TypeScript tooling comes with extra stuff too. If you want to see coverage (everyone does) there's another tool.
2. Testing - Unit test and End to End testing require testing frameworks, test runners, and if you want to write like above (esnext or TypeScript) you also need transpiling.
3. Module Loading / Bundling - Require.js, JSPM/System.js, WebPack, etc... are used to allow your code to actually run in the browser. Without a module loader you could not break your code out in to separate files. Without a bundler you would be loading a lot of extra files in production.
4. Serving your application - If you want to run your app locally you need a way to serve it up and watch for changes.
5. Debugging - You want to debug? Now you need a way to debug the file that gets served to the browser back to the original source.
6. Linting - Lint your code base for style consistencies.
Each of these packages usually have their own dependencies, and they get pulled down as well.
This convention of small packages that have a single focus is arguably better than massive packages that do everything for you. This allows you to remove a package and replace it with the one that does the same thing but in a way you want it.
I really like the idea of this BundleTransformer plugin from NuGet, and I see that they have LESS support. But ...
After weeks of trying, I cannot find any decent example of how to use it. The documentation is unclear, to say the very least. This is the closest I could find, which does not compile or work.
who-could-ask-for-more-with-less-css
Well, the simple answer is that I could ask for more.
Can someone please assist me with the simple task of creating a bundle that has .less files in it, that will run? I am completely lost.
I would suggest reading the wiki page for bundle transformer and also, as the wiki page suggests, make sure you are familiar with ASP.NET bundling and minification.
If you follow the examples of usage you should be up and running.
I know this is an older post but figured I'd chime in. The Bundle Transformer Codeplex discussion board (Feb 2015) mentions that BundleTransformer is no longer considered a modern client-side build tool and they are recommending you go with Gulp or Grunt - which both have support starting in Visual Studio 2013.3 via VSIX extensions and more baked in to VS2014. FYI -This Scott Hanselman post explains how to get up and going with Grunt and Gulp in Visual Studio. I think if you're using BundleTransformer for simple Less compilation it works fine, but doesn't allow you to do things like generate CSS Sourcemaps which make your browser's dev tools aware of the Less source files, which in my humble opinion is critical for using a CSS preprocessor - the ability to see the LESS line numbers of your source files in the styles pane.
I have just jumped on the Sublime text wagon and really want to optimise my workflow using LESS. I have looked for a plugin that performs the compiling clientside, in fact I could just add the less.js file to all projects, but I can't find anything to explain how to get it to work.
Also I was thinking that it would be best to install something on the Apache server that comes with MAMP to do it server-side and then I wouldn't have to worry about adding certain files and copy the preprocessed client-side code for the production website.
I use CodeKit (Mac Only), which does what you want SO WELL, plus so much more. I really can't say enough good things about it. I'd recommend checking out the site and the videos to see what it offers.
There is also this ST2 plugin:
https://github.com/BBB/sublime-text-2-plugins
I haven't used it personally because of how well CodeKit works. But it is another option.
Just to clarify, these aren't options that install and run on MAMP, but I think once you check them out you'll see they still provide a solution that doesn't require you to add extra files to your projects.