Remove Live UI

[punund]

Meteor has apparently dropped Spark.
Is Live UI plugin still relevant?

[bminer]

Not really. I'm not too interested in Meteor anymore either...

I've been thinking about Riot.js integration instead.

[CodeLenny]

@bminer What would need to happen to move forward on a new Live UI integration?

[bminer]

@CodeLenny - Sorry for the very delayed response. Live UI is pretty dead at the moment. It would take a fair amount of work to get it going again. It might as well be completely re-designed. The way Spark was engineered years ago was a little clunky, and the UI regularly exhibited strange behavior.

To be completely honest, I usually just render Blade templates to HTML and then use those HTML documents with a UI library like Riot.js. I'm thinking about deprecating the whole Live UI project and killing it once and for all. There are other libs out there that do a pretty nice job solving the problem, and those libs are usually template-language independent.

Anyway, what do you guys think?

[CodeLenny]

@bminer I've been checking out alternative engines such as Riot.js. After a bit of research and testing, I actually prefer Polymer to Riot - they are quite similar, but Polymer allows sub-templates to require other templates.

I did like having the language features in Blade be interpreted into Live UI constructs. I'd wonder if Blade could support adding custom (run-time) language features that could be translated - like turning for-loops into HTML attributes, as Riot/Polymer use.

I still liked having the language features in Blade, and would like to see that survive somewhere - I can't find a single other project that bakes them into the language. I'd love to see a project of this type continue, even if it was simplified to a more basic sub-set of features to make it easier to stabilize - even as an academic effort, but hopefully could be used in industry.

[bminer]

@CodeLenny - I might have some time over the holiday to work on this. Blade v4 would be a re-design with some language features removed.

