Framer
Framer copied to clipboard
koenbok
Have an option to use ES2015 instead of coffeescript
This just about covers all the reasons I think why this would be a good idea. https://gist.github.com/danielgtaylor/0b60c2ed1f069f118562
Just for the sake of healthy debate: http://tech.noredink.com/post/111583727108/dont-replace-coffeescript-with-es6-transpilers
IMHO at the end of the day the decision of "which language should I use" is really project / team dependent. In terms of the FramerJS project goals, which I understand are teaching designers how to code, I see Coffeescript as a wise choice as it is easily readable and clean -still, this is my opinion-.
An argument against Coffeescript would be that the community, tools, plugins and updates will certainly never be as dynamic and large than the ES6 one.
Talking strictly about language syntax, I could find these two ES6 features that are not available in Coffeescript:
- Iterable classes
- Constants (this one would be really nice to have in CS)
I agree a lot with your analysis Javi. I'd add one more ES6 pro: let block scope.
@jchavarri I get what you are saying but I'm suggesting a toggle to give the user the choice. I personally would like to write code the way I do in production today in Framer. I don't disagree with the syntax of CoffeeScript but for me I'd much prefer just to use ES2015.
We'll likely never support both at the same time, because that would effectively double our workload and would be generally confusing to our users (two document types).
@koenbok Yeah, you're right that wouldn't be very feasible. I'm assuming sooner or later you'll have to support ES2015 though.
I think we will slowly move towards ES6 when we get a little bit more native browser support.
Another interesting link that covers CS vs ES6: https://github.com/hemanth/coffeescript-equivalents-in-es6
@mattmischuk I understand, and I agree it would be awesome to be able to choose what language to use with Framer, but I also see what Koen mentions about effort duplication.
An intermediate solution –while Framer Studio moves into ES6– could be to create a custom ES6 Framer environment, using Babel, Gulp+Browserify (or Webpack or...) and the open source Framer codebase. Maybe this option could be explored using the boilerplate project I was working on, I'm happy to discuss it further!
I found today this language (framework? UI library?) that brings some interesting points to the table:
http://imba.io/
I second that, it will be so awesome if there is a toggle to switch between CS and JS. Not a ninja at CS so often will write my code in JS and use tools like http://js2.coffee to convert and paste.
I'd love to see vanilla JS support. ES2015 features would be useful, but I don't even think a compiled superset is at all necessary. I already know JS. I can learn Coffee, but it's a pain. I'd rather just develop in the language that's familiar to me.
Framer is a JS library at its core. I don't think it makes much sense to support CoffeeScript but not JS; that seems like a really strange decision to me.
I think the Framer team is looking at the feasibility of moving down to Javascript when ECMA6 gets better native support. In the meantime, if you want to use Javascript, you can always use the open source Framer.js (: Although, you will miss out on all the super awesome Framer Studio features.
There is a really dirty way to be able to use JavaScript inside of Framer: Use CoffeeScript's embedded javascript to insert javascript, by placing your javascript code between backticks like this:
You will loose Auto-Code, most of the Auto-Complete functionality, and a lot of syntax highlighting, but it works :)
I would love to see this as well. It’s making me think twice about using framer as I can’t stand to use CoffeeScript anymore, I have pretty much got rid of it out of our organisation.
I think we will slowly move towards ES6 when we get a little bit more native browser support.
The version of Safari bundled with iOS 10 and macOS Sierra supports ES6 @koenbok.
I can't bring myself to encourage such a big overhaul, but having taught Flash+Actionscript, Processing, raw web tech, and Framer, I'm just not convinced that Coffeescript is the best idea for a first/introductory language. The shortcuts and über significant white space mean less to type but more to learn. Because one of my goals is to prepare students to encounter other technologies, Coffeescript's dissimilarity from more common C like syntax makes me anxious.
Do agree with @IanBellomy above regarding learning and future proof. It seems that we are feeding users with a solution that wouldn't help them in the long run. With technology comes and goes all the time. JavaScript is there to stay. People would love to invest time and resources to learn something that is beneficial in the long run.
That said, the ability to quickly and concisely do things like class Button extends Framer.Layer . . .
is probably what convinced me to give Framer a try in the first place. The team's work making a space where basic UI elements and their behavior can be crafted in sane ways is very appreciated!
If Framer would use ES6 it would be a very nice teaching tool for teachers who teach JavaScript it is so visual and easy to change properties and see instantly how the code changes. It is like the dream tool for teachers...
I am currently building the design to code pipeline at my company, I would seriously consider this tool for our prototyping if it wasn't in CoffeeScript. I would really like to see language options for this product.
All major desktop browsers now have very good browser support (Edge, Firefox, Safari, Chrome, Opera) @koenbok Is this still a plan?
Echoing others -- ES6 support has improved greatly, and coffeescript is the only thing holding my organization back from using Framer as our primary prototyping tool.
@doaboa Actually Andrew Liebchen made a project which lets you implement Framer via ES6 (even includes a Sketch plugin for exporting layers to Framer). https://github.com/andrewliebchen/ecma-framer
I'm still sticking to CoffeeScript just for consistency for reading Framer documentation, but with us using React Native to deploy our app, I can see this smoothing out the friction between design and development.
