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

91–100 of 133 posts

Re: Glimmer – Fast and light-weight UI components

#91

Post by mattnewton »

luketheobscure wrote: post #89
mattnewton wrote: post #80

Earlier quoted context omitted.

But when the app grows, you can customize it instead of forking ember to get around it's opinions, something I have had to do in production apps.

I've been working full time on Ember stuff for a long time now, and I can not imagine a single reason to ever fork Ember. I've used different programming languages (CoffeeScript, don't make fun), templating languages (Emblem.js, don't ask), built and served it with Rails, without rails (Ember-CLI was a godsend), and hacked at it in a million different ways. All this was supported by API's or tooling within Ember (eve…

The first time it was for a sub-route that could be brought up in any other route (to show a little search pane in the app). We were told by the community just "not to do that" but it was in our spec and there wasn't a way to load the same countroller for multiple routes. The second time was more short lived, but it was to allow asynchronous modules to be loaded after the main app. There were no community solutions to this at the time. The last time wasn't really forking ember but we underwent a painful process of remaking most of our views in vanilla JavaScript for performance on mobile, which has gotten completely out of hand with all the two way bindings of pre-glimmer ember. It felt like we were fighting the framework the whole time.

If you go off the rails, it is extremely painful. I haven't looked at Ember in a while, because of my experiences, so ymmv. It could all be completely different now.

Re: Glimmer – Fast and light-weight UI components

#92

Post by conradk »

always_good wrote: post #67
conradk wrote: post #58

Earlier quoted context omitted.

Ah, thanks for explaining that ! I thought the Ember team had started an entirely new project instead of reusing something that already existed. If they extracted it, that makes much more sense to me now.

I don't understand these sorts of comments. "Heh, good thing you read and summarized TFA because I didn't and instead jumped to conclusions." I see it on HN all the time, like a celebration for not having to read the submission. "Phew, that was a close one!" There are maybe 8 sentences of copy on that landing page. One of them is: > Because Glimmer powers the components in Ember, > there’s a battle-tested, full-stack…

That's not what I meant to say at all.

Here, I saw what looked like a new project. You say I should have understood right away because Glimmer is said to power Ember's components. But the Ember team could very well have built an entirely new engine for its components. I thought Ember used to use Handlebars (didn't it?) and had just recently built a new engine (aka Glimmer) instead of adapting an existing one (React, Vue, etc). But that sounded odd, hence my question.

If you see these sorts of things all the time, there may be a reason: communication is hard and we all interpret things a bit differently (depending on our experience, our mindset, our native language, etc).

Re: Glimmer – Fast and light-weight UI components

#93

Post by BigJono »

mnutt wrote: post #90
BigJono wrote: post #87

Earlier quoted context omitted.

This is a very good way to go. In my experience, adding a new tool can take a day or two of refactoring in a medium sized project; but removing one can take a week. Removing a bunch because you completely over-engineered the solution and can't maintain it can often take a month, or even get dangerously close to "scrap it and rewrite" territory, which is a complete death sentence for a small company. Unless I'm workin…

I can see where you're coming from, but I tend to bucket apps I write into either general use case, mostly business-logic apps, or highly specific services. (say, a network proxy or compositor or something) The general use case apps all tend to share a good deal of requirements (multiple pages, authentication, forms, etc) and while it would certainly be possible to pick and choose each component, it's nice to have a…

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 release and seeing widespread adoption.

redux-thunk is a great example of what I'm talking about. The design pattern prescribed by it is confusing in subtle ways. They're basically overloading the terminology of "action creators" to mean two wildly different things. The main benefit is solid (it provides a way for controllers/business logic functions to access the data store through dependency injection rather than closures, making them easier to test) but the implementation isn't well thought out, the terminology surrounding it is confusing, and it provides rookie developers more ways to shoot themselves in the foot (see getState abuse).

If any of this craziness was proposed as a core part of Angular or Ember there would be enough sane devs speaking out against it and it would be changed. But since in a modular system in React you are free to choose parts as you please, everyone that knows what they're doing just elects not to use stuff like this, until it builds up enough of a cargo cult following that it becomes standard and starts infiltrating your work place, and suddenly you're outnumbered 20 to 1 by people that have just "always done it that way".

Re: Glimmer – Fast and light-weight UI components

#94

Post by Jare »

mnutt wrote: post #88
WhitneyLand wrote: post #76

This is the way not to design a landing page. 1) Ui components for what? 2) "Attention to detail of ember" - is that a quality comparison, or is it only for ember framework? 3) UI project without a single screenshot? 4) Doesn't mention one actual feature or component 5) GitHub link doesn't go to a repo. Instead it's a list of repos that you have to click around in to find the main project. 6) API docs link goes to a…

My guess is that while it's a standalone page, given the timing (released during emberconf keynote today) the copy is mostly targeted at ember devs, at least initially. As someone who is intimately familiar with ember, I immediately understood that it's for building apps with the ember rendering engine sans ember itself. For other devs, the purpose and benefits may not be as obvious.

