
Glimmer – Fast and light-weight UI components - makepanic
https://glimmerjs.com/
======
EvilTrout
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 to jump in and start building. React's immense
popularity has shown the value in creating a view layer framework without all
the extra stuff. It's great for onboarding new developers since there is less
surface area to familiarize yourself with, and you can add in extra stuff
(work your way towards full Ember) as you go.

It also comes with the added benefit of being able to add small components to
a page without running the whole thing as an application, which is a use case
Ember was not so great at before.

Overall I think it's a great announcement.

~~~
k__
I used Ember for about 2 years and thought so too.

Now I'm using React and I think it's approach is much better.

The API is tiny compared to Ember and there aren't much concepts, still it
accomplishes everything Ember did.

I feel bad to say this, but in the modular, library heavy, NPM based JS world
of today, React (and other component frameworks like Cyclejs or hyperapp) fits
just in. While Ember feels like a anachronism of the big framework days of
Rails. :/

~~~
elwayman02
Why would you want to build a bespoke React-based framework for every app you
make? Why not simply have everything you need out of the box, plus the ability
to easily integrate any npm library into your app via first-class build
tooling that is miles easier to use than something clunky like Webpack?

~~~
k__
Because in my experience the "out-of-the-box" solutions always break down the
more you want to customise them.

Now I rather prefer solutions that have customisation in mind from start, so
it's always easy to switch things.

~~~
mhd
I remember when that wave hit the Ruby/Python space, with things like
Pyramid/Pylons. These days that seems to have gone the way of the dodo, with
the big monoliths still being around and then some minimal HTTP decorators
like Sinatra/Flask/Node. Problem is that the middle ground would require a
level of modularity that we still haven't reached, despite all the talk of
"software ICs" that came around with early OOP.

I predict that's how we're going to end up in a few years again. Some big
monoliths (whatever react is morphing into currently, plus Angular and as the
world is a cruel mistress, ExtJS), plus a plethora of DOM wrappers and view
libraries.

And 72 build systems.

