I have a small (and maybe dumb) question. I am working on my final year project and I was wondering if I can use bootsrap and tailwind css together. I know that they can be used together, I am not asking how to, I am asking if its bad practice or if it will impact the application in a bad way (maybe slowing it down since the app.css is twice as long). I have worked with both of them in the past and I would like to use tailwind on some pages and bootsrap on others. Any advice on this will be appreciated.
Thanks.
As a general rule, it is better not to use too much css in a page for both reasons you mentioned: speed and compatibility.
If you are sure about the compatibility, then it leaves the speed issue.
It is all about a compromise between optimization and ease of implementation which is very subjective.
Related
I stumbled on a web app project that was using ElementUI and spent most of the year updating dependencies. Ended up installing PostCSS and rebuilding the admin Panel how I wanted it to look and feel. It way recently decided to install Vuetify as the UI components are more modern looking and they use tailwind.
Whilst it has given some dated UI components a better feel. I still find myself reskinning and re theming. In some cases building my own transitions or adding new effects.
I hate using apps that have a repetitive UI.
My question is is there any point using Vuetify as at times I find myself battling with their "skin" and using a ton of CSS !important - which doesn't seem like good practice.
Sometimes I see UI or /UX design, and I think it looks cool, but I don't always want the whole thing. I'm the only one on the team that has been fond of tackling the CSS.
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.
I want to use onsen for a mobile web app. Most people seem to use it with phone gap/cordova so that the result can be installed as an app.
Am I going to have performance issues if I use it for a website?
The minified JS alone is 350kb and the css is almost 200kb. I suppose I can gzip it but I just want to make sure I'm not misusing the tool and doing something crazy.
Hmm actually
https://cdn.rawgit.com/OnsenUI/OnsenUI-dist/2.0.0-rc.15/js/onsenui.min.js - 85KB
https://cdn.rawgit.com/OnsenUI/OnsenUI-dist/2.0.0-rc.15/css/onsenui.css - 3.2KB
https://cdn.rawgit.com/OnsenUI/OnsenUI-dist/2.0.0-rc.15/css/onsen-css-components.css - 25KB
These are the only 3 files which you actually need to use Onsen UI.
If you want to use something like angular, react etc there are additional js files which you may need, but only if you want to use the frameworks.
And of course for the css - if you want to use some sort of icons either font awesome icons or something similar you would need to add those too, but if you're not using them you don't need to serve them.
As for performance issues
for loading you can concatenate the files to make less requests (you said you will be gzipping them so I guess you will probably also be doing this)
after everything is loaded I don't think you will be able to notice a difference between the app and the webpage.
I may be missing something, but I think this is pretty much it. Basically just include the things which you need - no need to include angular bindings if you're not using angular for example :D
The problem I am encountering a great number of imported files. I am trying to slowly inject webpack into a legacy site. There are many global stylesheets:
require('../../../Content/Ones/_forms.scss');
require('../../../Content/Ones/_grid.scss');
require('../../../Content/Ones/_panels.scss');
require('../../../Content/Ones/one.scss');
require('../../../Content/Ones/_grid_tools.scss');
Is there a way to avoid this? I might be just looking at this from the wrong angle because I can't seem to find a question that matches my use case.
Please advise, Thanks!
The SASS files you import (whether you import them from a JS file or another SASS file) are part of your webpack dependency tree, so they should all be watched automatically. If they're not, would you mind adding some more info to your question about your app structure and webpack config?
As for reducing the number of global SASS imports, there are a few ways to do that, but making a good choice here really depends on how your app is structured.
Side question: Is there a reason you're adding webpack to this site? Anything in particular you're hoping to gain? I ask because if it's not a component-based SPA, you might not be getting very much out of webpack, and it may not be worth the trouble.
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.