11 ms·
Coffeekup
- wallrat 15y agoLooks pragmatic and useful. I've been experimenting with a similar implementation inspired by Clojure's Hiccup, but Coffekup looks mature enough to consider adopting.
- yuvadam 15y agoIt's comforting to know that nowadays 300 watches and 20 forks on github are enough to consider software "mature". (Nothing personal, just a reflection...)
- nzoschke 15y agoCute name and well executed project. But personally, Coffeescript -> Javascript -> HTML sounds way too indirect for my taste. I've seen this patter a few too many times at work now: the new frontend guy loves HAML, and he uses it on a project, and the next couple guys that help maintain it hate it and rewrite everything in straight up HTML.
- Sapient 15y agoJust reading your comment, it occurred to me that this is an editor problem. What we actually need are editors in which you can set you language (haml, slim, less etc), and then those are compiled and saved, in realtime to html, erb, css etc. Not having used too much Coffee Script yet, I don't know what the transformation from CS -> JS -> CS would result in, but I believe HAML -> HTML -> HAML would be pretty much 1:1, and html2haml already produces pretty much exactly the same haml I would have produced if I had done the conversion manually.
- iloveponies 15y agoI can see such a conversion like that leading to a scenario where someone writes some broken markup and the conversion to and from formats only makes the situation worse.
- Cushman 15y agoOne of the goals of CoffeeScript is to produce only well-formed, compliant JS. JS to CS conversion would go against that.
- joeyespo 15y agoWhile I also think this is too indirect for my taste, I'd really like to know why the maintainers hate it. Is it simply because they've never learned HAML and how to debug/maintain it? Or because it truly is a nightmare? I'm interested because I was thinking about trying it. I've been wondering about the maintenance implications though.
- nzoschke 15y agoThe former. The first guy that loves Haml a lot has used it on tons of projects, and knows its quirks, has his own clever tricks, etc. Someone else comes along and has to set up a Ruby environment and learn a new syntax (for layout and templating) just to add a new element to the page. That gets frustrating really quickly. Haml and its like are not a nightmare at all. I do appreciate the elegance of the resulting code and this offers a lot of benefits. It's just hard to get everyone to buy into it on a team.
- danenania 15y agoI don't really get this. Conceptually, haml IS html. Sure the syntax is a bit different, but it's hard for me to imagine that a decent programmer would get hung up on this. Same with coffeescript really. If a cleaner syntax on top of a language scares you, you don't really grok the original language all that well in my opinion. There are certainly arguments for sticking with vanilla html/js, like the potential minor hassles of dealing with file conversions and debugging generated code, etc., but fear of a new syntax that can be learned in 15 minutes is a weak one. Edit: I do grant that js to coffeescript is a bit more of a leap than html to haml since coffeescript actually introduces some new language concepts.
- jarin 15y agoMost of the "I hate Haml" arguments can easily be solved by use of filters (e.g. :markdown, :textile, :javascript, :plain, :erb, etc) and/or proper use of helpers or cells (I prefer cells). The things I most often see people doing wrong are trying to format body text with Haml and putting excessive logic in your Haml templates (which is something to look out for anyway, even if you use erb, slim, or whatever).
- chrisjsmith 15y agoWhilst I appreciate the effort that people put into these things, I really don't like this sudden obsession of adding another layer of abstraction over everything. Abstrations are hard to debug, require a learning curve of 2x the original problem and are rarely complete.
- naz 15y agoAgreed, we should write everything in binary
- chrisjsmith 15y agorephrase - un-necessary abstration.
- ehsanu1 15y agoThen the issue becomes determining what abstractions are "necessary". The line is very blurry, and there is plenty of room for a range of reasonable positions on this matter. While there may be some objective truth about which abstractions really are a net benefit to use, there's no easy way for us to determine it (besides deciding between binary and assembly). So arguing about it is mostly pointless. Leave each to their own preference.
- chrisjsmith 15y agoIMHO, abstractions become apparent if needed. Abstractions should never be thought of first. Read GEB - covers it indirectly ( http://en.wikipedia.org/wiki/G%C3%B6del%2C_Escher%2C_Bach http://en.wikipedia.org/wiki/G%C3%B6del%2C_Escher%2C_Bach )
- ulisesroche 15y agoIt's not exactly sudden, you know. We're not using punch-cards anymore, for example. I've haven't done much debugging, since Haml/Sass/Coffeescript write better HTML/CSS/Javascript than I do, but you can always look at the compiled code if you need to.
- johnlaudun 15y agoI like the thinking that go into efforts such as this, but like other commenters I do on occasion end up wondering about the fragmentation that this leads to. That worry noted, the thinking is the important point and CoffeeKup is very cool.
- mikemaccana 15y agoI love CoffeeScript but I don't understand this. HTML / HAML / SHPAML are document languages. CoffeeScript is a programming language. An element that contains another element isn't a function. I don't see any reason to make it one. If you want a templating language, why not use one, rather than having an unnecessary 'space dash greater than' to indicate elements are contained within each other?
- gosub 15y agoa markup language like html is not made of elements that containts other elements, that is just an artifact of the syntax. A tag is more like a "semantic modifier" of its argument/the thing that it contains. How is <i>Lorem ipsum</i> different from (italicize "Lorem ipsum") or italicize :: string -> adorned-graphic-text ? edit: also, I think having one entire application expressed with only language (coffeescript vs html+css+javascript) is an advantage.
- maxwell 15y agoThese are arbitrary distinctions; as Heidegger said, language is language. As long as they're Turing complete, the only difference between "programming" and "templating" (and "natural") languages are what they're used/optimized for. Element A containing Element B can be generated by function A taking Element B. The CoffeScript program converts a set syntax/grammar into JavaScript; but the syntax is just syntax, and its clean, smart design lends itself well for compiling code other than JavaScript, just as JSON is a useful serialization format in other langs. There are benefits in using the same syntax for representing structure, content, and presentation, as long as the concerns are still properly separated.
- akdetrick 15y agoThe "language is language" argument has shifted my thinking a bit from my initial reaction to this project. In that line of thinking, it's also raised a new question in my mind. CoffeeKup seems to be optimized for baking logic into the template. It is not too different, but too much like most "templating" languages for me to completely get behind it. This is however, a really cool project that's well executed. I'm just hoping that the idea of further separating logic from templates takes hold (something like mustache, perhaps).
- coenhyde 15y agoLooks fantastic. With the traction Coffeescript is getting I wouldn't be surprised to see it eventually execute directly inside v8 or similar, bypassing the javascript compilation altogether.
- iambot 15y agoi cannot wait
- dualogy 15y agoEven if V8 could do this, I'd probably continue to compile my stuff manually (it's so easy) so I wouldn't have to wait for Node / Chrome to update to the newest V8 when there is a new version of the CS compiler that I might need "now". Also it'd be the only way for me to be sure my CS is compiled by the proper compiler version.
- coenhyde 15y agoI was more thinking coffee script development for nodejs. The browsers on a whole have only just got javascript sorted. I think it's too much to ask for native coffee script support in the browser.
- rpearl 15y agoIf you translate your coffeescript to javascript serverside, then there is no overhead on Jaegermonkey or v8 (obviously). Although I doubt that any of the browsers will ever support it directly, porting coffeescript to run directly on top of Jaegermonkey or v8 wouldn't be too hard, since there is a direct translation from coffeescript to javascript. You would only need a new front end--if you emit Spidermonkey/Hydrogen bytecode, the relevant engine can JIT it. On a slightly related note, a friend of mine is working on this: https://wiki.mozilla.org/DevTools/Features/SourceMap https://wiki.mozilla.org/DevTools/Features/SourceMap Which, while not compiling directly, will allow you to map the generated JS directly back to the coffeescript source.
- mraleph 15y ago
- lysol 15y agoI sort of like the idea, but think I'd rather just have a CoffeeScript version of EJS. It's hell on my shift key but I still _like_ HTML as it is, after all these years.
- jashkenas 15y agoVoilà: https://github.com/sstephenson/eco https://github.com/sstephenson/eco
- jjm 15y agoI like HTML too, but when I took a look at ECO i thought wow, that's a lot of `%` signs... Then I started thinking about all that big corp JSP I wrote a lifetime ago. Taking a second look at CoffeeKup made me appreciate what the project is doing, clearly abstracting away useless syntax with the same good'ole functions.
- shimonamit 15y agoI just noticed the example is editable! Thumbs up for a great demonstration.
- alecbenzer 15y agoWhile I agree that it does seem slightly more appropriate to use something like haml that's specifically designed for this purpose, I kind of like this because it removes the somewhat annoying need to learn a new language (assuming you already know coffescript). I haven't looked at this too much, but I also find that templating languages often try to implement some elements of higher level programming languages, but often end up not having some of the features I want (I'm thinking specifically about liquid right now and it's apparent inability to let the designer declare arrays on their own, and its sort of awkward "filter" mechanism instead of just sticking to function calls, syntactically) edit: well, actually, nevermind - now that I think about it liquid and haml/erb/etc are different things - liquid is trying to be a programming language and haml/erb are templating markups used with existing programming languages. I guess what I like about this is that it's just one consistent language - the markup parts and the dynamic parts are done via the same thing, as opposed to having a programming language embedded in a markup language
- etaty 15y agoI prefer http://jade-lang.com/ http://jade-lang.com/ why ? because no '->' at the end of each line
- danenania 15y agoAgreed. I've really come to love minimalism in languages. It's somewhat like economy of words in poetry. There should be sufficient syntax to get the desired meaning across, and nothing more. Even though I haven't used jade yet, it's the cleanest looking markup language I've seen. I would also a appreciate a cleaner alternate syntax for json to complete the picture.
- emehrkay 15y agoThis may be a bit "get off of my lawn," but I would never use this. I respect the effort put into making it work, but I have no problem writing <div></div>
- dualogy 15y agoI too have no problem writing a single <div></div>. But trust me it gets old. In a new from-scratch project (which is completely stand-alone and won't need to "integrate" with anything or be touched by other coders who "can do html but not coffeescript") after having done the first 10-15 templates I was looking at my CoffeeScripts... then back at my <html/><templates/> ... then rewrote them all to the tune of: renderTemplate: -> "div": "span .some-class": _: ["Hello, "] "strong #dyn_id": _: ["#{@getName()}!"] "subTemplate": foo: bar subTemplate: (args) -> blockquote: _: args.foo getName: -> "user name from DB or whatever" (Then hand-rolled my own very simple JSON-to-HTML "renderer" in 20 minutes plus generating a CS class file to be compiled to JS for each template -- all really simple stuff.) Looks scary coming from years of HTML coding right? But HTML looked scary at first too. Now: stylesheets are Stylus, templates and logic are CoffeeScript both server-side and client-side. I haven't been such a happy coder for a decade. Config files are a simplified Stylus/Coffee-like format that gets transformed to JSON. I'm actually using the CoffeeScript compiler here so in effect each config file gets transformed into a node.js "module". That means they could be turned into config "scripts" if necessary. What I loved about Lisp in theory: code is data, data is code. Only the parens sucked for me. Now we're approaching this ideal again, slowly and emergently but surely. :)
- tptacek 15y agoJust looking at the syntax and thinking about how I would write things in it, this looks strictly inferior to Haml; there's syntax in here that appears to exist solely to shoehorn this into Coffeescript's grammar. What does this do better than Haml to make up for that?
- nolanw 15y agoIt uses CoffeeScript's grammar, so there's no need to learn a new one or switch between two different grammars as you work. It's also way less code than Haml. CoffeeKup's src folder is 240 lines of code.
- jarin 15y agoI think the main advantage is it doesn't require Haml. I use Haml whenever possible, but I could see this being very useful for Node.js or other JS/CS-based apps.
- catch23 15y agowhy couldn't one write a haml parser for node.js? That would seem like a better strategy than invent a whole new syntax for markup.
- bergie 15y agoThere is a HAML parser. http://howtonode.org/haml-for-javascript http://howtonode.org/haml-for-javascript But it is a good thing to experiment with different approaches.
- Cushman 15y agoNot sure what you mean here-- it's raw CoffeeScript syntax. The templates it produces are JavaScript functions.
- deleted 15y ago[deleted]
- jedschmidt 15y agoThis exploits CoffeeScript syntax in the same way that (fab) exploits JavaScript syntax: https://github.com/jed/fab/blob/browser/demo.html https://github.com/jed/fab/blob/browser/demo.html (I'm biased, but am a fan of making markup "just code".)
- anonymous 15y agoWhat a great idea! Now i can write html that nobody understands but me. This will keep those pesky designers from messing with my codes.
- chetan51 15y agoLooks interesting. A suggestion: there's no example anywhere for something like <div class="content"> Please add that to the example on the landing page.
- zentechen 15y agoThis is so stupid.
- denysonique 15y agoThis is wonderful. I am looking forward to someone creating a Coffeekup Gem. I will use this in my next Rails project. Thank you for this awesomeness.
- aslamnd 15y agoI agree. It's a good effort. No doubt. But I personally feel that it makes a simple markup language like rocket science. I prefer HAML over this once as in HAML I only need to type single (%) character to mark tags where is in this language I need to use two characters (->).
- mtogo 15y agoI have no idea what this is. Shows up as two large empty text boxes under Opera. After opening it in Firefox, i find it ironic that something that has to do with web standards is so broken in a major browser.