~~~
ergo14
You know that pyramid powers some of the most important infrastructure for
python? Like new version of PYPI ([https://pypi.org/](https://pypi.org/))? And
lots of big organizations use it - like Mozilla or NASA, sites like Reddit
still use pylons.

IF you think it went the way of the dodo, I'd suggest doing a bit of better
research before predicting the future :D Because IMO you are seriously off
here.

~~~
mhd
I'm talking about the trend of build-your-own frameworks, not the software
itself. Heck, there are enough sites out there still using Zope, MASON and
Aolserver.

~~~
ergo14
Pyramid is feature complete as a framework in my opinion - with defaults
requires less thinking vs. lets say flask - the resulting applications will be
more elegant and better organized (partly because it doesn't use globals
eveywhere). The glue is quite good nowdays.

------
panic
_Close to the metal: Glimmer is one of the fastest DOM rendering engines,
delivering exceptional performance for initial renders as well as updates.
Architected like a virtual machine (VM), Glimmer compiles your templates into
low-level code so it can run as fast as possible—without sacrificing ease of
use._

By low-level code, they mean… JavaScript, right? In what sense is this "close
to the metal"?

~~~
halfdan
No, they are compiling it down to instructions which are then interpreted by
the Ember/Glimmer VM:
[https://youtu.be/vg5A_UOGShg?t=42m8s](https://youtu.be/vg5A_UOGShg?t=42m8s)

~~~
spicyj
…which is written in JS. Everything's all relative though. JS is certainly a
reasonable choice for this.

~~~
shawndumas
They mean that they made use of --allow_natives_syntax to identify Hidden
Classes.

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

~~~
vorpalhex
The install parameter you provide already requires yarn and the rather large
ember-cli, in addition to requiring my app to be built on top of glimmer
instead of with it.

How can this possibly be considered remotely lightweight, especially compared
to something like Mithril? I count at least 12 repos on your github that seem
to be integral components including a dedicated CLI!

~~~
lyime
Why is the size of the CLI a concern?

~~~
Touche
What I think the GP is saying, and I agree, is that the CLI makes Glimmer the
center of your world and not just another library you use. MomentJS doesn't
come with a CLI tool to use it. You just use it.

------
ssijak
Whoa, good. I was worried, 12h passed without major new JS framework on the
front page. But, clock started ticking again..

~~~
a-priori
Maybe you should read about it a bit before you dismiss it with useless snark.

This is not a new JS framework. This is the view layer extracted from Ember as
a standalone library.

~~~
conradk
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.

~~~
always_good
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 framework
        > waiting for you—if you need it.

~~~
stickfigure
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._

------
modularfurnitur
I cut my teeth using Ember a few years back, the whole community is amazing
and does great work. Using react/redux now, and while I think it's the
simplest and most pragmatic approach (the connect function changed the game),
I think the api's over in clojurescript land, specifically re-frame are the
best . It's conceptually the same as react/redux, but with a few more
facilities for isolating side effects in actions, and a wayyyyy simpler api
for querying the store in functional components.

But what I came to say is I think templating languages are sub par. Using an
actual programming language that returns "html", or some variant (like
clojurescripts hiccup language) is way more useful. I wouldn't use this
because of that.

~~~
dustinfarris
If you feel like giving Ember another whirl in the future, ember-redux is
production-ready and has a comparable API to react-redux. (e.g. `connect`)

[https://github.com/ember-redux/ember-redux](https://github.com/ember-
redux/ember-redux)

------
config_yml
side point: rwjblue is an absolute beast if you look at his contribution
activity [https://github.com/rwjblue](https://github.com/rwjblue), his output
is amazing and much appreciated!

------
erikpukinskis
> _Glimmer compiles your templates into low-level code so it can run as fast
> as possible—without sacrificing ease of use._

What's the benefit vs just writing your templates in JavaScript in the first
place?

~~~
tomdale
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]. Having the full expressiveness
of JavaScript is very nice, but it makes it harder for tools to statically
analyze and optimize the rendering process. Ember has gone through three major
rendering engine architectures now (string-based, DOM-based and now the
Glimmer VM) and the simplicity of the templating language has made that
portability much easier.

[0]:
[https://www.w3.org/2001/tag/doc/leastPower.html](https://www.w3.org/2001/tag/doc/leastPower.html)

More importantly though, there are a lot of people in the world who know HTML
and CSS. 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.

Lastly, and this is perhaps just a personal foible, but I have a really hard
time mentally mapping more complicated JSX expressions into the final HTML
output. It's fine when you're writing it, but reading it later, particularly
to write CSS for it, is more challenging for me than Handlebars. I know some
people would say that this is a code smell and that I should break that
component up into smaller components, but I'd rather that decision be made by
me than because I feel forced into it by the muddiness of my render() method.

~~~
catshirt
"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 couldn't learn _one_ in the first place
seems counterintuitive?

is teaching someone a for loop really at all (let alone significantly) easier
than teaching them to map an array?

edit: "creating a new syntax to cater to people who couldn't learn one in the
first place seems counterintuitive?" on second read this seems thoughtless.
isn't that almost the whole point of a DSL? i think you and i have convinced
myself to stop hating on templates.

~~~
a-guest
> JSX is HTML and JS (?)

"JSX is a preprocessor step that adds XML syntax to JavaScript."
[http://buildwithreact.com/tutorial/jsx](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.

~~~
catshirt
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).

~~~
a-guest
> "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.

~~~
mlsarecmg
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 }) => <li>{number}</li>
        const App = () => (
            <ul>
                {range(0, 20, 5)
                    .map(index => 
                        <Item number={index} />
                    )
                }
            </ul>
        )
    

Templates can't even resolve <Item> 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.

------
WhitneyLand
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 page that is blank except for another link to the
actual API docs.

7) Add a few points back because at least they didn't name it CockroachUI (I
still have hope the CockroachDB guys will change their name).

Just a guess - rhis was done by someone who has not agonized over bounce rates
in google analytics.

