Since Laravel 5.4, the default method to compile assets is using Laravel Mix, instead of elixir.
I know that "Mix" uses WebPack by default to compile the assets.
What benefits does this method bring?
The Mix also allows you to compile without WebPack, and this always
produces files that are smaller in size and work the same.
This is entirely incorrect. Have you attempted to configure any of the myriad options to optimize your bundle at all?
Start with the webpack-bundle-analyzer plugin. This will give you an idea where your bloat is, what is duplicated, and where to start trimming your application.
Between uglifying, chunking, deduplification, minification, etc. you'll have in the end compiled resources that are far from "large".
Now I'll grant you it has a steep learning curve comparative to other tools, regardless, WebPack is an incredibly powerful tool, you need to take the time to learn it's configuration capabilities.
Care to elaborate on what you mean by working the same? I run several production applications as well as a number of smaller personal projects. I never seem to get different results after each build.
But in the end it's just a tool. A tool like any other tool, you use what you feel comfortable with and what fits for the job. There's a reason it as selected as the default, though. And it isn't because the maintainers are ignorant by any means.
Related
I'm new(ish) to Laravel and I've been trying to get a clear understanding of how to use Faker to generate my test data. One of the things that's really confusing me right now is the different versions of Faker that I'm seeing in code examples. Some of them use fzaninotto/faker while others use fakerphp/faker (which I see is built into my Laravel 9.41.0 app).
What is the difference between the two packages and which one should I be using? Or will I need both due to differences between what fakes each package can generate?
I'd really appreciate some advice on this matter. I have a suspicion that the fzaninotto version is an older version of the fakerphp version and that I should simply use fakerphp and just think "fakerphp" whenever I see examples that use fzaninotto but maybe that is just wishful thinking on my part....
I'm fairly new to Vue and only learn a little bit of it. Actually it's my first time seeing this beautiful library (whatever you may call it ) And i saw many developers actually pulling many dependencies from npm like vueify, and many more. Now, I just want to ask. I'm only a beginner. and what i know is to just pull of my files and store them in my resources/assets/js folder and just do elixir on them. And, is it really a good practice to just pull of those dependencies and browserify/webpack on them regardless the size of the app i'm developing ? Humbly asking for opinions
I am beginning to use Go for web development, but I am having issues with asset management. I would prefer to have a tool like Rails' Asset Pipeline for managing (and compressing) css/js files (as well as SASS), but I am still able to work with css and js files.
While I am able to work with css and js, I am not able to work with SASS. Is there a way to use SASS in a Golang project? I am not using a framework.
Thank you!
I'm not familiar with Ruby on Rails but, I assume, that ruby on rails gave you some sort of tools for managing the source to distribution client-side asset transition (polyfills, transpiling, minification, compiling of SASS/SCSS to CSS, compiling of XScript to JavaScript ... etc).
While a web development framework might do that to try and ease in developers quickly (I assume rails does that, not ruby) its not exactly the way Go does stuff.
Go is a language, not a framework + language, just a compiler, a few build tools and a set of standards for how to write, test, document and indent stuff (with the indent,test and document part being optional).
A go server, at least the way I built servers with go, is somewhat decoupled from the client. It server static assets when they are needed (e.g. it serves the minified JavaScript and the stylsheets and the html, and jsons with info from the databases... etc), but it doesn't really care about what those are, its a server. The go toolchain is made for building golang applications (e.g. said server), but its not made for building client-side web applications (those consisting of js, css and html).
Now, you may use a framework similar to rails written in go that helps "pack up" css, js, html. But I'm unaware if there are any.
You may use a compiler which turns go into client-side code (i.e. javascript) https://github.com/gopherjs/gopherjs , if you enjoy the go toolchian and want to use it for client-side development. But, go-like performance isn't something this gives you AND you are working with a subset of go. Its really just a different way to write javascript.
However, what you most likely need in your case is a "build-chain" for your client side. Here there are 3 tools which (in my opinion) stand out in 2016:
npm
webpack
bower
I could write an essay about using this tools but here's the summary:
Webpack is used to create a "pipeline" for your code which does thing like, calling babel on javascript, compiling sass to css, minifying assets, allowing js to be written with import syntax... etc, really, its a swis army knife in your js development arsenal and probably matches the functionality of whatever you were using before.
Npm is the node package manager BUT even if you are not using node for your server. It can be useful to keep tracks of dependencies for building your application (like webpack) and for downloading modules. Its also useful for running various scripts and deployment, its a bit of an overkill to use both npm and weback though you will probably have an easier time setting up the webpack enviornment if you have a package.json (config file for npm) with each of your project.
Bower is one I actually don't use for small projects. But its basically a repository for javascript libraries (among other things), so you can easily say, write "bower install jquery" and you've downloaded jQuery for your current project.
Again, there are many other tools out there, these are just some of the ones I like, but, check some of them out. They can help you replaces your previous pipeline. Don't think of client and server side code as being the same, they are decoupled and having a strong separation between them might help you a lot.
I have used backbone boilerplate on the past
https://github.com/backbone-boilerplate/backbone-boilerplate
I want to use marionette on my next project and I have found this
https://github.com/BoilerplateMVC/Marionette-Require-Boilerplate
My question is if it's a good idea to go with the marionette boilerplate or start form scratch.
As an aside, I'd like to suggest you give Yeoman a shot for scaffolding your first Marionette app. Yeoman works via what are called "generators", and provide much more than the the above Boilerplate MVC can offer you (Chai and Sinon for testing, Bower for client-side package management, etc...). Plus, Addy Osmani, who runs backbone-boilerplates is one of the heads of the project. Check out generator-marionette here.
I haven't used BoilerPlate, but glancing through it, it certainly seems like a valid approach to writing Marionette apps. If you're just getting started it will certainly help you see how the various pieces are supposed to be used. One gripe I've got is the folder structure. I prefer to break my applications down into modules, and then add models, collections, views, etc under each module. But this will certainly get you up and running quick, and there's nothing stopping you from customizing it to suit your needs.
I agree with others here: it is a useless limitation to imitate a folder structure that follows the 'old mvc model for server-side code'. You will remain more flexible further down the road if you think of your application strictly as completely self-containing modules, i.e. they contain their own controller/router/views/collections/templates etc. You can have a separate folder structure for shared code that is not a module, although anything can be made a module :)
Regarding boilerplate code and generators: i think in the beginning you should actually NOT do it, because you won't understand what you're doing. But that's just my personal opinion.
Let me elaborate on the question...
I have a custom CMS (built on codeigniter FTW) that includes many different types of modules.
Every time we have a new project come through the door, it is a variation and amalgamation of a few of the existing modules.
Sometimes a project comes through with requirements that are not satisfied by the existing modules, in that case I will write a new module...
All the modules are separated out in folders and the code is VC-ed using GIT. Every module has it's own Model, View, Controller, SQL and Javascript files. All the dependencies are also separated and folder-ed nicely...
The next step for me is to create some sort of installer script that will take me through the "scaffolding" process step by step, allowing me to choose from the existing modules. A glorified "makefile" if you may...
Rather than rolling my own, does anyone know of any such thing out in the wild.
I know of Apache ANT (java), what I need is something in pure PHP with very low or no dependencies...
I would like something as simple as running a git pull and then php make.php
Thanks.
The "Ant-like" alternative I am aware of in PHP land is phing it is written in PHP and it will allow you to perform several tasks for packaging, deploying and testing your web applications. The documentation is a great starting point if you want to hit the ground running.
It is can also be extended to define new tasks if needed (examples and explanations are provided in the documentation)
Reading through the doco it appears to be possible to install Phing without PEAR as documented here you would have to correctly setup the environment on each machine you wish to use Phing on. I can not confirm this method though as I use PEAR for all my installs.