With zero experience in ember, as soon as I saw that I first needed to install the ember cli, I assumed it was something built on top of ember. Which doesn't sound lightweight or even interesting to a non-ember user, so was quickly followed by a snarky smile and a quick close of the page. After reading some HN comments I understood that it was like a collection of actual widgets (like bootstrap, but lighter?) and was interested. Then I read the docs, saw it is a library to build components, and I filed it under "not going to use ember so I may as well stay with React".

Re: Glimmer – Fast and light-weight UI components

#95

Post by a-guest »

catshirt wrote: post #73
tomdale wrote: post #49

Earlier quoted context omitted.

JSX vs. templates is a common debate, with popular JSX options like React and Preact and template-based options like Vue and Glimmer. The reality is that there are hard tradeoffs to both and anyone who tells you one is obviously superior to the other is probably trying to sell you something. For me personally, templates ever-so-slightly edge out tools like JSX. For one, I subscribe to the Rule of Least Power[0]. Havi…

"The fact that Glimmer templates are "just HTML" makes them accessible to people like designers who may not understand all of the fancy destructuring or array mapping happening in your JSX." isn't this like, at least a little backwards? JSX is HTML and JS. templating languages are HTML with some custom DSL. destructuring and especially mapping are pretty simple concepts. creating a new syntax to cater to people who c…

> 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, as compared to the JSX syntax.

Re: Glimmer – Fast and light-weight UI components

#96

Post by gexla »

WhitneyLand wrote: post #76

This is the way not to design a landing page. 1) Ui components for what? 2) "Attention to detail of ember" - is that a quality comparison, or is it only for ember framework? 3) UI project without a single screenshot? 4) Doesn't mention one actual feature or component 5) GitHub link doesn't go to a repo. Instead it's a list of repos that you have to click around in to find the main project. 6) API docs link goes to a…

This is an open source project. Probably there is nobody agonizing over anything on this site (not because they are spending all their time working on the project, but because they probably have full time jobs). It's also likely that if you are arriving here, you probably already know what this is. You probably got here through Ember.

If you want to contribute.

https://github.com/tomdale/glimmer-website

Re: Glimmer – Fast and light-weight UI components

#97

Post by stickfigure »

always_good wrote: post #67
conradk wrote: post #58

Earlier quoted context omitted.

Ah, thanks for explaining that ! I thought the Ember team had started an entirely new project instead of reusing something that already existed. If they extracted it, that makes much more sense to me now.

I don't understand these sorts of comments. "Heh, good thing you read and summarized TFA because I didn't and instead jumped to conclusions." I see it on HN all the time, like a celebration for not having to read the submission. "Phew, that was a close one!" There are maybe 8 sentences of copy on that landing page. One of them is: > Because Glimmer powers the components in Ember, > there’s a battle-tested, full-stack…

It's not the parent's fault. I read that landing page, clicked around a bit, and still had no idea what I was looking at. The top comment thread here on HN is about how confusing the page is.

It really would be much clearer if they deleted all the text on the landing page and added This is the view layer extracted from Ember as a standalone library.

Re: Glimmer – Fast and light-weight UI components

#98

Post by mikeryan »

gexla wrote: post #96
WhitneyLand wrote: post #76

This is the way not to design a landing page. 1) Ui components for what? 2) "Attention to detail of ember" - is that a quality comparison, or is it only for ember framework? 3) UI project without a single screenshot? 4) Doesn't mention one actual feature or component 5) GitHub link doesn't go to a repo. Instead it's a list of repos that you have to click around in to find the main project. 6) API docs link goes to a…

This is an open source project. Probably there is nobody agonizing over anything on this site (not because they are spending all their time working on the project, but because they probably have full time jobs). It's also likely that if you are arriving here, you probably already know what this is. You probably got here through Ember. If you want to contribute. https://github.com/tomdale/glimmer-website

Personally - I got here through Hacker News

Re: Glimmer – Fast and light-weight UI components

#99

Post by chacham15 »

tomdale wrote: post #63
TheAceOfHearts wrote: post #40

Earlier quoted context omitted.

What are their respective sizes? Could you link to some benchmarks? I wonder how it'll stack up to React Fiber. I love when libraries compete on performance, since it can end up benefiting everyone.

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?

Re: Glimmer – Fast and light-weight UI components

#100

Post by bluepnume »

Coming from someone who loved writing apps with Ember, before moving on to other things, I think this is a step in the right direction. Having the UI library as its own standalone thing is a great move.

That said, it's way too hard to figure out how to buy into this thing without adopting the whole ember-cli ecosystem.

Ember-cli is a fantastic achievement, but for god's sake, give me a CDN link with a global `glimmer` object so I can at least play around with the thing in one of my projects, without buying into the entire ecosystem first!

I know that Ember is the "we'll take care of your whole app" framework, but with Glimmer maybe there's a chance here to cater to folks who love libraries like React, because they can get started with about 5 lines of code bunged into an html file and grow from there.

Let me start small, and make it easy for me to grow big.

Post reply on HN