~~~
gexla
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](https://github.com/tomdale/glimmer-website)

~~~
mikeryan
Personally - I got here through Hacker News

------
vvoyer
Did not find easily any live example, should be required for any "UI" library.
And should be displayed on the frontpage

~~~
tomdale
The API docs themselves are a Glimmer app:
[https://glimmerjs.com/api/](https://glimmerjs.com/api/). The source code is
here: [https://github.com/glimmerjs/glimmer-api-
docs](https://github.com/glimmerjs/glimmer-api-docs)

You may also enjoy the prerequisite turbo-stress-test app:

[https://glimmerjs.com/demos/uptime-
boxes/](https://glimmerjs.com/demos/uptime-boxes/)

[https://github.com/glimmerjs/glimmer-
demos](https://github.com/glimmerjs/glimmer-demos)

~~~
leeoniya
do you guys have any benchmarks where the dom tree is not mostly static?

uptime-boxes suffers from the same problems as the original dbmon - the tree
is static and the diffing engine has little to do while the DOM mutations are
only nodeValue/textContent and className.

------
finchisko
"fastest DOM rendering engines, delivering exceptional performance for initial
renders as well as updates."

I read this every time new fw pops up. Usually those kind of claims are
exceptionally exaggerated.

~~~
ryantablada
A big difference around that is that Glimmer is not just a new FW. It is an
abstracted and consolidated version of the view/component layer that has been
battle tested in Ember for years.

------
0xADADA
Looks like its a smaller deployment (38kb) nearly as small as Preact, much
smaller than Ember, and brings TypeScript support and <angle-bracket> style
components to the ember ecosystem.

~~~
Touche
38k is not nearly as small as Preact. Preact is 4k.

------
subpixel
This looks impressive and has been something the Ember community has been
looking forward to for a long time, but I wonder whether Glimmer is a tool
that will actually sway developers who are not already using Ember to start
using it (read: choose Ember over React, Vue, Angular, etc.).

------
mnutt
For those that want to try it out, it looks like the released ember-cli
version doesn't support it. To test it out, you can replace the first
instruction on that page with: `yarn global add ember-cli/ember-cli`

(edited for better command)

~~~
mwpmaybe
This will do the trick:

    
    
        yarn global add ember-cli/ember-cli

~~~
johnrlive
I get this error when I type 'ember' in terminal "zsh: command not found:
ember"

~~~
johnrlive
figured it out:

1\. Add the following in my .zshrc file: export PATH="$(yarn global
bin):$PATH"

2\. "yarn global remove [package-name]" then "yarn global add [package-name]"

------
dandare
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?

~~~
Matthias247
In theory you could hope that you find users and afterwards offer consulting
and support services for your users. As well as charge for development of
custom features/extensions that they need.

I guess in practice I think business models around libraries, frameworks and
infrastructure software are hard. There is often lots of competition. And
users in the meantime often expect that these things (including support) are
for free.

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

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

------
pier25
Can anyone compare this to Vue?

------
chrisabrams
Fast and "light-weight" Ember UI components _

------
ergo14
Looking at the docs this looks a bit like Polymer 2.0, except not using ES6
but TS. I like it.

------
aligajani
Oh no, not again..

------
matthoiland
Tl;dr; Ember is often overkill for a simple app. Glimmer is a lightweight
framework, similar to VueJS with tiny build sizes. Being part of the Ember
ecosystem, a simple Glimmer app can grow as needed to a full Ember app. "NPM
your way to Ember" was the motto they used today at EmberConf. As an Ember AND
Vue fanboy, this is cool.

------
mhd
Hmm, pretty heavy use of ES6, too (async/await, decorators etc.). Is there any
"modern" library left that lets you use the browser's JavaScript engine
directly, without transpiling?

~~~
bjacobel
Neither async/await nor decorators are part of ES6 (which is more properly
called ES2015).

Almost all major browsers support ES2015. A few recent versions support
async/await, now that it's expected for that syntax to be a part of ES2017.
None support decorators (in fact, I'd be surprised if decorators ever make it
into the formal ES spec).

~~~
mhd
Compared to other Javascript libraries, it's not that bad, I was just hoping
for a second that "extracted the render engine" meant something really
lightweight, i.e. something you could just include as a script tag for
lightweight use (like "sizzle", back in the days).

It's still going to be worth a look, as I don't mind opinionated stuff for
some mid-sized SPAs and tools, I'm just missing a tool for the lower end in my
belt these days.

------
conradk
I can't help but think: yet another front-end library. But Ember being solid,
there is probably good reason for this project.

What does Glimmer do that all of the existing view libraries couldn't do ?
x-tags, vue, react, preact, etc, etc, etc.

Wouldn't an abstraction layer on top of any of those libraries have avoided
the need to create an entirely new project ?

~~~
Touche
I think the abundance of view libraries is evidence that no one has really
"solved" it.

------
leeoniya
to avoid repeating myself here:
[https://www.reddit.com/r/javascript/comments/6212ym/glimmerj...](https://www.reddit.com/r/javascript/comments/6212ym/glimmerjs_the_rendering_engine_behind_emberjs_can/dfiw396/)

