3 ms·

The author proposes this API: function Component({ showMessage }) { h('div', () => { h('h1', { text: 'Hey there', visible: showMess

The author proposes this API: function Component({ showMessage }) { h('div', () => { h('h1', { text: 'Hey there', visible: showMessage }) }) } I don't think it is better than the current React API `r = React.createElement` const Component = ({ showMessage }) => r('div', null, showMessage && r('h1', null, 'Hey there'))

bl4ckm0r3 3y ago
imo the readability of the proposed solution is not the best, especially for more complex things... it isn't clear to me if he is proposing that to be "under the hood" (like react's createElement), but if not i don't think it's a better solution (even though i understand the problem of using "custom syntax" but it's pretty normal when you are building "on top" of APIs.
- mickael-kerjean 3y ago
  I am getting through the same phase of rewriting my OSS [1] in vanilla JS [2], the solution I settled down on is to write components in pure es6 like this: export default function(render) { const $page = createElement(` <div class="component_helloworld"> whatever here </div> `); render($page); $page.addEventListener("xxxx"); onDestroy(/* remove listeners */); } Yes I sort of had to write my own mini framework but it's well under 100 lines of codes [0] with the idea that maintaining that 100 lines of codes is gonna be a massive win compared to keeping up with any "modern framework" npm hell The core idea is that instead of trying to pretend some cool ideas like HOC or render props, we call a dog a dog and say "decorator pattern" and just use the pattern directly [3] and when we need to compose things we do so as well [4] ref: - [0] the skeleton I started to settle on a nice API before starting the full rewrite https://mickael-kerjean.github.io/skeleton/example/index.html https://mickael-kerjean.github.io/skeleton/example/index.htm... - [1] original oss project which I'm migrating: https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/filestash - [2] current state of the rewrite where you can see this pattern in action https://github.com/mickael-kerjean/filestash-rewrite/tree/master/pages https://github.com/mickael-kerjean/filestash-rewrite/tree/ma... - [3] https://github.com/mickael-kerjean/filestash-rewrite/blob/master/pages/adminpage/ctrl_about.js https://github.com/mickael-kerjean/filestash-rewrite/blob/ma... - [4] https://github.com/mickael-kerjean/filestash-rewrite/blob/master/pages/adminpage/ctrl_log.js https://github.com/mickael-kerjean/filestash-rewrite/blob/ma...
  - bl4ckm0r3 3y ago
    what is this giving you more than using svelte or something like lit-html? https://mickael-kerjean.github.io/example/counter https://mickael-kerjean.github.io/example/counter looking at this example (i personally don't like the template string for dom because it's a bit of a pain to read and you need a lot of manual work later, separated from the definition of the markup, to add eventhandlers etc) you rely a lot on rxjs to handle state and IMO it's a bit hard to follow what is going on, compared to https://svelte.dev/repl/f5acc8113ec14bc7946eff9687916fa1 https://svelte.dev/repl/f5acc8113ec14bc7946eff9687916fa1 for example
    - mickael-kerjean 3y ago
      > what is this giving you more than using svelte or something like lit-html? 1. that's a trade off. From my point of view most framework provide short term win at the cost of the long run, this short term win is what we call "nice dev experience" and the long term cost is on the maintenance side when your dependencies will be rotten or someone will realise a dependency of your dependency of your dependency was disguised as a trojan. I don't get paid to upgrade my OSS project, if I can make that part much simpler, that's a BIG win for me even if the code doesn't look as nice as in svelte 2. The end goal is to enable people to change the end product by pushing patch of the frontend without having to recompile anything. I have many people contacting me to make changes to the UI and I can't make it because it doesn't make sense for 99% of the users, with this approach I can make a plugin for 1 dude without affecting anyone else and by just shoving a diff of what I need to change to enable that use case 3. I can actually read the code of 100% of my dependencies and yes I've had situation where I was asked this question > you rely a lot on rxjs to handle state and IMO yeah I'm a rxjs fanboy, can't help it but this is just a example you could use whatever rock your boat, my boat is definitly on the rxjs camp
d3w4s9 3y ago
Looks like Vue's render function: https://vuejs.org/api/render-function.html https://vuejs.org/api/render-function.html And let's be real, nobody likes writing code this way.
- beebeepka 3y ago
  Sometimes you kind of need render functions but it definitely isn't the most handy way of building a template. Many, many people struggle with this, including FE guys. In my experience, html is a pretty good abstraction of html. Many have tried making it easy to do this programmatically but, at least imho, no js syntax beats good old html. No a huge fan of react but jsx templates are better than r(node, props). Even jquery allows you to do this.
tannhaeuser 3y ago
Does anyone else wonder why the author doesn't go all the way but stops at HTML and DOM? How does "div", "h1" help here to "convey meaning" or attach "behavior", or serve any other purpose usually associated with HTML that may make sense for responsive/accessible documents but not apps? AFAICS the DOM is a crappy scene graph for apps, made barely tolerable through lots and lots of CSS ad absurdum, thereby complicating if not outright sabotaging text reading for generations to come. SVG would be a much more rational choice (with parts where typography and text flow/flow layout actually play a role still in an essential HTML subset). Or even pure JS-based immediate mode rendering, possibly with offloading of new layout model computations into JS libs portable across JS-enabled browsers, like the Houdini API is proposing? The proposed syntax merely seems like it's opportunistically driven by what's present in the JS language but isn't really pushing the limit despite the tone.

bl4ckm0r3 3y ago

imo the readability of the proposed solution is not the best, especially for more complex things... it isn't clear to me if he is proposing that to be "under the hood" (like react's createElement), but if not i don't think it's a better solution (even though i understand the problem of using "custom syntax" but it's pretty normal when you are building "on top" of APIs.

mickael-kerjean 3y ago
I am getting through the same phase of rewriting my OSS [1] in vanilla JS [2], the solution I settled down on is to write components in pure es6 like this: export default function(render) { const $page = createElement(` <div class="component_helloworld"> whatever here </div> `); render($page); $page.addEventListener("xxxx"); onDestroy(/* remove listeners */); } Yes I sort of had to write my own mini framework but it's well under 100 lines of codes [0] with the idea that maintaining that 100 lines of codes is gonna be a massive win compared to keeping up with any "modern framework" npm hell The core idea is that instead of trying to pretend some cool ideas like HOC or render props, we call a dog a dog and say "decorator pattern" and just use the pattern directly [3] and when we need to compose things we do so as well [4] ref: - [0] the skeleton I started to settle on a nice API before starting the full rewrite https://mickael-kerjean.github.io/skeleton/example/index.html https://mickael-kerjean.github.io/skeleton/example/index.htm... - [1] original oss project which I'm migrating: https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/filestash - [2] current state of the rewrite where you can see this pattern in action https://github.com/mickael-kerjean/filestash-rewrite/tree/master/pages https://github.com/mickael-kerjean/filestash-rewrite/tree/ma... - [3] https://github.com/mickael-kerjean/filestash-rewrite/blob/master/pages/adminpage/ctrl_about.js https://github.com/mickael-kerjean/filestash-rewrite/blob/ma... - [4] https://github.com/mickael-kerjean/filestash-rewrite/blob/master/pages/adminpage/ctrl_log.js https://github.com/mickael-kerjean/filestash-rewrite/blob/ma...
- bl4ckm0r3 3y ago
  what is this giving you more than using svelte or something like lit-html? https://mickael-kerjean.github.io/example/counter https://mickael-kerjean.github.io/example/counter looking at this example (i personally don't like the template string for dom because it's a bit of a pain to read and you need a lot of manual work later, separated from the definition of the markup, to add eventhandlers etc) you rely a lot on rxjs to handle state and IMO it's a bit hard to follow what is going on, compared to https://svelte.dev/repl/f5acc8113ec14bc7946eff9687916fa1 https://svelte.dev/repl/f5acc8113ec14bc7946eff9687916fa1 for example
  - mickael-kerjean 3y ago
    > what is this giving you more than using svelte or something like lit-html? 1. that's a trade off. From my point of view most framework provide short term win at the cost of the long run, this short term win is what we call "nice dev experience" and the long term cost is on the maintenance side when your dependencies will be rotten or someone will realise a dependency of your dependency of your dependency was disguised as a trojan. I don't get paid to upgrade my OSS project, if I can make that part much simpler, that's a BIG win for me even if the code doesn't look as nice as in svelte 2. The end goal is to enable people to change the end product by pushing patch of the frontend without having to recompile anything. I have many people contacting me to make changes to the UI and I can't make it because it doesn't make sense for 99% of the users, with this approach I can make a plugin for 1 dude without affecting anyone else and by just shoving a diff of what I need to change to enable that use case 3. I can actually read the code of 100% of my dependencies and yes I've had situation where I was asked this question > you rely a lot on rxjs to handle state and IMO yeah I'm a rxjs fanboy, can't help it but this is just a example you could use whatever rock your boat, my boat is definitly on the rxjs camp

d3w4s9 3y ago

Looks like Vue's render function: https://vuejs.org/api/render-function.html https://vuejs.org/api/render-function.html And let's be real, nobody likes writing code this way.

beebeepka 3y ago
Sometimes you kind of need render functions but it definitely isn't the most handy way of building a template. Many, many people struggle with this, including FE guys. In my experience, html is a pretty good abstraction of html. Many have tried making it easy to do this programmatically but, at least imho, no js syntax beats good old html. No a huge fan of react but jsx templates are better than r(node, props). Even jquery allows you to do this.

tannhaeuser 3y ago

Does anyone else wonder why the author doesn't go all the way but stops at HTML and DOM? How does "div", "h1" help here to "convey meaning" or attach "behavior", or serve any other purpose usually associated with HTML that may make sense for responsive/accessible documents but not apps? AFAICS the DOM is a crappy scene graph for apps, made barely tolerable through lots and lots of CSS ad absurdum, thereby complicating if not outright sabotaging text reading for generations to come. SVG would be a much more rational choice (with parts where typography and text flow/flow layout actually play a role still in an essential HTML subset). Or even pure JS-based immediate mode rendering, possibly with offloading of new layout model computations into JS libs portable across JS-enabled browsers, like the Houdini API is proposing? The proposed syntax merely seems like it's opportunistically driven by what's present in the JS language but isn't really pushing the limit despite the tone.