6 ms·

So, if you are building this off 'window', you are basically just adding syntax sugar to one big global variable. That is absolutely a simple solution to storin

So, if you are building this off 'window', you are basically just adding syntax sugar to one big global variable. That is absolutely a simple solution to storing state. In one place. But that is not comparable to the functionality of React, so I'm not sure I agree that it is a "react-like framework".

atum47 2y ago
I'm guilty of using React as framework to try to copy from. After working with it for the past 5 years I end up wanting something like it but with less bloat to use in my personal projects. So, what I tried to do: have functional components with JSX like syntax and a managed state that is in sync with the UI. Giving those 3 features and the syntax, I used the term React like.
- EGreg 2y ago
  I never understood the fascination with JSX. Stuffing HTML into JS? You can stuff JS into HTML natively LOL. Why not use HTML templates and Web Components, or something? I would have thought React would become like jQuery, after Web Components were implemented natively in browsers, just like jQuery's functionality was. But it's still very popular.
  - MarcelOlsz 2y ago
    >Why not use HTML templates and Web Components, or something? I would have thought React would become like jQuery, after Web Components were implemented natively in browsers, just like jQuery's functionality was. But it's still very popular. Us frontend devs are so lost in the framework sauce that there is a 5 year lag between what web api's can do and when it hits our slack channels.
    - paulddraper 2y ago
      Have you ever used web components? They are absolutely not equivalent to what react does, though there is overlap.
      - MarcelOlsz 2y ago
        I've played with them yeah.
      - EGreg 2y ago
        Vue, Svelte etc don’t use JSX and are perfectly fine
        paulddraper 2y ago
        Sure, they have their own HTML-based file formats. .vue .svelte FYI, React works with or without JSX, if that's really the hang up. But the developers overwhelmingly prefer JSX.
  - globalise83 2y ago
    Web components are still a little tricky to work with. For example, passing down a complex state to child components is easy in React, but in native web components not so straightforward. Stencil.js is a nice choice for that, but it is just as complicated as React to learn.
  - jeswin 2y ago
    > I never understood the fascination with JSX. HTML templating (without JSX) gives you markup as strings, which means you don't get type checks, auto-complete, syntax highlighting etc.
    - mock-possum 2y ago
      Have you checked out lithtml?
      - jeswin 2y ago
        Yeah. It requires a framework specific plugin in vscode (and other IDEs), since the markup is just text which requires framework-specific interpretation. Ultimately, like everything else it's trade-offs and personal preference.
      - esperent 2y ago
        Do you mean lit html? I've seen it before, it uses template strings for html templating: const myTemplate = (name) => html`<div>Hello ${name}</div>`; Compared to JSX, I don't like it much. I feel that template strings are unergonomic and fiddly to type a lot, although maybe I'd get used to it.
        nchmy 2y ago
        It's literally just plain html and JavaScript...
    - gryzzly 2y ago
      it’s really a funny point, as if JSX is somehow native? JSX requires a compiler and definitely also editor extensions for syntax and auto-complete and type checks.
      - WorldMaker 2y ago
        Sure, but the most common JSX compiler and language service is Typescript and Typescript is well supported everywhere. As the de facto language service for most JS work today, it certainly feels more like "native" than other template compilers. Also, for what it is worth, JSX is mostly (despite a few attempts from React to complicate it) a very simple syntax transformer to boring function calls for mostly easy to write functions. We've had "h" functions for a long time before JSX and we'll have "h" functions still if JSX stops being an interesting thing to support.
  - ajkjk 2y ago
    they're just so much easier to think in
  - thomasfromcdnjs 2y ago
    expressiveness
  - mightyham 2y ago
    I don't think it's that hard to understand the appeal of JSX. If you want your interface to be modeled functionally (state as input, view as output), it makes way more sense for your view to be the result of a function in contrast with having app logic "stuffed" into a mutable view template. I'm also not sure why you are offering Web Components as an alternative because it's exactly what you are criticizing, stuffing HTML into JS. It's basically just a more limited and less ergonomic version of React class components, that comes with it's own host of unique headaches.
  - WorldMaker 2y ago
    > Why not use HTML templates and Web Components, or something? At least in my experience, the best way to write both HTML Templates and Web Components is with JSX. The type checking and language services of JSX are still something of a best in class for serious type safety in complicated data binding and reactivity. HTML Templates have "slots", but those are the simplest of holes and on the one hand support any HTML you want to place inside those holes, but on the other hand aren't a very deep template language for interactivity. Web Components have some auto-magic with "slots" if you plan to use your HTML Templates to populate the Shadow DOM. But the Shadow DOM is super complicated, hard to style, and entirely optional. It's also still not a deep enough auto-magic to do deep interactivity easily. We also still don't have "HTML Modules" even in strong polyfill, so distributing HTML Templates for Web Components is still something of an open problem. Most highly interactive Web Components still have a template engine inside, even when they work alongside/with HTML Templates. JSX is still a great template language. React itself may still be the jQuery of JSX-based because we seem to be swinging from Virtual DOM approaches back to "Real" DOM approaches, but JSX can be used for more than just Virtual DOM. (I've been successfully using my own library Butterfloat that uses JSX but is not a Virtual DOM in nice to tree-shake, wonderfully type safe Web Components.)
