5 ms·
Am I the only one who think that this: class Example extends Component { render() { return ( <App> <Window title="Examp
by c-smile 8y ago
Am I the only one who think that this:
class Example extends Component {
render() {
return (
<App>
<Window title="Example" size={{w: 300, h: 300}} menuBar={false}>
<Button stretchy={false} onClick={() => console.log('Hello')}>
Button
</Button>
</Window>
</App>
);
}
}
render(<Example />);
is using too many artificial parsing layers ?
1) Like run JS, then there 2) parse JSX that will build virtual DOM, then 3) interpret that vDOM to 4) create physical window.
Why not just
let app = Application({params});
let window = app.window({url:"content.xml",
type: "frame" });
- uryga 8y agoLooks nice for a short example, but later you'd also need some stuff like: let button = new Button("Click me"); window.attach(button, {position: 'center'}); To me, imperative widget creation gets tedious and hard to read pretty fast. I'm not a fan of the many parsing layers involved in the JS example either, but I really appreciate the declarativity they enable.
- c-smile 8y agoI am not saying that you don't need markup at all. Window content can still use markup. But it is not clear why do you need it for defining Application and Window abstractions. In browsers DOM element is a subject of style applicability and events handling. But why do you need DOM nodes for application and window ?
- always_good 8y agoWhat does your trivial wrapper actually improve though? window = (...children) => <App><Window>{...children}</App></Window> Over the years I've learned that some boilerplate isn't bad. In fact it means App and Window are implemented in the same abstraction that I'm using.
- crooked-v 8y agoJSX is JS. While there's technically 'parsing' involved, it's fundamentally just syntactic sugar: import { createElement as e } from 'whatever' return e(App, {}, [ e(Window, { title: 'Example', size: { w: 300, h: 300 }, menuBar: false }, [ e(Button, { stretchy: false, onClick: () => console.log('Hello') }, [ 'Button' ]) ]) ])
- c-smile 8y ago"JSX is JS" It is not, https://facebook.github.io/jsx/ https://facebook.github.io/jsx/ It is handled by transpiler - one more parsing layer in loading sequence of your application.
- azerothian 8y agosounds like you have your project configured wrong, transpiling should impact compilation not the loading aspect of your application
- mlsarecmg 8y agoThe transpiler is a build build (a babel plugin), it isn't even a part of the application nor does it run while loading. The snippet above turns into a bunch of nested functions.
- tannhaeuser 8y agoNo it isn't, in the sense that it's not part of a language spec for JavaScript, like E4X (now deprecated) once was considered to become. But I guess E4X's problem was that it was too far ahead of its time and had XML in its name. [1]: https://developer.mozilla.org/en-US/docs/Archive/Web/E4X https://developer.mozilla.org/en-US/docs/Archive/Web/E4X
- mlsarecmg 8y agoJSX gets transpiled, not parsed. The effort is completely on the tooling side, there's no loading effort that changes JSX into functions. The main difference between your two snippets is that one is declarative and the other is imperative. The declarative piece can reflect state and react to changes, the other can't - you do that manually.