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

81–90 of 133 posts

Re: Glimmer – Fast and light-weight UI components

#81

Post by boubiyeah »

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…

2 years ago, we released a pretty complex project (real time updates, event sourcing, dozens of views, etc) using virtual-dom into production. 2 designers were with us and occasionally helped with the crafting of views, they never complained and weren't lost at all; they actually found it funny and enjoyed it.

"It's familiar good ol HTML" is marketing again.

The argument about underpowered templates being easier to optimize is true though (see svelte for another approach), but it doesn't seem to matter nowadays. Good luck finding an actual difference with a good virtual-dom lib (known for their GC demands) even on a low powered machine on a real app.

Re: Glimmer – Fast and light-weight UI components

#82

Post by kolme »

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…

Yes, and 8) being a library and not having any code snippets.

Re: Glimmer – Fast and light-weight UI components

#83

Post by [deleted] »

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…

[deleted]

Re: Glimmer – Fast and light-weight UI components

#84

Post by andai »

kolme wrote: post #82
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…

Yes, and 8) being a library and not having any code snippets.

9) Video thumbnail (and half of video) is a guy's face.

(Consider changing video thumbnail to a screenshot of the software in action, or even a logo.)

Re: Glimmer – Fast and light-weight UI components

#85

Post by pzuraq »

mattnewton wrote: post #80
mintplant wrote: post #56

Earlier quoted context omitted.

So you're still working within a framework, then.

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.

When and why did you fork Ember to get around it's opinions? I've been developing with Ember for 5 years now, and the only time I ever had to modify the source was with Ember Data pre-1.0.0, when it wasn't solidified at all. The concepts behind the framework are really simple, and literally everything is configurable.

Re: Glimmer – Fast and light-weight UI components

#86

Post by Axsuul »

This library has a lot of promise for prototyping your app in Glimmer and then dropping it into an Ember framework when the app gets bigger.

However, the whole landing page screams "premature release". The API docs are sparse, the landing page barely conveys what the hell is going on, and there's so many other minor nuances. Why does the GitHub link on the top right go to the website source for example? Everyone pretty much expects to be taken to the actual library GitHub.

Re: Glimmer – Fast and light-weight UI components

#87

Post by BigJono »

finchisko wrote: post #57
EvilTrout wrote: post #11

As a long time (5 years full time) Ember developer, this is quite interesting to me philosophically. I've spent a lot of time trying to tell people that all the stuff in Ember is there for a reason; for example, you're going to need a router, you're going to need support for controllers, etc. I still feel strongly that if your app is large and serious you are going to need that stuff. But. A lot of people just want t…

"still feel strongly that if your app is large and serious you are going to need that stuff." My approach usually is, start minimalistic and if you need additional stuff, you can usually add it later. That is why I like React. For example if I need router, I can choose from many implementation, but there are also cases when I don't need it all.

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 working with people I know well, I'll often elect to start off a fresh project with just React and maybe Redux, and build from there. Even if I know full well that we'll need some stuff like thunk and react-router, my preference is to leave them out and let the team run into the problems they solve before we introduce them.

IMO even if just one team member gains a new understanding about why their tools exist and why they're using them, it's worth a bit of refactoring.

Re: Glimmer – Fast and light-weight UI components

#88

Post by mnutt »

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.

Re: Glimmer – Fast and light-weight UI components

#89

Post by luketheobscure »

mattnewton wrote: post #80
mintplant wrote: post #56

Earlier quoted context omitted.

So you're still working within a framework, then.

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 (even when it was a bad idea, which it often was).

I would really like to know what prompted you to fork Ember.

Re: Glimmer – Fast and light-weight UI components

#90

Post by mnutt »

BigJono wrote: post #87
finchisko wrote: post #57

Earlier quoted context omitted.

"still feel strongly that if your app is large and serious you are going to need that stuff." My approach usually is, start minimalistic and if you need additional stuff, you can usually add it later. That is why I like React. For example if I need router, I can choose from many implementation, but there are also cases when I don't need it all.

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 shared set of functionality that is well-tested together and that stays the same between multiple projects and teams.

I think adopting something like ember is pretty much the opposite of "can't maintain it" since while I understand how it works internally, I don't actually have to maintain it myself. In my experience I've seen more instances where we ended up ripping out a homegrown library to replace with a community-supported solution than the other way around.

Post reply on HN