On Tuesday, 22 April 2014 at 16:38:04 UTC, Andrei Alexandrescu
wrote:
On 4/21/14, 11:51 PM, Jacob Carlborg wrote:
On 21/04/14 23:23, Andrei Alexandrescu wrote:
I confess getting a bit uncomfortable about adding new
dependencies at
this point. We depend on dpl-docs already, and the tool was
difficult to
install and broke from one dmd release to the next. Sönke was
nice and
proactive about it, but he's an active member of the
community. If we
find issues with tooling coming from the outside - and we
will - we're
on our own. It would help if many people in the community are
fluent
with them.
I've used Sass a lot. Although not via node.
Good to know, thanks.
Adding a tool right now that has overlapping functionality
with
ddoc/dpl-docs, and that is relatively unknown within the
community
sounds like a tall order.
Sass doesn't overlap with ddoc.
I'm clearly outta my depth here, basing myself off of giving
http://sass-lang.com/guide a couple minutes. From what I can
tell here's how ddoc matches up sass features:
Pre-processing: yes
Variables: yes
Nesting: no
Partials, Import: somewhat (by passing several ddoc files to
dmd)
Mixins: yes
Extend/Inheritance: no
Operators: no
I'm glad to see a revamp of dlang.org happening. Again if the
added tools bring great advantages with them, fine. But we
can't add dependencies carelessly and only for minor
convenience.
Let me ask Aleksandar again: we already depend on dpl-docs
since recently. Is it helping/competing with the new tools you
plan to add?
Andrei
It's not competing with Sass. Sass would make it easier for me to
faster write needed styling and also more importantly to have
style files easy to maintain later (I had worked few times with
monolithic 3000+ lines long CSS files and can attest that it's
much easier to work with nice hierarchy of small SCSS files).
I can surely do without Sass and use plain CSS but to keep it
maintainable I would need to split it to multiple files and would
need a tool to concat those later to the target CSS (this can be
done with cat but it's non-standard on windows) and then I would
need a tool to minify that CSS.
These are simple tools, and they can be written from scratch in D
(which I would like to do, but then I won't be working on
redesign while those are done).
If I would use Sass, I would not only get really nice and
powerful DSL to write styles in but I would get tools to concat
and minify CSS.
As I've said in message to Dicebot I would not use npm as it
would be bad marketing, but I would really like to use libsass
(sassc - the compiler, to be precise, libsass is a library used
by sassc) which written in C.
If that's too much dependencies I'll have to go with plain CSS
files.
And I've already decided to use Make instead of gulp (a npm
packaged build tool for node.js).
The only thing that remains is JavaScript minifyer. I have tried
almost all of them, Google Closure Compiler, YUICompressor,
jsmin, UglifyJS and in my experience UgifyJS[1] is definitely the
best tool for that task (closure compiler can get your slimmer
files but you must stick to Google's rules of writing and
annotating your code, which I find too limiting).
The only problem with UglifyJS is that it's a Node.js
library/tool...
So I don't know what to do about that. Sure, there are online
versions of both Closure Compiler and UglifyJS but they cannot be
integrated in build system (well, not without requirement of
internet connection).
I wonder if DMDScript's parser could be used to write JS minifier
in D. This is actually something I would really like to look into
but there is definitely not small amount of work needed to
develop a tool like that. So it will have to wait, sadly.
So, as I'm not aware of any native good JS minifing tool I'd skip
that step for now. We can optimize that later (anyway, I'll keep
JS usage on bare minimum).
The only question yet remaining is if I can depend on sassc[2] or
not?
[1] https://github.com/mishoo/UglifyJS
[2] https://github.com/hcatlin/sassc
