So I just started learning Laravel, and I want to build something cool with it. I've been working mostly with frontend development, particularly AngularJS, and started using RequireJS recently.
I like the way Yeoman generators set up front-end applications as far as the directory structure, (i.e. /app, /test, /dist) and would like to continue using this structure, but I want to pull it into the overall application. I also like that in most cases, the application uses unbuilt files (particularly JS) for development because it cuts down on waiting for processes.
How can I set up and structure my Laravel (or any other framework) application and templates to use a similar directory/build setup for files? The problem I keep getting stuck on is using unbuilt/uncompressed files for development, as well as a clean separation of my source vs. built front-end files.
Since starting with Laravel I have tried all sorts of Asset Management tools and methods. I ended up using Stolz/Assets, an ultra-simple-to-use assets management PHP library that can be installed with composer. It is not an ideal tool as there are some issues when minifying (particularly CSS.)
Like you though I really needed neatly compiled and minified js/css assets for production.
After much research I have ended up using Gulp.js after reading this blog post (http://www.abishek.me/using-gulpjs-with-your-laravel-application/). I immediately downloaded and installed Gulp.js and created a gulp file with my own directory structure in it. I was up and running within minutes. I have since gone on to modify my gulp file so it now compiles SASS, minifies and compresses both CSS and JS for production.
I continue to use Stolz/Assets (Asset Management Library for Laravel) for serving up my files but I do not rely on this for any compiling or minification.
Related
What is the need for bundle.js for Node.js/Angular/React applications? What if its not used while building and deploying the application?
Where bundling comes from?
We started bundling our assets because of performance reasons.
HTTP1 supports limited requests on a single connection. Creating connections for each asset was killing the performance.
We started bundling things page by page to increase performance with more effective caching.
We were able to add the fingerprint to it and upload it to a CDN. (home-page.231434.js). So we were able to deploy our application by dockerizing it.
Bundling also helps us reduce the page size more because the bundler knows the full system. This means it can remove unused things and minify things easier. You can't do it without a bundler easily.
Also, bundlers are using transpilers. Browsers can't always be able to run the codes that we write like Typescript, and CoffeeScript. Bundlers can transpile these codes easily into bundles.
Do we still need it?
Nowadays things are changed a lot about bundling our assets.
First of all, almost every browser now supports HTTP/2. So we can request multiple files on the same connection. Bundling is not needed because of this anymore. Also, we have http/2 server push.
Libraries like React, Angular, and Vue are a lot more effective in size. They can be easily downloaded to a page from a gzip supporting source.
These are the reasons we don't need bundling anymore.
But based on your project we may still need bundling. This is the real truth.
I would still go with bundling.
In my company, we are using a container orchestration system to control our dockerized applications. We may run more than a version same time. Creating fingerprints for files while bundling and uploading them to CDN is still more effective for us. And also we are trying to get use of prefetching and preloading. CDN helps us reduce the loading times of other country visitors.
And also we are getting support from the service worker to change assets when we need it by page.
So actually nowadays it is just based on your project. There are not many performance reasons anymore.
how to create bundle.js
Nowadays,we usually use pack tools like webpack to pack js、css or other files.With proper loaders, webpack will pack the files into many bundle files and the browser will understand them.
the need for bundle.js
The module bundler will analysis the project ,find the dependency relationship and only fetch the necessary package when loading the web page.
And with module bundler, it will compiler some lanuages that browser can't read, like typescript 、less and so on.
What if its not used
Module bundler is not necessary for web project, but it will improving the performance of web pages.If not using the module bundler, web can't only fetch necessary bundle when loading.So the loading time will be longer.
My web development is principally intranet sites and web front-ends for embedded devices using NodeJS.
My current structure is to have everything in one NPM package. I run NodeJS behind Nginx, and let Nginx serve css/image/client-side-javascript files directly from public.
I'm starting to use VueJS and Vuelidate, both of which use the now ES6 modules system - e.g. import { required, minLength } from 'vuelidate/lib/validators'.
While I've (rather hackily) made these work with my current structure, I think the time has come to get into the world of Javascript build-systems/bundlers.
If I use VueJS's preferred option of WebPack, how should I change the structure of my code?
Should I have one NPM package for the frontend (generated by vue-cli init) and another for the Express backend app?
Should I put my Express App into the generated Vue frontend package?
Should I use browserify to do the job of WebPack and stay with my existing structure?
Or something else entirely?
I’m not sure why you’re intent on putting your JavaScript code in other packages. If you have an application then you can keep your raw JavaScript files in there, along with the build script(s). Someone should be able to check your application out and be able to build it.
If you’re looking to get started with a build system, then a nice “bridge” might be to use Mix, a project created by Laravel for building front-end assets such as Sass and JavaScript. It uses Webpack under the hood, but in turn exposes a more user-friendly, fluid API.
If you go down this route, then you could put your raw JavaScript files in a lib/ or src/ directory. You could then use Mix to compile these components like this:
mix.js('lib/your-entry-point-script.js', 'public/js/app.js');
Your entry point script would just be the script that requires all your other scripts and components and the script that you want “built”. Mix would then compile that and place the resultant script at public/js/app.js.
Mix itself is just a npm package, so all you need to do is npm install laravel-mix --save-dev.
You can read more about Mix at https://laravel.com/docs/5.7/mix
I'm a back-end java developer (spring boot) and currently I'm interested in building a single page application.
What I like about SPA frameworks (mostly Vue):
Model-binding (saves boilerplate code)
Components and templates (separating code in multiple files is always good, but I don't like single file components as I feel they mix the view and logic)
Routers
However, unless you are using Node there seems to be poor integration
What I don't like:
Node (I develop backend in Java so I don't want to install node just as a prerequisite for NPM)
NPM (I already have dependency management in Maven/Gradle. I actually don't mind it as much, I just don't want to install it and manage it seperately)
I understand why stuff like Node, Npm, Webpack is necessary, it's just that I've already have Java/Spring/Eclipse doing all that for me. I have no desire to have basically two separate build processes.
TLDR: I like the direction and architecture of modern frontend, I just don't want to deal with the tools that are used.
Specific Question: How can I develop a modern SPA using Spring Boot, Gradle/Maven and Vue.js and not have to install Node/Npm/Vue cli etc. What are the best tools if there are any?
Thank you.
You can use maven frontend plugin hosted from here.
It is maven plugin that is leveraging downloading nodejs, webpack, gulp, grunt and running it on your codebase.
You will be able to run maven build and nodejs will be downloaded automatically. It will run your frontend build as well and in resulting jar you will have only necessary minified files.
However, you have to be aware that if you want to debug your frontend application it is a good idea to have those things installed and being able to run the app locally without minification of html and js files.
If you don`t want to download tools you can use helper scripts provided by authors of this plugin to use tools downloaded by this plugin.
I've got two projects which I've created:
A web UI built using webpack
A Vert.x webserver written in java built using Gradle
I want to find a way to bring the resulting build dir contents of the first project into the second as the webroot which will be server up using the StaticHandler.
Is anyone aware of a clean way to do this? I want to preserve the two git projects as they are because I like using the webpack dev server for development of the UI and it generally feels cleaner to have them separated.
I was looking at potentially using the bitbucket pipelines build on my repo, however bringing the assets generated by the first project into the build of the second is where I'm facing issues.
You could create a gradle task that before that depends on the jar task (so it runs before it) executes webpack compile into the resources directory. So when your jar task runs it bundles the compiled webpack code.
I am about to start a new emberjs project and I cannot decide whether to use requirejs or rake-pipeline.
The ember advice seems to be to use the rake-pipeline.
Anybody any thoughts on either side of the argument?
If you want to load the dependencies dynamically after page load on an as-and-when-required basis then requirejs is the preferred option.
However if loading all the script when the page loads is not an issue for you (amount of javascript is small, or lot of javascript is required just for the rendering of content) then rails asset pipeline reduces a lot of boilerplate for you because even if you use require js you will eventually have to use r.js compiler to bundle all the dependencies into a single script. Rails does all of this concatanation and minification transparently behind the scenes without you having to do anything at all. Using the rails asset pipeline eases rolling deployment for you because in development scripts are all served as individual files without minification and in production scripts are served as minified and concatenated. This does not require you to run any build script or optimizer upon every change and you don't even have to modify anything in your HTML files. As long as you follow the sprockets specifications and specify the dependencies (which you have to do in case of requirejs too) everything works out of the box.
Also, Rails asset pipeline does not tie your client application to rails platform as sprockets (the dependency manager used behind in the rails pipeline) can be used independently without rails.
If however AMD compatibility is important for you (for example you are planning on using the same code on a NodeJS server as well as client, or are creating a distributable library) then requirejs is a great option.
You can also take a look at https://github.com/jwhitley/requirejs-rails/ which attempts to integrate requirejs into the rails pipeline. Please make sure that you have a reasonable level of familiarity with both requirejs and rails before you adopt this approach.