Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Glimmer – Fast and light-weight UI components

glimmerjs.com

Post reply on HN
Print view View original

121–130 of 133 posts

Re: Glimmer – Fast and light-weight UI components

#121

Post by a-guest »

catshirt wrote: post #115
a-guest wrote: post #95

Earlier quoted context omitted.

> JSX is HTML and JS (?) "JSX is a preprocessor step that adds XML syntax to JavaScript." http://buildwithreact.com/tutorial/jsx Whereas the templates in Glimmer are built on HTML. At the 10,000 ft view, my two cents: it looks easier to reason about what is going on with dynamic elements in the template via handlebars together with what is going with the html elements themselves in terms of rendering/appearance/css,…

i'm less concerned with what "looks" easier than what's actually easier. i just can't convince myself "it looks less scary" is worthy of the technical tradeoffs (for me, at the very least).

> "looks" easier

I should have been clearer and said: it actually is easier to reason about the html and the dynamic rendering with the approach Glimmer takes.

Re: Glimmer – Fast and light-weight UI components

#122

Post by cibernox »

chacham15 wrote: post #99
tomdale wrote: post #63

Earlier quoted context omitted.

The Glimmer runtime is under 30k, and we have not done much bundle optimization yet so hopefully this should go down a little bit even further. React Fiber is currently just over 70k, and that's just the reconciler, not the complete React package. However, according to Dan Abramov[0] they have not yet focused on optimizing the bundle size either. And Fiber includes some prioritization features that we don't have in G…

Is incremental rendering something that will be added to Ember/Glimmer?

It has it already. It had it for a while

Re: Glimmer – Fast and light-weight UI components

#123

Post by cibernox »

dandare wrote: post #102

I always wondered what is the business model of a library like this. Is just someone spending hundreds of hours of his free time to create this for the community? Or is there a business model I don't see?

There is none. We develop ember because we need a tool to solve our problems and the existing solutions weren't good enough in at least some aspect that mattered.

The idea is that opensourcing software makes people you don't know can use it, improve it and ultimately you get those improvements yourself.

Re: Glimmer – Fast and light-weight UI components

#125

Post by mlsarecmg »

elwayman02 wrote: post #2

Glimmer is smaller and faster than React, with TypeScript supported natively. This is a game-changer for people who are looking for a lightweight rendering library that ships with great tooling support and a larger framework ecosystem behind it.

React-lite is 25kb, it gets there by stripping off proptypes and some other things without, sacrificing functionality, so it can always be applied as a production alias. Things like Preact and Inferno compat go even further, you can bring React down to 5kb or less. With React Fiber it will be easier to create modular packages that contain specifically what the app needs.

TS already supports JSX.

Re: Glimmer – Fast and light-weight UI components

#126

Post by mlsarecmg »

a-guest wrote: post #121
catshirt wrote: post #115

Earlier quoted context omitted.

i'm less concerned with what "looks" easier than what's actually easier. i just can't convince myself "it looks less scary" is worthy of the technical tradeoffs (for me, at the very least).

> "looks" easier I should have been clearer and said: it actually is easier to reason about the html and the dynamic rendering with the approach Glimmer takes.

Only for someone who has never seen JSX, and for very simple cases. For anything that goes deeper you have to break the pre-made HTML conditionals and circumvent. For instance the horror an Angular uses goes through to loop an object with "pipes" which are now defined in separate files, whereas everyone else would use Object.keys and that's that. I often wonder, where are the actual benefits with templates, all i can see from using them are critical downsides.

Do this in a template for instance:

    import range from 'lodash/range'
    
    const Item = ({ number }) => {number}
    const App = () => (
        
            {range(0, 20, 5)
                .map(index => 
                    
                )
            }
        
    )
Templates can't even resolve because they don't know scope. The have no access to `range` either. Instead we're now hacking around with template registrations and injections. This results in a mess of functionality sprinkled all over the place for no good reason.

Re: Glimmer – Fast and light-weight UI components

#127

Post by dbbk »

dandare wrote: post #102

I always wondered what is the business model of a library like this. Is just someone spending hundreds of hours of his free time to create this for the community? Or is there a business model I don't see?

Well there's a group of people in the Core Team. I know at least one of them has been hired by their company (LinkedIn) to work on the framework full time, as their app (and subsequent business) is built on top of it, so it makes sense to have someone paid to focus on it.

Re: Glimmer – Fast and light-weight UI components

#128

Post by BigJono »

acemarke wrote: post #118
BigJono wrote: post #93

Earlier quoted context omitted.

Oh, absolutely. I wasn't trying to comment on the difference between the monolithic and modular approaches of Ember and React respectively. I think the monolithic approach actually solves the problem I'm describing to some extent, because developers in those ecosystems are forced into using these tools and patterns, which gives people a vested interest in making sure they're actually good before going into the next r…

Can you clarify what you mean by "the implementation isn't well thought out"? It's a 10-line function that basically just checks to see if the argument is a function, and if so, executes it. Thunks _are_ "action creators", in the sense that they are given `dispatch` and allowed to dispatch things. The word "thunk" is a long-standing CS term, per [0]. I addressed the `getState` question in my blog post "Idiomatic Redu…

'implementation' was probably the wrong choice of word there. 'design decisions' is probably better.

I'm not sure we're working with the same definition of 'action creator' here, because redux-thunk completely moves the goal posts. In redux, an action creator is a utility function which takes some parameters and creates an action, returning it. This is rather intuitive. It's purpose is to allow functions that dispatch actions to build their actions using a common interface, with little risk of generating an action in a format the dispatcher is not expecting.