- MarcelOlsz 2y ago
  Check out "preact" if you haven't already [0] [0] - https://preactjs.com/ https://preactjs.com/
- whizzter 2y ago
  While I see a fair bit of elegance in your experiment, IMHO I also think that for it to be React-like and start mentioning code size one should at least handle structural changes (ie adding/removing items like in a todo-app). I made a minimal Vue-inspired templating thingy a while back and a fair bit of the codesize (part due to impl and part due to architecture to make it solid) is spent to handle cases of structural changes (adding/removing items, updating event listeners,etc).
  - atum47 2y ago
    > (ie adding/removing items like in a todo-app). I have made such an app using TinyJS, would you like to see it? here: https://github.com/victorqribeiro/TodoApp https://github.com/victorqribeiro/TodoApp
    - whizzter 2y ago
      That'll work
deleted 2y ago
[deleted]
jy14898 2y ago
Maybe I'm missing something, but there isn't any global state attached to window? They attach a constructor for state to the window, but that isn't the state itself - it just returns a smart state object.
- atum47 2y ago
  const appState = {...state} With that line I end up creating a appState inside the createState function which uses the state dictionary just as a template. Would it be better if I attached the things I need to the state object that I receive? function createState(state) { state._update = () => ... .... return new Proxy(state, ...) } legit question.

atum47 2y ago

I'm guilty of using React as framework to try to copy from. After working with it for the past 5 years I end up wanting something like it but with less bloat to use in my personal projects. So, what I tried to do: have functional components with JSX like syntax and a managed state that is in sync with the UI. Giving those 3 features and the syntax, I used the term React like.

EGreg 2y ago
I never understood the fascination with JSX. Stuffing HTML into JS? You can stuff JS into HTML natively LOL. Why not use HTML templates and Web Components, or something? I would have thought React would become like jQuery, after Web Components were implemented natively in browsers, just like jQuery's functionality was. But it's still very popular.
- MarcelOlsz 2y ago
  >Why not use HTML templates and Web Components, or something? I would have thought React would become like jQuery, after Web Components were implemented natively in browsers, just like jQuery's functionality was. But it's still very popular. Us frontend devs are so lost in the framework sauce that there is a 5 year lag between what web api's can do and when it hits our slack channels.
  - paulddraper 2y ago
    Have you ever used web components? They are absolutely not equivalent to what react does, though there is overlap.
    - MarcelOlsz 2y ago
      I've played with them yeah.
    - EGreg 2y ago
      Vue, Svelte etc don’t use JSX and are perfectly fine
      - paulddraper 2y ago
        Sure, they have their own HTML-based file formats. .vue .svelte FYI, React works with or without JSX, if that's really the hang up. But the developers overwhelmingly prefer JSX.
- globalise83 2y ago
  Web components are still a little tricky to work with. For example, passing down a complex state to child components is easy in React, but in native web components not so straightforward. Stencil.js is a nice choice for that, but it is just as complicated as React to learn.
