This one is 25 bytes gzipped http://vanilla-js.com/
Does it work in ie9?
Show HN: HyperApp – 1k JavaScript framework for building web applications
71–80 of 169 posts
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#72Side question: Isn't it grossly inefficient that in Redux, you have reducers that return an entirely new state object? Wouldn't it be better to return some kind of data that represents just the diff you intend to make, like {op: INCREMENT, arg: 1, key: "Foo"}?
It depends. If you are making a shallow copy every time via `Object.assign` or the `{...obj}` syntax, then yes, it is rather inefficient. But a) for many (most?) apps it's Good Enough™, and b) you can always use a specialized library like Immutable.js to greatly reduce the overhead. I'm not sure about what would be the benefit of the scheme you are proposing. Are you proposing that the diff then gets applied directly…
Oh right, immutable data structures are good for exactly this situation. I've been in mutation land for a while now. :)
However, now I'm newly confused: Yes, I'm proposing that the diff then get applied directly to the state by the Redux infrastructure, and I don't understand why that would break any important assumptions provided by Redux. Is there an example you could give of how this might create a problem?
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#73Side question: Isn't it grossly inefficient that in Redux, you have reducers that return an entirely new state object? Wouldn't it be better to return some kind of data that represents just the diff you intend to make, like {op: INCREMENT, arg: 1, key: "Foo"}?
Objects in JavaScript are references so internally it's just a pointer being passed around.
Hmm, but reducers are supposed to return references to new state objects, right? So clearly something more substantial than a pointer has to be created/duplicated.
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#74Side question: Isn't it grossly inefficient that in Redux, you have reducers that return an entirely new state object? Wouldn't it be better to return some kind of data that represents just the diff you intend to make, like {op: INCREMENT, arg: 1, key: "Foo"}?
If just the diffs were returned, you'd need to constantly reapply them to recreate the latest state. By returning the entire state the previous reference can be discarded.
Well, I'm thinking that Redux would apply the diffs to the state destructively, so I'm not sure why we would need to "constantly" reapply them in order to recreate the latest state... we would simply have the latest state on-hand already. But if we're in a context where a lot of rewinding and fast-forwarding of state is happening for some reason, or where these state diffs can't easily be reversed/inverted, then I can see why this would be inefficient.
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#75I've seen "Show HN: HyperApp" type of submissions at least 5 times earlier. Congrats, you made a 1Kb JS library. Please stop spamming HN though. https://hn.algolia.com/?query=hyperapp&sort=byPopularity&pre...
I don't even get why it is important that it's 1kb. Give me a library with great API and easy to use. Nobody cares if library is 1kb or 100kb (minified).
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#76Wow, there's an overwhelming total of 2 comments in the source file. The first indicates a constant value. The second lacks all context. Looks like typical JavaScript code.
This comment violates both the site guidelines ("Please don't post shallow dismissals, especially of other people's work.") and the Show HN guidelines: see "In Comments" in https://news.ycombinator.com/showhn.html .
Understood. I'll refrain from such comments in the future.
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#77In the same vein there's Mithril. It's 8kb but includes a router and a fetch polyfill! I love these little JS frameworks :) https://mithril.js.org/
Mithril is nice. One downside is it doesn't lend itself really well to compound components. Everything has to be passed down through attributes.
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#78If you're interesting in a reactive template library that doesn't require a compiler for non-standard JavaScript syntax, check out a library I've been working on for a little while now, lit-html: https://github.com/Polymer/lit-html Where JSX would look like this: const view = (state, actions) => ( {state.count} actions.down(1)}>- actions.up(1)}>+ ) The lit-html would be: const view = (state, actions) => html` {state.…
> Nearly identical. lit-html uses ` `s and cloning, so that it doesn't have to do any expensive VDOM diffs. So… it's not doing reconciliations and is just replacing the entire tree on every render, losing things like cursor position and forcing the browser to re-render and re-layout the entire thing?
Actually it does not :)
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#79Earlier quoted context omitted.
It depends. If you are making a shallow copy every time via `Object.assign` or the `{...obj}` syntax, then yes, it is rather inefficient. But a) for many (most?) apps it's Good Enough™, and b) you can always use a specialized library like Immutable.js to greatly reduce the overhead. I'm not sure about what would be the benefit of the scheme you are proposing. Are you proposing that the diff then gets applied directly…
Oh right, immutable data structures are good for exactly this situation. I've been in mutation land for a while now. :) However, now I'm newly confused: Yes, I'm proposing that the diff then get applied directly to the state by the Redux infrastructure, and I don't understand why that would break any important assumptions provided by Redux. Is there an example you could give of how this might create a problem?
You would have to be much more disciplined with your approach. With Redux, if I store a reference to any part of the state, I am guaranteed that the value will never be changed by Redux itself (so, unless I manually mutate it, it is guaranteed to be frozen [0]). Because of this, I can do things like safely store a value off of the Redux state inside a component, and when the state changes, I can compare the new value against my stored value to see if it has changed. If you directly mutate state, then the reference would update in-place, so there is no way to compare changes locally without first making a copy.
It also goes the other way: I can't accidentally change the state by mutating the object I get back. With your scheme, any "accidental" mutation on any part of the state will actually change the state. This opens up a whole world of bugs, because any time you want to store part of the state locally (inside a component, for instance), you have to remember to make a copy if you want to guarantee that no unwanted side effects occur. (Plus, getting into the convention of "everything is immutable" means you can generally be much more confident about passing objects around without fear of them being mutated unexpectedly.)
Edit: Now that I think about it, what you are proposing sounds pretty similar to MobX.[1] You should check it out if you haven't already. I personally strongly prefer Redux for the reasons I mentioned, but it's a pretty solid library either way.
[0]: In development, it's very easy to enforce this with Redux by simply calling `Object.freeze` on the state in the root reducer, completely preventing the state object from being mutated.
[1]: https://mobx.js.org/
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#80I've seen "Show HN: HyperApp" type of submissions at least 5 times earlier. Congrats, you made a 1Kb JS library. Please stop spamming HN though. https://hn.algolia.com/?query=hyperapp&sort=byPopularity&pre...
I don't even get why it is important that it's 1kb. Give me a library with great API and easy to use. Nobody cares if library is 1kb or 100kb (minified).
HyperApp has a great API, and for Web client code, size does matter.