Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unopinionaited generic xjst runtime #287

Closed
Guria opened this issue May 31, 2016 · 10 comments
Closed

unopinionaited generic xjst runtime #287

Guria opened this issue May 31, 2016 · 10 comments

Comments

@Guria
Copy link
Contributor

Guria commented May 31, 2016

I wonder if it's possible to extract basic runtime without bem-specific modes.
xjst initially was for general purpose data transfomations. Would be great to have modern runtime implementation for other then bem-related usages.

@vithar
Copy link
Member

vithar commented May 31, 2016

Can you define potential users of such runtime?

@Guria
Copy link
Contributor Author

Guria commented May 31, 2016

From veged/xjst

For example, XJST can be used as:

  • HTTP request router
  • template engine
  • AST transformator
  • parser

Also

Also I am bit crazy on splitting of responsibilities. I think it helps codebase to be more readable and maintanable.

@awinogradov
Copy link
Member

👍

@qfox
Copy link
Member

qfox commented May 31, 2016

That's all good but what you expect from bem-xjst? What the API you propose?

@Guria
Copy link
Contributor Author

Guria commented May 31, 2016

xjst: apply*, match, def, once, wrap, mode, replace, oninit
bemxjst: block, elem, mod, elemMod, mix, content + above
bemtree: above
bemhtml: tag, cls, attrs, js + above

@qfox
Copy link
Member

qfox commented May 31, 2016

No, I mean we talking about JS now, what the API you await? Some example in JS would be awesome.

I know as a user of old known xjst that there are a bunch of disadvantages related to it's complexity. It's really hard to use on custom transformations in comparison to XXXtraverse + vanilla.js.
And even if xjst useful for creating languages, anyway there are not so much cases for that at my POV.

Atm you just propose to split xjst logic from bem-xjst (correct me if I'm wrong) but bem-xjst by self will become slower and it is not acceptable.

But I'm not against it (since there are much pros still) if you can do it without losing performance.

@miripiruni
Copy link
Contributor

bemtree: above

Nope. I have related question: #332 (comment)

@awinogradov
Copy link
Member

I need this, I want this, I like this! ;)

@awinogradov
Copy link
Member

Hi there! I have made PoC of this issue. Let's discuss here #371 ;)

@miripiruni
Copy link
Contributor

miripiruni commented Oct 20, 2016

After meeting we decided to split this issue to:

  1. Use with YM, commonJS, webpack, gulp, etc.
  2. Expose API which uses require()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants