Plates v1.0.0

[Southern]

Plates has been pretty abused over the past year. It's time that it got some love! We've been rebuilding it from the ground up. Here are some of the things that this recode aims to fix, or has already fixed:

• Accept multiple HTML strings, maps, collections, and data in Plates.bind
• Have a parser that is accessible from Plates, but not dependent on being used in Plates.
• Make code more manageable.
• Better parsing of HTML for manipulating tags:
  • Use regular expressions for parsing rather than iterating through each character.
  • Fix mapping to where things such as .append actually append, rather than overwriting all of the HTML in the tag.

This code is currently incomplete, no tests are currently provided, and any of the methods in this code could change at any time. There will be completely new documentation, once the code is complete, that will outline all of the methods that are available in the actual release.

Pull requests are welcome if you would like to contribute to this code.

[mmalecki]

This needs tests before we can merge it in.

[3rd-Eden]

This also completely breaks browser support.

[heapwolf]

regular expression based parsing can be slow compared to bitstream parsing. I'd be curious to see your benchmarks (benchmarkjs?) Despite the performance, the api is was the exploration of an idea which i consider now quite aweful.

[Southern]

@3rd-Eden Please give examples of how it breaks browser support so that it can be fixed. It's worth noting that I haven't tested this in the browser yet. Sorry that wasn't in the pull request description.

@mmalecki Tests will be out soon, this PR isn't ready yet. Just a place to show the progress.

@hij1nx The API will actually be the same as the current API, with a few additions. That was one of the stipulations of it being recoded. I've been running time tests between the old code and the new code, and I haven't seen a major performance hit by using regular expressions in this manner. If you find a way that it takes longer, please let me know so I can look into ways that it could be improved. I really don't think iterating through each character, as it was previously, is exactly a fast method of doing things either.

[Swaagie]

Can't all current tests be ported? Most are use case tests and some target specific fixes, see test 42 for example.

Concerning browser support Object.defineProperties is not supported by IE8 for instance. The question would also be what browser support do we want to provide?

Also there is a massive pull request open, I'm not sure how legit it is. But contribution would be hurt if we just ignored that.

[3rd-Eden]

@Southern basically all ES5 stuff that your using should be banished. So stuff like:

• Array.isArray,
• Object.defineProperty(s)
• Object.keys.
• Configure checks
• Array.indexOf
• The y flag in regexp

@Swaagie The current version is working from IE6 to whatever IE and some older firefox versions like FF3. But basically following http://yuilibrary.com/yui/environments/ would probably yield enough support.

[Southern]

@Swaagie I haven't tested all of the current tests yet, as it's not complete enough (mapping isn't in here) to test yet. The current tests may be fine for all I know.

@3rd-Eden I know the "y" flag isn't supported in regex in all browsers. It doesn't force the "y" flag. It's just checking the source of the regular expression to see if the "y" flag is active. It's not actually adding it into the regex unless the user does. If all we're missing is a few functions in IE, why can't those functions just be added into the current code? It seems that only IE < 9 has problems with ES5, which doesn't surprise me at all.

@hij1nx I understand that Mustache has a huge following, including myself. However, Plates doesn't function the same as Mustache. So using Mustache as a comparison is pretty moot. Until I'm told otherwise, or someone can point me to some performance stats showing that it's taken a major performance hit, this recode will continue.

/cc @indexzero

[indexzero]

@Southern This is a good start; your parser looks pretty minimal. Contrary to other comments on this thread, regular expressions are fast in Javascript (especially V8). The need for a lexer-pass and a parser pass is obvious, and it's nice not to have to rely on .replace(/super long regex/, function (... anymore :-D

Look forward to what you come up with.

[davidchase]

@Southern @3rd-Eden curious on the status of this PR, let alone project... is it abandoned ?

[serapath]

same question. i forked plates.js several months ago and took some time to go through all the commits on this project to include them in my fork, just to realize, that they were only commit to polish stuff.
(e.g. spelling fixes, code formatting, readme updates, etc...)

Basically the project as is works for me, but i wonder if the code could be made smaller and maybe there is room for performance optimization.
If the contributors decided to move on - because they do not consider plates to be any longer "state of the art" for whatever reason, it would be nice to learn about that.

thx :-)

[3rd-Eden]

@davidchase In case of this pull request it cannot and will not be merged in until all points expressed above are addressed. In addition to that the usage of this module has been declining at Nodejitsu as we've found it quite hard and super annoying to maintain template's rendering process in two different locations. So I would say, we welcome new contributors that want to help out with maintaining and moving this project forward.

[davidchase]

@3rd-Eden is there another module you guys use at Nodejitsu instead of this one?

[jcrugzz]

@davidchase check out https://github.com/bigpipe/, https://github.com/nodejitsu/contour and https://github.com/nodejitsu/browsenpm.org for an idea of what we are working with these days.

[davidchase]

@jcrugzz those are all excellent modules but I was hoping for something similar to plates... I really was drawn to the dsl free lack of {{}} templates.. we use handlebars currently and before used jade, etc but plates had me interested but it doesn't seem like a project that is being actively maintained.. unless you would still recommend its use in production? It seems like a lot of people try develop these dsl free templates modules but they either don't catch on or something else happens and seems like people go back to whats known such as handlebars or something similar. I might have to be another one to make an attempt or contribute to something like this or hyperglue & hyperstream. 😐

[serapath]

I'm pretty attracted to "programmatic template systems" (that's what they are called in a blog post from strongloop)

For example:

• https://github.com/flatiron/plates
• https://github.com/medikoo/domjs
• https://github.com/substack/hyperglue

I always thought, with those templating language, it should be easy to do live content updates "data binding", because the tags tell me exactly where to update the data.

This could be combined with requestAnimationFrame and libraries like fastdom to optimize performance or on the server side just by using plates.

I'm not so familiar with the virtual DOM concept and what else might be necessary to optimize performance - but i imagine, that i could get a pretty nice templating solution with this approach.

I actually wonder why nobody tried to go down that route yet - or if somebody did - i'm always happy to learn about cool projects :-)
If somebody could point me towards potential flaws in the concept, that would be equally nice, so that i don't try something stupid.

[3rd-Eden]

@davidchase As we've moved completely away from this pattern, we're using nothing else like this. The modules that we use are the once's that @jcrugzz mentioned. Our BigPipe system allows each layout component to be written in different template language if people want to do so, we're currently using html, handlebars, jade and ejs using this system (template magic is powered by https://github.com/bigpipe/temper).

@serapath Sure, it's easy to update content using data binding but the problem starts when you need to work your layout and start moving elements which causes everything to break as your mapping is no longer up to date. This requires you to edit other files which contains these mappings which is becoming an increasing burden for more complex layouts.

"virtual dom" wouldn't really yield any major benefits on the server as there isn't any new DOM that needs to be repainted. You are just manipulating in memory objects with function calls.

[serapath]

Can you elaborate what you mean?
For example, on this codepen, you can click the first element and it alerts something. Afterwards you drag it around and it gets clicked, it alerts the same stuff, thus the event listener still works.

What is the problem about re-positioning?

[indexzero]

Closing this due to age. This project is formally deprecated. Will be adding a notice soon.