I'm trying to decide if I should include Compass when starting a new Rails 3.1 project. I haven't used Compass before.
Rails 3.1 now supports SCSS directly. The Rails 3.1 asset pipeline (via sprockets) now compiles stylesheets automatically. And I can use a SCSS version of a CSS framework such as Blueprint directly.
What benefits will I get from using Compass with Rails 3.1?
Compass provides a lot of good mixins, a pretty powerful sprite-generator, and a tight integration with Blueprint in a way that means you don't have to use non-semantic col classes all over your HTML.
There's not really much benefit to using Compass if you're not using the mixins, but then again there isn't much benefit to using SCSS if you're not using them (nesting and variables are nice, but mixins help keep browser-specific implementation of properties in a single location).
However, I found Blueprint to be more of a hassle than it is worth. I would still use Compass for the mixins, but right now compatibility between Rails 3.1 and Compass is terrible (you have to jump through some hoops and you still sacrifice some functionality).
In a somewhat related note, the way Rails 3.1 compiles assets is rather "broken". It doesn't consider how the community has been using Sass for the last year or two — keeping variables, mixins, and page partials all separate to be included by a master file in order. The "automatic" way Sprockets loads and compiles Sass disassociates files from each other, so even if you define the load order manually in your application.css, variables you set in a file are not available to subsequently loaded files.
Bourbon (by Thoughtbot) is a light alternative to compass that integrates well with rails 3.1.
It has the main css3 mixins you get with compass (background-images, box shadow, border radius, gradients...). It also has helpers to style buttons, "gridify" your layout and a few more goodies.
You might miss some of the power features compass has, but that can be easily overcome with the power of sass : just copy/create you're own mixin!
Compass often gave me headaches when upgrading my rails app. I appreciate the simplicty of Bourbon (although it might give you headaches as well... in the morning :-) )
Compass is a design-agnostic framework - e.g. you don't have to worry about which browsers the users have.
e.g. Compass has add-ons, like for example the CSS3 cross-browser features:
http://compass-style.org/reference/compass/css3/
this way you can specify things in your .scss files browser-independent
Side-Note:
The way Rails 3.1 processes .scss files, is one at a time -- e.g. if you define variables in one file, they don't get carried over to the other .scss files. IMHO not really optimal solution.
The html5boilerplate compass plugin is a great time-saver too, so for these reasons I would use compass
Related
What is the most elegant way to get a riot based UI today?
i'd love the following points to be addressed:
A proper code-mapping for easy debugging
A good way to bundle the application (so far i used Webpack and JSPM)
It would be lovely if it would work elegantly with Typescript.
Is it best to use Tag files, or straight JS? If the later, would it be better to use a class that inherit from riot's tag class? If so, can i place the template code in a different file?
Future compatibility: i saw that there's going to be a change (that "export default" thing) - how would you recommend to write the code for the smoothest migration path?
If you have more items for consideration - please add them....
Thanks for asking these questions. I have tried to answer to all your questions hoping they could be useful also to other Riot.js users
A proper code-mapping for easy debugging
the riot compiler generates simply javascript code without modifying too much the structure of your original source code. Any modern browser should be able to provide with debugger breakpoints and console calls all the debugging tools you need. Check for example the stack trace of this error you don't need much more to figure out where it's coming from.
A good way to bundle the application (so far i used Webpack and JSPM)
In this repo we provide 3 different javascript bundle examples: rollup, webpack, riot-compiler. I personally prefer rollup but you can (and should) use whatever works best for you and your team.
It would be lovely if it would work elegantly with Typescript.
The riot public methods are already available as Typescript interfaces:
- https://www.npmjs.com/package/#types/riot
- https://www.npmjs.com/package/#types/riot-route
I am not a typescript user and that's why I will not invest time in making examples in a technology I don't use but PR are welcome
Is it best to use Tag files, or straight JS? If the later, would it be better to use a class that inherit from riot's tag class? If so, can i place the template code in a different file?
I recommend you to just use Tag files because riot was designed as component library and it embraces completely the philosophy of components composition vs class inheritance. If you have code you share across several components you can either use mixins or import it with your bundler directly in your tags see for example
Future compatibility: i saw that there's going to be a change (that "export default" thing) - how would you recommend to write the code for the smoothest migration path?
Riot 3 will be not compatible with Riot 4. (that will be a full rewrite) I can't recommend any best practice to make your code portable to Riot 4. Remember that Riot 3 will be still supported and your code will run even on IE9 for the next 10 years. Once riot 4 will be released and the API will be stable I can provide more hints about a migration path.
We are testing HAML and SASS on a recent project to speed up our development flow.
We built the static front-end, and from here, will be integrating the source into a Wordpress build. HAML isn't going to be used in the WP integration; we only used it to rapidly build the static front-end. However, not that it matters for this question, but we're using SASS throughout the entire build and into the WP integration. We're using Prepros as the preprocessor.
So, when building in PHP, it's pretty simple to use partials to make the front-end build more organized and efficient. No problem.
But we're using HAML on this project -- as an HTML generator -- and would love to integrate the language in all future builds if we can figure everything out. And we're trying everything possible to avoid having to expand into learning Ruby and/or configuring a complex development environment.
Anyways, using the overview above, is it possible to use partials to construct layouts in HAML without over-complexing the build? I've seen many answers relating to yes--and the answers are there--but the background information and semi-documentation just happens to never be there.
If anyone could point me in the right direction, that would be absolutely amazing. Please know that I appreciate any effort and advice from the community!
Thanks again,
B
I am converting a good old ASP.Net website to a single page application using Ember.js in a ASP.NET Web API project.
All the devs of my team and myself are pretty new to javascript. We spent the last 2 weeks learning the basis and comparing SPA frameworks. I apologize in advance if my question sounds stupid :)
All the Ember tutorials I have found so far included all Handlebars templates into one single file. I assumed it would be pretty obvious to split them into separates files (*.hbs) when the time would come, but it's not. I might be totally missing something here, but I found about 4 ways to get my templates back when I need them. I'd like to know which method you would recommend:
Concatenate and then inject all the template files when the app loads. I could write some C# code on the server-side that concatenates all the templates files into a single one when the app loads (i.e. each time a visitor enter the app). It seems odd to me, in terms of processing, but also because the generated HTML file will be pretty heavy.
Load each template dynamically via Ajax when I need it. Pretty much what is done here. I kinda like this solution even though I haven't tried it yet. It makes sense to me to get asynchronously a template when I need it instead of loading the entire app on the first load.
Use the Bundling mechanism of Asp.Net MVC. I found stuff like csharp-ember-handlebars to precompile the templates on the server-side and return them as a single javascript file. It works-ish but I feel like the precompiled file will become pretty heavy as I add new templates.
Use Grunt with the plugin grunt-ember-handlebars to precompile the templates. I'm not familiar with Grunt but if I understand well all the devs working on the project will have to install Node.js + Grunt + learn how to use a command prompt + remember to run the command before each commit (if they modified a template). This is not obvious for the web designers. And adding grunt to the build actions will require the entire dev team (working on other projects) to have grunt on their machine (not acceptable).
I need to find a simple and elegant solution to address this issue. My project is in a solution with 35 other projects and I cannot add too much complexity to the build, neither depend on unstable libraries. Maybe I have been too optimistic when I thought I could use Ember for my project. Any suggestion would be welcome!
Your #3 is the most ideal (and common) way that I've seen applications handle templates. With a compiled and minified template file you really don't have to worry to much about performance problems in regards to adding new templates, especially if you take advantage of caching.
One benefit to having the templates compiled and available off-the-bat is that users only need to Download Your Resources Once™, as apposed to downloading resources for each subsequent page load. This leads to a fantastic user experience.
Can someone explain why I would want to use the less.js script along with its stylesheet? I don;t understand the purpose and its advantages. Thank you. Erik
Less.js is a CSS pre-processor, it means that you will be able to write your in style using the Less pre-processor languages in a *.less file, then Less.js will compile it into pure CSS.
CSS pre-processor comes with a lot of powerful features such as: variables, mixins, nested rules, operations, imports and a lot more.
With Less.js you have two options:
Running Less at client-side: write your styles in Less then include the JavaScript pre-processor: Less.js.
Running Less at server-side: write your styles in Less then run the pre-processor using Node.js or Rhino, and in other cases you may use some ports like DotLess.
If you have potentially large Web Interface Design (complex layout, sprites, multiple navigation, several forms, etc...) then you should consider using one of the popular CSS pre-processor like Less.js or Sass. They will help you a lot.
Keep in mind... there are big project build on top of CSS pre-processor, Twitter Bootsrap use Less and Compass is a great framework that will kill your aches related to cross-browser issues concerning inline-blocks, clearfix, box-shadow, etc...
Having been inspecting a few elements on Google, i noticed that their naming conventions are fairly funky, ie.
.n-Wa-q-Dc, .n-xb .n-Wa-q-Dc:hover
This is clearly not readable/manageable by a human. Is it the opinion that Google's CSS and class names are largely auto generated by server side technology.
I cant see people maintaining such a CSS file myself.
Would it be advisable for such a large system (Google) to have any people managing the CSS and just to let the systems handle it?
They should have a version that is human-readable (for development) and, from that, generate the obfuscated version (for deployment). Most likely, a search-n-replace is performed on the names of the scripts or stylesheets (from using human-readable to obfuscated ones) before deployment.
It looks as though they probably ran their css through a minifier to reduce the size of the css file. As