- jeswin 2y ago
  > I never understood the fascination with JSX. HTML templating (without JSX) gives you markup as strings, which means you don't get type checks, auto-complete, syntax highlighting etc.
  - mock-possum 2y ago
    Have you checked out lithtml?
    - jeswin 2y ago
      Yeah. It requires a framework specific plugin in vscode (and other IDEs), since the markup is just text which requires framework-specific interpretation. Ultimately, like everything else it's trade-offs and personal preference.
    - esperent 2y ago
      Do you mean lit html? I've seen it before, it uses template strings for html templating: const myTemplate = (name) => html`<div>Hello ${name}</div>`; Compared to JSX, I don't like it much. I feel that template strings are unergonomic and fiddly to type a lot, although maybe I'd get used to it.
      - nchmy 2y ago
        It's literally just plain html and JavaScript...
  - gryzzly 2y ago
    it’s really a funny point, as if JSX is somehow native? JSX requires a compiler and definitely also editor extensions for syntax and auto-complete and type checks.
    - WorldMaker 2y ago
      Sure, but the most common JSX compiler and language service is Typescript and Typescript is well supported everywhere. As the de facto language service for most JS work today, it certainly feels more like "native" than other template compilers. Also, for what it is worth, JSX is mostly (despite a few attempts from React to complicate it) a very simple syntax transformer to boring function calls for mostly easy to write functions. We've had "h" functions for a long time before JSX and we'll have "h" functions still if JSX stops being an interesting thing to support.
- ajkjk 2y ago
  they're just so much easier to think in
- thomasfromcdnjs 2y ago
  expressiveness
- mightyham 2y ago
  I don't think it's that hard to understand the appeal of JSX. If you want your interface to be modeled functionally (state as input, view as output), it makes way more sense for your view to be the result of a function in contrast with having app logic "stuffed" into a mutable view template. I'm also not sure why you are offering Web Components as an alternative because it's exactly what you are criticizing, stuffing HTML into JS. It's basically just a more limited and less ergonomic version of React class components, that comes with it's own host of unique headaches.
- WorldMaker 2y ago
  > Why not use HTML templates and Web Components, or something? At least in my experience, the best way to write both HTML Templates and Web Components is with JSX. The type checking and language services of JSX are still something of a best in class for serious type safety in complicated data binding and reactivity. HTML Templates have "slots", but those are the simplest of holes and on the one hand support any HTML you want to place inside those holes, but on the other hand aren't a very deep template language for interactivity. Web Components have some auto-magic with "slots" if you plan to use your HTML Templates to populate the Shadow DOM. But the Shadow DOM is super complicated, hard to style, and entirely optional. It's also still not a deep enough auto-magic to do deep interactivity easily. We also still don't have "HTML Modules" even in strong polyfill, so distributing HTML Templates for Web Components is still something of an open problem. Most highly interactive Web Components still have a template engine inside, even when they work alongside/with HTML Templates. JSX is still a great template language. React itself may still be the jQuery of JSX-based because we seem to be swinging from Virtual DOM approaches back to "Real" DOM approaches, but JSX can be used for more than just Virtual DOM. (I've been successfully using my own library Butterfloat that uses JSX but is not a Virtual DOM in nice to tree-shake, wonderfully type safe Web Components.)
MarcelOlsz 2y ago
Check out "preact" if you haven't already [0] [0] - https://preactjs.com/ https://preactjs.com/
whizzter 2y ago
While I see a fair bit of elegance in your experiment, IMHO I also think that for it to be React-like and start mentioning code size one should at least handle structural changes (ie adding/removing items like in a todo-app). I made a minimal Vue-inspired templating thingy a while back and a fair bit of the codesize (part due to impl and part due to architecture to make it solid) is spent to handle cases of structural changes (adding/removing items, updating event listeners,etc).
- atum47 2y ago
  > (ie adding/removing items like in a todo-app). I have made such an app using TinyJS, would you like to see it? here: https://github.com/victorqribeiro/TodoApp https://github.com/victorqribeiro/TodoApp
  - whizzter 2y ago
    That'll work

deleted 2y ago

[deleted]

jy14898 2y ago

Maybe I'm missing something, but there isn't any global state attached to window? They attach a constructor for state to the window, but that isn't the state itself - it just returns a smart state object.

atum47 2y ago
const appState = {...state} With that line I end up creating a appState inside the createState function which uses the state dictionary just as a template. Would it be better if I attached the things I need to the state object that I receive? function createState(state) { state._update = () => ... .... return new Proxy(state, ...) } legit question.