-
Notifications
You must be signed in to change notification settings - Fork 48
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
Comments
Can you define potential users of such runtime? |
From
Also
Also I am bit crazy on splitting of responsibilities. I think it helps codebase to be more readable and maintanable. |
👍 |
That's all good but what you expect from |
xjst: |
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. 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. |
Nope. I have related question: #332 (comment) |
I need this, I want this, I like this! ;) |
Hi there! I have made PoC of this issue. Let's discuss here #371 ;) |
After meeting we decided to split this issue to:
|
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.
The text was updated successfully, but these errors were encountered: