Live data from Hacker News

Show HN: HyperApp – 1k JavaScript framework for building web applications

github.com

11–20 of 169 posts

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#11
This looks pretty awesome! Inspired by hyperscript I assume?

https://github.com/hyperhype/hyperscript

Question: I was looking over the source and noted that you weren’t building your virtual dom with the document fragment API https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra...

Is there any particular reason why? I’m curious because it’s my general understanding that creating a document fragment and attaching your vnodes to that and then pushing to the dom is more efficient especially for diffing

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#12

Side 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.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#13

This one is 25 bytes gzipped http://vanilla-js.com/

The dependencies add up though, it's more like it's 17 Megabytes on the server

https://nodejs.org/dist/v8.11.2/

Or 30 MB for the client side

https://www.google.com/chrome/

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#14

Side 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 to the state (`state.foo += 1`)? If so, you would remove a powerful assumption that Redux gives you: that a state object will never change from underneath you after being returned from the store. If, instead, you would make a shallow copy of every value affected by the diff, then you haven't gained anything over Redux, and in fact have made the API significantly more complicated for no benefit (aside from maybe slightly less boilerplate for deep paths).

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#15

This one is 25 bytes gzipped http://vanilla-js.com/

You do realize that this is simply a page that advocates using plain JavaScript and isn’t an actual “framework” right? I mean I can see the point you are trying to make, but it feels mildly disingenuous to link to this without explaining what you really mean.

It's just a joke really.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#19
This is an exceptionally simple library to use in place of React. Both its performance and the development experience have been great.

My company's been using it in production for more than a year now without any issues. Highly recommend giving it a look.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#20

Earlier quoted context omitted.

You do realize that this is simply a page that advocates using plain JavaScript and isn’t an actual “framework” right? I mean I can see the point you are trying to make, but it feels mildly disingenuous to link to this without explaining what you really mean.

It's just a joke really.

I have a better one.

Knock knock... blank page... ++: "Uncaught TypeError: cannot read property 'a' of undefined."

Post reply on HN