Move from CoffeeScript to JavaScript?

[kinow]

I got a new job few days ago, but at both companies, JS developers asked me why the dashboards needed CoffeeScript. Being a Java developer, I am fine dabbling with CoffeeScript every now and then when I need to change a widget. But from what they suggested, looks like JavaScript has been getting better, and there is a new specification of EcmaScript 6 that they are using through transpilers like babel (from what I understand).

Today I fonud this library via Hacker News: https://github.com/decaffeinate/decaffeinate

And I wonder if this could simplify the code of widgets in the future? I searched " coffeescript ecmascript 6 " looking for comparisons, but what I got the most were posts about people migrating from CoffeeScript.

So for others with more experience in JS and CoffeeScript, and that are aware of the current trends with these technologies. Would it be interesting to start something like this? Or should we just stay the way we are and that's that?

I know @tylermauthe is looking into changes like Passenger, a Job class, and other interesting issues that I'm following. Perhaps we could release another version or two of the gem for maintenance, and plan a major release with these changes. So moving from CoffeeScript to JavaScript could happen at the same time - again, only in case it makes sense.

Thanks

[kinow]

Link to HNews thread with the comments https://news.ycombinator.com/item?id=14583882

And looks like there is an alternative path, from CoffeeScript to TypeScript... but I'd have to read about this one :-)

[aweiland]

I think the CoffeeScript dependency comes from having BatmanJS as the view layer. It provides both the scripting capability for data manipulation and view rending with HTML templates.

In a previous discussion there seemed to be a bit of consensus around vue.js. I've never used it (I am a React person). However Vue.js seems be be a bit more of a full featured framework, which is what you want to replace BatmanJS, which would make sense to me.

It'd be nice if this could be accomplished without bringing in some serious dependencies (like webpack).

[kornysietsma]

It'd be a pity to move to a complex framework like any of the ones suggested - especially as most frameworks do a lot of extra things that Smashing doesn't really need, such as responsive device support and support for legacy browsers.
Indeed, as Dashing is likely to be run on browsers under user control, it would be possible to bypass transpiling to es6 entirely. Maybe this could be looked at as an option - leave batman.js as the framework for now, but look at if we could just have an option to author tiles in es6 somehow, and get them to play nicely with batman.js

[aweiland]

I don't disagree. The trouble is smashing is built around batman.js and coffeescript which are both essentially dead projects.

[kornysietsma]

It's well worth noting that there's nothing to prevent people writing widgets in JavaScript / es6 - using http://decaffeinate-project.org/repl/ I've converted some of our widgets, and it's pretty painless, as long as you follow some of their manual cleanup steps. (and as long as you are happy to assume users have an es6 browser)

Maybe this is something that could be added to the docs, and/or there could be a sample javascript widget created.

[NicoJuicy]

Coffeescript isn't dead. http://coffeescript.org/announcing-coffeescript-2/ Discussion was here: https://news.ycombinator.com/item?id=15276833

[terraboops]

Coffeescript might not be dead, but I'm totally in favour of doing this... Wow this has been open a long time hah.

This would be a big enough change that it'd warrant a whole rewrite of all the things though... Would break widget compatibility, throw community into crisis, revolutions might ensure, etc etc. Highly related to the whole re-write in react would be awesome but then it breaks batman compatibility problem - kinda feeling like I don't care too much about backwards compatibility too much anymore.

[rherwig]

At my company, I'm working on a "coffee-less" smashing dashboard. I am using webpack along with ES2015+ in order to make this feel more like a "real" web app.

I would strongly encourage the use of ES2015+ instead of ES5, since classes and extensions make the transition from coffee much easier.

[kinow]

+1 @tylermauthe, regardless of the chaos it might create at first.

@rherwig if you find interesting things during your company's project, feel free to submit pull requests or send your suggestions to us :-)

[fixmycode]

This change, along with replacing Batman with Vue (and Gridster with an HTML grid) while maintaining the same API, would make Smashing a great app for 2018, maybe we should open a project and start setting some milestones? 😃

[markwooff]

Would love to see this move to something a bit simpler to use - if there's a need for more hands on deck I'd love to assist in decaffeinating Smashing!

[YtvwlD]

@fixmycode Replacing Gridster with another grid is already possible. You can do that in your configuration folder.
I've replaced it with a flexbox layout.

[rherwig]