For sure the - code blocks would be removed in favor of language-specific conditionals and iterative code blocks. No more free-form JavaScript in templates. :( The reason for this change is that JavaScript logic probably doesn't belong in the DOM part of the template. It tends to make things slow and buggy.

The rest of the language could probably be designed to allow a 1-to-1 mapping to Riot.js.

• templates --> custom tags (template file name becomes the custom tag name using "data-is" attribute)
• string interpolation within text blocks / attributes --> curly braces
• event handlers --> script tag with event handler function
• functions declarations (mini-templates) --> custom tag (function name becomes the custom tag name)
• function calls --> use attributes and opts
• file includes --> use attributes and opts to include the mini-template
• blocks --> use multi-transclusion for block replacements. Block append/prepend probably wouldn't work. Parameterized blocks would probably be removed, too.
• if/else (new keywords) --> conditionals
• each (new keyword) --> loops

I dunno. What do you think? What Blade language features do you really like? What are the must-haves? What gives Blade an edge over a similar templating language like Jade?

[CodeLenny]

@bminer Excluding the Live UI features, I really like how flexible Blade is currently. In Blade 3, I can use JavaScript loops with - code blocks, or use Riot each tags. I'd really miss code blocks, especially as many of my sites are pre-rendered in CI, and I don't care how long that takes.

I would be interested in seeing (or helping create) a Blade that would be flexible. Instead of converting everything for Riot, keep the existing (non-Live UI) system. Have a flag to disable - code blocks and similar features for performance. For the fancy features like foreach, have it by default do a JavaScript foreach (instead of dealing with curly-bracket hackishness). Then let the user override that to use a Riot each, if that's what they wanted.
I'd love to define Riot events inline, and have the compiler move them into the script tag - but that's something I'd definitely want as a user-defined functionality so Blade isn't tied to a single system.

I very often use/appreciate:

• File includes
• Whitespace sensitive, tags, classes, a>/<a for inserting spaces
• Blocks
• Functions (but really want yield in native Blade)
• :coffeescript, :markdown, :stylus
• Inline code (- lines)
• Block commenting using indentation (We're working on implementing this in our whitespace sensitive hardware design language)
• !!! 5 doctype (but wish it was compatible with Jade/pug)

I sometimes use:

• Event handlers - only with Live UI

I never use:

• Blade keyword escaping
• :nl2br, :cdata
• Piping a function call into a variable - I wanted to use this to replace yield (make functions modular) but couldn't get it to work well

Things I would like:

• While on Blade 3, link to spark-standalone in the Live UI docs (currently there's some dead link)
• Option to use alternative languages in code blocks/interpolation - I hate writing plain JavaScript, especially when I want to write a very short snippet, as I'm in a single-line - or in string interpolation. Personally I'd choose CoffeeScript.
• yield inside functions, as mentioned above
• Make JavaScript templates standalone
• Probably a bunch of browser-side API changes, especially documenting using the browser runtime without the Express plugin (like, just use a RawGit link)
• Fix Markdown paragraph breaks with blank lines between them

[bminer]

Interesting. Thanks for the feedback! I'm curious... how do you use - code blocks? Do you do simple conditionals (if/then/else)? Iteration over an array/collection? More advanced iteration? JS functions?

I'm finding that most "reactive UI" libraries support conditionals and iterating through a collection (i.e. array). That's where it stops. Blade 3 allows you to write JavaScript anywhere, which is flexible and robust, but it leads to challenges when writing a reactive UI library (or integrating it with one). If I removed the - code block, I would certainly add if/else conditionals and iteration over a collection. But, I wonder... are there other common use cases for inline JS in templates?

[CodeLenny]

@bminer Just did a grep through my large code repository at work. Definitely use for, if, else.

I often use it to set a variable to pass to templates, but generally just the page title:

- var title = "Home"
include "./page.blade" exposing title
replace body
  //- ...

At some point, there was a bug in Blade if you tried to set an attribute to a complex expression - I forget if it complained about ( or +. Either way, I often compute attributes if they are long/messy, are used multiple times, or have one of the banned characters. Here's a mocked up example:

- var isChecked = (db.rows[i][option]) ? "checked" : "";
input(type="checkbox", checked=isChecked)

I've used it to set local configuration. I'm recreating a few lines in grep as I'm too lazy to open the full source, which is also currently closed source. (Doesn't seem to really make sense, but I'm sure there was some context making it sane)

- var str = "Open"
- var options = {left: "Open to the Left", right: "Open to the Right", top: "Open Above", bottom: "Open Below"}
- if(options[side])
  - str = options[side]
//- something that uses str, probably a button or something

I've managed to use it coupled with Live UI to make sure JS is run each time that section of the model is re-rendered. Yes, I'm embarrassed by it, but it worked.

input.some-library-class(...)
- $(".some-library-class").initJavaScript()

I've got some vague memory of me using it to get some text from fs.readFileSync. Don't worry, that code certainly didn't make it to production.

Not sure if any of this can't be done with proper constructs, instead of free-for-all code insert, but I've liked the freedom.

I might be able to dig up some other uses from other projects.

[bminer]

Hm, good to know. I've pretty much done the same sort of stuff... (if, else, for, var). Nothing too crazy. Sometimes my looping constructs are a bit more complicated than iterating through every single item. Maybe you might want to break the loop when you encounter a particular item, for example.

Here's the problem when it comes to "reactive UI", though. When you're looping through a collection, you need to track every item. You don't want to re-render an entire list if one item is spliced out of an Array, for example.

In Riot, there's a no-reorder option for loops: http://riotjs.com/guide/#performances
Before this option, there was a mess of a discussion here: riot/riot#990

So, needless to say, tracking arrays and updating the DOM accordingly can get computationally expensive if you're not careful. I'd like to leave reactive DOM out of the Blade project entirely if possible. To be honest, it's a difficult problem that I don't have a lot of time to solve. :) But, I would certainly support a Blade v4 that integrated more nicely with other reactive DOM libraries. I'm afraid that means removing some features (i.e. the - code block). IMHO, it might be worth losing some of those features to allow Blade to be used in reactive UI applications.

I should add something else here: I'm not a fan of Riot's syntax, but I use it because it's lightweight and works just fine.

[CodeLenny]

@bminer

All right, I'm not married to including reactive DOM inside Blade. Letting it integrate into different reactive libraries would probably be better for now. (Just give me a minute to get over the dream that the Live UI wiki page promised)

I'm still not sold on ditching - code blocks. I agree they should be disabled when using reactive libraries, but I wonder if they could be stuck behind a flag, so we could keep using them in all the other forms of templates. It's sorta nice to have quick-and-dirty methods around.

To make sure we're on the same page, I was suggesting that the output be flexible, so users can provide custom definitions for each, if, etc., and not just coding for Riot (or some other framework). Would you agree, or do you have other ideas?

[bminer]

I agree. Flexibility and backwards-compatibility are definitely important. I'll keep that in mind.

Due to my crazy work schedule, I probably won't have time to start on this until February. I'll try to keep this thread updated as I make progress. Have a Happy New Year!

[CodeLenny]

Sounds great. Again, I'd love to help if you need a hand. Let me know if you would like to collaborate on Blade v4.

Have a great New Year yourself!

[bminer]

Yeah, I'll take you up on that! I'll let you know once I come up with a plan to move forward. I think I have your email.

[CodeLenny]

Yep, you should have my email. I'm also willing to contribute to brainstorming/design if you want, or dive in to new areas and try some different ideas (flexibility of output might be a place to prototype concepts)