I've started my first ember.js project with ember-cli including ember-cli-broccoli-compass to compile my stylesheets with compass. Now that I've done my first styling, my stylesheets need 5 seconds to compile. When I now work on my javascripts and there are any changes to my files, my whole project, including the stylesheets, is re-compiled, which lasts a bit too long for me. So, is there any way to exclude the stylesheets from the compiling process?
EDIT:
I don't know this is "the answer", but using https://github.com/quaertym/ember-cli-compass-compiler instead avoids the problem.
Not sure on compass but I think its related to this issue over on ember-cli-less with sourcemaps
https://github.com/gdub22/ember-cli-less/issues/10
https://github.com/ef4/broccoli-sourcemap-concat/pull/3
The issues have been closed but on a fresh ember new they are still present
Related
I'm completly new with Django and python (and alone as tech in my company, not able to ask help to previous dev). I have to maintain an existing app written in django still developing new services fully written in node, which is my most important task (and my skills). I have a problem that i have fixed some bugs in UX, fixing CSS mostly. And I don't understand how to build sass.
In manage.py, when i ask the list of commands the only things which is related to my problem is "collectstatic" which seems to not build but just collect static files (good naming so) in one folder. And obviously, it doesn't resolve my problem.
Any suggestion ? I'm lost in this big new thing. Many love on every body who can help me. Do you know if there is an integrated tool ? Do i need to use an external compiler which is just not documented ?
Django got nothing to do with compiling assets, you compile it your way in node using your favorite bundler like gulp or webpack and then introduce the final path to django. but people stumbled upon this and created bunch of helper libs, checkout django_webpack.
In case you felt overwhelm then save learning curve time and do like I said earlier, bundle it on your flavor and create a management command in Django that you can run the bundler from python context.
This is the second time i'm commenting about this problem and I really hope you can help me this time since i've gained some more information about the problem. So the problem is basically that all my Django projects doesn't update the static files (this also includes projects which I have downloaded). So I can fx still see the old styling from the css files but the changes is not displayed. When i insert the css or js directly into the html file i can see it though. I thought that it maybe had something to do with my browsers stored caches but I have tried to do a hard refresh, clearing all my caches, installing whitenoise and forced browser to reload the css file by adding an extra parameter to the end of the src tag. I have also tried python manage.py collectstatic and almost everything else on this thread.
When the problem bagan to occur I was working with the implementation of stripe. I don't neccessarily think that stripe is the problem since the problem occured hours after i had already implementet the checkout site. I just think it's worth at least mentioning.
Some of my venv packages:
Django | 3.0.3
django-bootstrap4 | 2.2.0
stripe | 2.50.0
Weird behaviour:
Yesterday when I decided to comment out the bootstrap link to see if that was somehow the problem, the changes to the css file got applied to the site. I tried to do that several times and that seemed to be the problem but that only worked for like an hour. Now I cant apply any changes to the sites whatsoever.
My first post:
If you want to see my first post about the problem, you can check it out here. Keep in mind that the problem is not only happening to my Django projects but also the projects which i've downloaded.
I have no idea whats happening and I would very much appreciate your help. If you need any more information please just ask.
Edit:
I created a new folder and css/js file and it kind of worked. I believe the reason it worked was bcs whenever you create a new css/js file, Django needs to atleast load the content of the file once. But whenever I wanted to make other changes it suddenly didn't work again. In my file i had two links to css files. This should usually not be a problem, but apparently it was for me. I deleted one css link and It suddenly worked fine again. If anyone knows why this happened pls tell me, i'm all ears.
Assume you did everything correctly! I once faced this problem too and I fixed it by changed the directory name inside static folder to the same name as my app name. static/css/style.css change to static/app_name/style.css. Also don't forget to refresh the browser (ctrl + r or cmd + r). Hope this would help.
I'm facing an issue when moving my less files to a pod structure outside the styles folder.
I'm trying to put i.e:
pods/user/register/style.less
pods/components/app-login/styles
and import them from my styles/app.less file.
but so far it just compiles for the first time, but does not watch for future changes. I tried to create a symlink inside my styles folder to pods folder but sometimes works and sometimes breaks broccoli compilation so I declined.
Do you have a better workaround for this? For the moment im going back to the old structure.
Do you need to use Less? The Ember core team may bet on Sass and incorporate https://github.com/ebryn/ember-component-css into the framework at some point in the future. Using that addon would provide you with everything you are after ...
No code involved yet, so morning to show. I am trying to get into it.
I am writing an ember.js application, using require.js as AMD. I am trying to wrote an ember component, and having a hard time deciding what goes where.
The templates are in their own directory and loaded by need using text.js (in the 'define' statement of require), and compiled in the ember view.
As far as I understand, the components need to be in /components directory, which I have done. But what from there? At what route/view/controller do I load them, and how do I compile them? I tried just loading and compiling in the view, but that have me an error, complaining about env not being there. I tried extending Ember.Component and compiling there, but I he l got the same error.
Did someone ever implement components using require.js? Can you me a skeleton of how it looks like?
I haven't done it with require.js per se but if you download Ember App Kit, they're using EcmaScript 6 Modules.
Still, the modules are transpiled to require.js modules by es6-module-transpiler, so I assume it has to be similar. Moreover, you're free to use require.js inside the files as well.
Remember that the component's name has to be in the form: my-name, at least one dash (-) included.
Out of curiosity: why don't you use ember-cli or aforementioned Ember App Kit?
THE PROBLEM
I'm looking for a way to decrease the 40-50 second wait every time our SASS needs to compile into main.css. I've already gotten it down from over a minute by switching from using Compass for compiling to using grunt-contrib-sass. I need to get it down to 5-10 seconds, or as close to that as possible.
CAN'T USE LIBSASS
I'm a little bit stuck using SASS 3.3 and Compass unless we absolutely have to switch for the performance. We do use bootstrap-sass so it would be hard to get rid of Compass entirely. This means we can't easily switch to libsass. But any code in Compass can also be copied from their repository directly into our _mixins partial so anything is possible with enough effort.
USER THEMES
The worst thing for our speed by far is that we have different usergroups, each with their own set of variables used to compile the SASS with a custom theme. So our SASS needs to compile once for the main theme, main.css, and then once more for each usergroup in the system to make their theme.css. As we add users the compile time that results when any of our main partials are changed increases linearly. Any suggestions to speed this up are also welcome.
REPLACE #IMPORT WITH REQUIRE?
I read on the TreeHouse blog that #import slows things down a lot when using the stock Ruby SASS compiler. We do have a lot of partials, and the user themes as well, and we have bootstrap-sass rigged to compile using our variables instead of bootstrap's default ones. So there are a lot of #import statements. TreeHouse used Sprockets in their Rails project, replacing #import with //=require, to speed up their ~1min SASS compilation to something like 3 seconds. Django has a port of Sprockets called django-gears, could implementing that have the same effect on our SASS? Can we use django-gears together with grunt? There doesn't seem to be much mention of using the technologies together in the Google-sphere.
(edit: found the article I was talking about, updated this section. http://blog.teamtreehouse.com/tale-front-end-sanity-beware-sass-import)
Edit 2: No, Grunt and django-gears don't really work together. I don't think we need to use Gears to achieve this effect though. I'm going to try using some sort of Grunt file concatenation plugin to replace the Sass #import statements, I'll report back here about what it does to our compilation time.
CONCLUSION
Anyway, that's all the research I've done so far, pretty much. We could rewrite our SASS to work with libsass, which would be tough and take a decent amount of time. We can implement django-gears to possibly-maybe speed things up using require. Or, not mentioned yet, we can replace Grunt with Gulp. Gulp seems to have a slightly faster version of grunt-contrib-sass but might cause trouble if we need a plugin later down the line that doesn't exist for Gulp (since Gulp is smaller/not as well-supported as Grunt).
Is there anything that I've missed so far in my research? Any further suggestions? I'm not terribly experienced so any sage advice Stackoverflow has to offer would be greatly appreciated. :)
Posting this as an answer instead of an update to the question because we did find an acceptable solution to our speed problems. There's always room for improvement though (and our compilation time is still hovering at a bit above average). I ended up refactoring everything to work with grunt-sass and our total compile time, including all main and customer themes, dropped to ~5 seconds.
By the way, using grunt-concat or any other way to circumvent the Sass #import statement didn't speed things up at all. I'm not sure what crazy bug the TreeHouse Blog developers experienced that implementing Sprockets fixed, but what worked for them didn't work for me.
The real breakthrough came when I found the article Is Libsass, the lightning fast Sass compiler, ready for prime time?, written by Ben Frain. He mentions a library called sass-list-maps, written by Lu Nelson, that emulates Sass 3.3 maps in lower versions of Sass. Using sass-list-maps and some of the other tips in that article, I refactored our Sass until it resembled a much earlier version. It didn't take a huge amount of time despite our large codebase, I just commented out all the partial imports in partials/_all.scss and added them back in one at a time, compiling with grunt-sass each time and fixing any errors (manually inspected the CSS too, there were some bugs there that didn't cause compilation errors).
The only thing left to work around was Compass, which wouldn't compile with libsass even after I copied it into our project from github. We ended up replacing Compass with Bourbon, a mixin library that will add itself to the file structure of your project so it is easily accessible to import. It also has the side-effect of being very lightweight and sharing most of the same syntax as Compass so almost no changes were in order there. It's fully compatible with libsass/node-sass.
In the end, our Sass compiles way faster, and everyone is happy. 5 seconds is still a little on the long side with grunt-watch running it's only a minor annoyance. If I manage to bring the compile time down more I'll post how I did it here as well.