In redux-thunk, an action creator is a function which takes some parameters and executes a bunch of business logic, dispatching actions created by OTHER action creators along the way. It does not create any actions and does not return any actions. It's a misnomer.

The only thing a redux-thunk action creator has in common with an actual action creator is they both implement the dispatch interface. This is not at all intuitive for new developers.

Moreover, it's completely unnecessary. What do you gain by overloading the dispatch function to do two completely unrelated things? Nothing. You could just as easily create a differently named higher order function that passes dispatch and getState into whatever function is passed into it, and it would be functionally identical.

Re: Glimmer – Fast and light-weight UI components

#129

Post by acemarke »

BigJono wrote: post #128
acemarke wrote: post #118

Earlier quoted context omitted.

Can you clarify what you mean by "the implementation isn't well thought out"? It's a 10-line function that basically just checks to see if the argument is a function, and if so, executes it. Thunks _are_ "action creators", in the sense that they are given `dispatch` and allowed to dispatch things. The word "thunk" is a long-standing CS term, per [0]. I addressed the `getState` question in my blog post "Idiomatic Redu…

'implementation' was probably the wrong choice of word there. 'design decisions' is probably better. I'm not sure we're working with the same definition of 'action creator' here, because redux-thunk completely moves the goal posts. In redux, an action creator is a utility function which takes some parameters and creates an action, returning it. This is rather intuitive. It's purpose is to allow functions that dispatc…

Eh... a thunk could absolutely call `dispatch({type : "SOME_ACTION"})` rather than doing `dispatch(anotherActionCreator())`. It also allows consistent use of binding to `dispatch` in conjunction with `connect`, per my post "Idiomatic Redux: Why Use Action Creators?" [0].

The canonical explanation for why middleware is the place for async logic is in a couple of SO posts by Dan Abramov [1] [2]. Quote:

> So the benefit of using middleware like Redux Thunk or Redux Promise is that components aren’t aware of how action creators are implemented, and whether they care about Redux state, whether they are synchronous or asynchronous, and whether or not they call other action creators.

In other words, a component simply calls `props.someFunction(someData)`, and it doesn't care where the function came from, or exactly what it does. It could be a plain action creator, a thunk, or a spy in a test. If there's asyncness that needs to happen, that can be handled outside the component in a reusable fashion.

There's also precedent for overloading `dispatch` and "teaching" it to understand parameters other than plain action objects, such as promises.

I understand your points, but very much disagree with your conclusions. (In a slight appeal to authority: I'm one of the current maintainers of Redux, and keep a list of links to React+Redux resources [3].)

[0] http://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why...

[1] http://stackoverflow.com/questions/35411423/how-to-dispatch-...

[2] http://stackoverflow.com/questions/34570758/why-do-we-need-m...

[3] https://github.com/markerikson/react-redux-links

Re: Glimmer – Fast and light-weight UI components

#130

Post by BigJono »

acemarke wrote: post #129
BigJono wrote: post #128

Earlier quoted context omitted.

'implementation' was probably the wrong choice of word there. 'design decisions' is probably better. I'm not sure we're working with the same definition of 'action creator' here, because redux-thunk completely moves the goal posts. In redux, an action creator is a utility function which takes some parameters and creates an action, returning it. This is rather intuitive. It's purpose is to allow functions that dispatc…

Eh... a thunk could absolutely call `dispatch({type : "SOME_ACTION"})` rather than doing `dispatch(anotherActionCreator())`. It also allows consistent use of binding to `dispatch` in conjunction with `connect`, per my post "Idiomatic Redux: Why Use Action Creators?" [0]. The canonical explanation for why middleware is the place for async logic is in a couple of SO posts by Dan Abramov [1] [2]. Quote: > So the benefit…

Anything can dispatch a hard coded action though. By that logic if I elect not to use the common action creator pattern (without thunk, i.e just standard action creators that return an action), does that make my React components action creators?

What if I put a 'createFoo' function in my component that creates a foo action, and call dispatch(this.createFoo()) from elsewhere in the component? Now what is the action creator? Is it the function, or is it the component? Because going by the terminology in the redux docs it'd be the function, and going by the terminology in the redux-thunk docs, it'd be the component.

That's the ambiguity I'm talking about. I'm sure Dan Abramov has a consistent logical model in his head for reasoning about this, but it hasn't been properly divulged to the community. I could find you at least 5 devs I've met IRL that think it's the function, 5 that think it's the component, and 5 that think it's both.

> So the benefit of using middleware like Redux Thunk or Redux Promise is that components aren’t aware of how action creators are implemented, and whether they care about Redux state, whether they are synchronous or asynchronous, and whether or not they call other action creators.

No, the mapDispatchToProps pattern is what provides this layer of abstraction. If a component calls 'this.props.doFoo', why does it care whether doFoo starts an asynchronous process by calling an overloaded 'dispatch' function that could mean one of two completely different things, or using the same thunk pattern with a less confusing name?

I'm not disagreeing with anything you're saying in this post. What I'm saying is that the choice of API for redux-thunk is ambiguous and confusing, not that the pattern itself is bad (in-fact I think it's very good).

> There's also precedent for overloading `dispatch` and "teaching" it to understand parameters other than plain action objects, such as promises.

There's precedent for murdering people too, it happens a hundred times a day across the country. Doesn't make it a good idea.

Post reply on HN