@kinow Sure, that would be the plan :-)
@fixmycode I thought about using Vue as well... I tried react, but that does not seem practical at all for a project like this.

Edit:
I'm just looking into Vue integration and it could be achieved pretty easily, BUT:
At the moment, I'm trying to figure out the best way to layout the dashboards.
Currently, the erb files integrate the widgets via batman/plain html. With vue, this would be tricky and kinda silly.

What do you think about having, i.e. a dashboard.vue instead of a dashboard.erb in order to integrate the widgets?

[terraboops]

@rherwig - definitly would want to use latest ES specs. We could make very nice semantics around a redux style state store for widgets - in fact redux connect naturally lends itself to the exact sort of data binding we need. I think it will give us a better ecosystem of components overall if we use a redux-like implementation vs the default flux implementation -- but I don't want it to get in the way of adoption if that's too weird.

I'm biased towards React, but all signs seem to be pointing in the direction of Vue.js being the best choice for Smashing... I am finally forced to admit 😂

[rherwig]

@tylermauthe I too am biased towards React, since I absolutely adore it! But vue seems the better choice indeed.

The thing for me is: atm smashing is kinda focused on "easy of use". You create a widget folder with script, style and markup, include it in your template and it is there. Although I strongly believe that a state machine as well as a web component like layout would be highly beneficial, it might be a challenge to reduce the need to write much boilerplate for the user of smashing.

I guess, a proof of concept is needed to find out, how it would handle.

[terraboops]

Good call - I can think of many different implementations... Perhaps we should try to have a CFP of sorts, call for prototypes! Then whichever smells the best we can go with - or probably mix and match from a few. I think it would be good to set a constraint here on changing only the front-end codebase - whatever it is must be compliant with the existing SSE interface? Beyond that, the sky is the limit - react, vue, angular, mythril, riotjs, jadelet, jquery Thumbs up if you like this idea and if we say end of March is the deadline for prototypes? After that - maybe 2-4 weeks to pick and choose, and then implement `the future`.

…

On Feb 28, 2018, at 9:56 PM, Rico Herwig ***@***.***> wrote: @tylermauthe I too am biased towards React, since I absolutely adore it! But vue seems the better choice indeed. The thing for me is: atm smashing is kinda focused on "easy of use". You create a widget folder with script, style and markup, include it in your template and it is there. Although I strongly believe that a state machine as well as a web component like layout would be highly beneficial, it might be a challenge to reduce the need to write much boilerplate for the user of smashing. I guess, a proof of concept is needed to find out, how it would handle. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[rherwig]

@tylermauthe I like the idea to only change the frontend. Let's see what we can come up with until the end of march.

[rherwig]

I prepared a little PoC on how to implement routing via dynamic imports, so that you can just create a new dashboard file and access it directly without having to implement routing yourself.

I'm happy about ideas and comments

https://github.com/rherwig/sinatra-vue-poc

[torarnv]

Very nice @rherwig! Would love to se Smashing transition to more modern technologies (Vue, ES6, HTML grid, etc).

[rherwig]

@torarnv So do I! I would be happy to assist with this. And I'd also like to here the voice of a contrib/owner, since this issue is quite old

[torarnv]

There's https://vudash.com/, based on node instead of Ruby. I haven't found a way to add widgets in an easy way without too much boilerplate though, and a lot of the dashboard stuff seems to be configured in json files, even the css, which I would expect to be in app.css or something.

[torarnv]

This is the kind of simplicity I'd expect:

https://github.com/rherwig/sinatra-vue-poc/blob/master/assets/widgets/Text.vue

[torarnv]

Is Ruby a hard dependency for this project? Would having jobs be written in JS with node be an alternative? Could they co-exist, to be able to still support jobs already written in Ruby?

[torarnv]

Vuedash developer docs: https://vudash.com/#/developers/

It seems it's actually quite easy to add new widgets without too much boilerplate.

[dmikester1]

2020, is this idea dead? I don't know coffeescript, but am quite experienced in modern Javascript. Would love to see this happen.

[kinow]

Definitely not dead. I think we just lost momentum. If you have any proposal on how to get it started based on the existing discussion, feel free to create issues or PR's 👍

[kinow]

For 1.3.0, we already have updated Gems. Next I think we can work on reviewing the CSS gridster replacement by CSS grids, and then prepare a branch with Vue.js.