1.0.0
I think it is time to start thinking on 1.0.0 version of Stylus. I already started adding the 1.0 tag to the issues I'd like to see at 1.0.0 release, but I thought it would be nice to have them all (with a lot more) listed here, at this page, as well as general thoughts on the future of Stylus.
Feel free to add anything you would like to see in the future Stylus, either at this page, or at issues
Stylus is not in the best shape.
It have a big codebase and a lot of things done wrong, a lot of bad decisions taken through the development. Some people could treat some of those decisions as something good, but most of them making the maintaining and developing Stylus harder and slower.
To move forward we need to rethink what Stylus is, what we would like to see there in the future, and what we don't need from what we have.
Great thing: with 1.0.0 we could break everything. It could be a major release that can be different from the current 0.x.x in a lot of ways. And, I think, we should do this. Let’s break the things!
One of the biggest problems is Stylus' syntax. Yes, it is very flexible. Yes, a lot of people love it (one of its variations). But right now this flexibility is slowly killing Stylus.
Each new feature, each new added thing needs to be tested in a lot of variations. You add a hash object and receive dozens of conflicts with existing syntax sugars thrown here and there in the source.
We need to change this.
The most proper way, in my opinion, would be settling with one proper way of doing things, then giving an optional way of using anything else.
I can see it this way: by default we would parse any stylesheet in a strict syntax, in case we happen to see any error (in the terms of this syntax), we should try to use the fallback syntax converter that would convert everything to the proper syntax, and then try to run Stylus again.
This way we would have much cleaner code and it would be much faster when wrote right. In other cases the fallback syntax would be used and it can be slow and not complete. There could also be things like use strict; in js to tell if we’re using only the strict version or loose, so we won’t make any assumptions.
I would mostly talk about the strict syntax, as we can throw out the backwards compatibility, we can change a lot of things.
There are a lot of common patterns you could see: for example, you could say we throw away a lot of transparency we can have in Stylus. This is an issue I would like to describe someday later, in short: transparent syntax is nice when it is defined explicitly. If we’re doing something transparent it should be our decision, not something that happen without us knowing.
-
The biggest question: should we have both indent-based syntax and braces-based one? Should be have them both in strict syntax? Or should we have only one as a strict one, and move another one into the loose area? I don’t have a certain answer to this right now.
-
Variables should always start with
$sign. This would make it so much easier to know where the variables are used. We could also remove the assumption that any non-defined variable is truey, soif $fppwould finally give usfalseif it is not defined. -
Interpolations should be written as
#{}, this would remove any possible conflicts we have and would allow us to use the interpolation wherever we would want. Right now it is not an easy task to add the{}interpolation to the new entities. -
We should remove the support for
property valuesyntax. Yes. this is feature a lot of people likes, but it makes the code really, really harder to maintain. Really. -
…
There are a lot of features that Stylus shouldn’t have. Those features could be done better by third-party tools and/or plugins.
-
@keyframes— right now they’re hardcoded, the prefixes are not actual and it have a lot of other problems overall. We should remove support for@keyframesand any other similar features if we have them there. -
Minified code — we should remove the flag that makes Stylus return a somewhat minified code. It is not Stylus’ task to minify the code, there are other tools that do this better. This don’t mean we shouldn’t make Stylus’ output better — we still wouldn’t render empty rulesets and remove duplicates from the selectors, but all the other stuff should be thrown away.
-
…
There could be a lot of things we can do with code. We could change the code style and use something like jshint or jscs to enforce it.
We should add tests not only for the styl→css conversion, but for the JS code itself too.