Glimmer – Fast and light-weight UI components(glimmerjs.com)

314 pointsby makepanic9 anni fa126 comments

Glimmer – Fast and light-weight UI components

https://glimmerjs.com/

132 comments

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__9 anni fa

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

_____s9 anni fa

With Glimmer as a standalone library, I think ember's going in the right direction. There's been some excellent work on Fastboot and Engines in the last year or so and I really like the approach ember's team is taking with this.

React, for me, still offers better composability. You deal in plain JS objects, pass them around, and can build really complex UIs on top of that. I also really like redux. I still use ember heavily though; I think we'll get there as well!

Touche9 anni fa

I think Ember is really good at marketing the stuff they work on, but it is usually overhyped.

Fastboot, for example, was announced what, 3 years ago? The readme says it's still not ready to use:

> The bottom line is that you should not (yet) expect to install this add-on in your production app and have FastBoot work.

https://github.com/ember-fastboot/ember-cli-fastboot

I find this is often true of Ember projects (like Glimmer 1), a lot of hype for something that has a lot of rough edges.

elwayman029 anni fa

At the end of the day, the Ember team takes a lot of time to not just build things the right way, but also make it as painless as possible for teams to upgrade along the blessed path. This has been a learning process to understand how much more time that takes, and has caused some past announcements to feel like they weren't delivered on, when in fact they simply just took more time to get right.

Touche9 anni fa

Yep, the 90-90 rule[1]

The other lesson to take is to be more cautious about announcing stuff before its really ready. But they don't seem to have learned that here. Here we have a project with its own logo, a marketing video with a nice electronica beat behind it, and a YouTube Live announcement...

... For something they are telling you to install from their master branch.

[1] https://en.wikipedia.org/wiki/Ninety-ninety_rule

[deleted]9 anni fa

_____s9 anni fa

One of the things with a large framework is that moving to a completely new direction is more challenging than it looks. So, at times, ember has made unrealistic promises — and Yehuda alluded to this in the keynote — but one can learn from it and get better.

As for Fastboot, it has its edges but there are people using it in production (DockYard is one, if I'm not wrong). ember-engines also says it's experimental and it does have some missing stuff (from my experience) but what is there works well.

Some of the things perhaps needed a rewrite of the underlying architecture. One great thing about ember (apart from v 1.13) has been just how painless it has been to upgrade. All the major changes they have made have largely been drop-in. Getting to that kind of backward compatibility is also a pretty impressive feat considering how big it is.

So, all in all, I agree that some of the things were overhyped and unrealistic but it seems they have learned from it, and I think that's just fine.

k__9 anni fa

Yes, I had the same feeling.

While the Ember devs talked about stuff like Fastboot and Glimmer, while other frameworks just had all this out of the box.

Their whole approach seems to be rather concept heavy and back in the days (2014/2015) the docs where horribly outdated and you had to check stackoverflow for basic things.

I had to use Ember 2 years on a project and found it clunky, but okay. I switched to React 2 years ago. And after I met a few hardcore Ember devs from back in the days, who said they switched to Angular2 or React I think this was the right decision. It's nice that the existing projects get so good support, but I wouldn't recommend anyone to start something new with Ember :\

elwayman029 anni fa

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__9 anni fa

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.

mhd9 anni fa

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.

ergo149 anni fa

You know that pyramid powers some of the most important infrastructure for python? Like new version of PYPI (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.

mhd9 anni fa

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.

ergo149 anni fa

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.

subpixel9 anni fa

I really don't, and few do, hence the popularity of create-react-app and next.js

mintplant9 anni fa

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

mattnewton9 anni fa

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.

luketheobscure9 anni fa

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.

mattnewton9 anni fa

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.

pzuraq9 anni fa

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.

824ueirwfjd9 anni fa

That hasn't been my experience with ember in the past 1.5 years. Granted when I was first introduced to it about 3 years ago, there were many issues and I wasn't keen on using it but since then things have improved a bunch.

k__9 anni fa

Nice to hear, I haven't used Ember for about 2 years now. When they started putting more effort in their CLI, this was the signal for me to jump ship and go for something more light weight.

LocalPCGuy9 anni fa

> still it accomplishes everything Ember did

That isn't really accurate unless you are adding additional libraries to accomplish all of the things Ember does. I'm not arguing with the rest of your post, just saying that statement is incorrect (in that it doesn't tell the entire story).

mwpmaybe9 anni fa

Glimmer.js may be more your speed!

finchisko9 anni fa

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

BigJono9 anni fa

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.

mnutt9 anni fa

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.

BigJono9 anni fa

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

acemarke9 anni fa

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 Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability" [1]. As a summary, yes, thunks (and sagas) give devs complete freedom to do what they want, and more "convention-driven" middleware can be useful, but they're also a level of abstraction that's not necessary, and sometimes you _need_ to execute arbitrary logic that doesn't fit a specific pattern like "REQUEST_START/SUCCESS/FAILED".

[0] https://en.wikipedia.org/wiki/Thunk

[1] http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-tho...

BigJono9 anni fa

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

acemarke9 anni fa

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

BigJono9 anni fa

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.

panic9 anni fa

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

ericwood9 anni fa

Pretty sure this is partially a joke based on the whole "nodeJS is close to the metal" thing: https://twitter.com/shit_hn_says/status/234856345579446272?l...

halfdan9 anni fa

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

spicyj9 anni fa

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

shawndumas9 anni fa

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

elwayman029 anni fa

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.

TheAceOfHearts9 anni fa

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.

tomdale9 anni fa

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

https://twitter.com/dan_abramov/status/844223224732958721

chacham159 anni fa

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

cibernox9 anni fa

It has it already. It had it for a while

chacham159 anni fa

Do you have a link to the docs for this? I cant seem to find it.

jbergens9 anni fa

I think Glimmer/Ember have lost already. React is fast enough for most things and then there is Infernfo and Preact that are faster right now. If you mean a larger ecosystem as in number of libraries I would guess that the react ecosystem is 10x the size of Embers.

maxkwallace9 anni fa

From my experience, the ecosystems are qualitatively different.

In Ember's, there's typically one community-sanctioned library that solves a particular problem, whereas React's tends to have more competing libraries. Like the frameworks, it's a tradeoff betw. customization and strong conventions. Doesn't make sense to compare based on number of libraries. Both approaches are valuable.

mlsarecmg9 anni fa

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.

vorpalhex9 anni fa

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!

tomdale9 anni fa

A legitimate question!

One thing people really love about Ember is that the process for going from nothing to a working app is very streamlined. Typically, this is not the case with smaller component libraries. Personally, I think there's a market for opinionated tools on this side of the simplicity spectrum.

Another aspect of this is that more complex build tools can often do better analysis of your app and move more work to build time, improving the boot and/or runtime performance of your app. For me, I'll trade a longer npm install time if it leads to a better experience for users.

That said, all of the Glimmer packages are distributed as AMD, CommonJS and JavaScript modules on npm[0], with a `module` field and everything in their package.json. While it's not as turnkey as using Ember CLI, I hope people feel empowered to experiment with whatever their favorite build tools are.

[0]: https://www.npmjs.com/org/glimmer

nkristoffersen9 anni fa

You shouldn't be deploying a CLI into production. While I haven't looked closely at this particular system, guaranteed you are not deploying the CLI. Just using the CLI to create deployable code.

When people say "lightweight" they mean small sizes over the wire. The final size of the production/deployment code. Not the development code.

EvilTrout9 anni fa

Those are only the build tools, and trust me you want a great build pipeline when dealing with Javascript these days!

In the screencast it shows that when you deploy you just get a javascript file for your components that should be super small.

lyime9 anni fa

Why is the size of the CLI a concern?

Touche9 anni fa

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.

boubiyeah9 anni fa

Did you try snabbdom? (https://github.com/snabbdom/snabbdom)

Works well for us :)

ergo149 anni fa

Polymer already fills that nieche I believe, except TS (it uses plain ES6).

JeremyBanks9 anni fa

Except for the lack of speed.

And the lack of great tooling.

And the lack of a large ecosystem.

And the insane data model.

I regret every moment I used Polymer.

ergo149 anni fa

- Lack of speed? - speed is equal to vue/react in dbmon benchmarks (even with polyfills).

- Tooling is quite good, polymer-cli, gulp, grunt support to name the most common stuff.

- https://www.webcomponents.org/elements - Thats a vibrant ecosystem :-) Big enterprises like ING, IBM, USAToday participate and release their components. (7k developers on slack channel)

- Insane data model? I work with my polymer elements same as I do with angular and react components. If in doubt just use redux/uniflow-polymer.

I get that you might not like it, but the issues you raised here are hardly valid (unless you used 0.5 or fresh 1.0)

spankalee9 anni fa

Can you tell me anything in particular lacking in our tooling? I know we have a lot of issues open, and a long way to go, of course, but if there's something specific it'd be helpful.

ssijak9 anni fa

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

a-priori9 anni fa

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.

conradk9 anni fa

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_good9 anni fa

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.

stickfigure9 anni fa

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.

conradk9 anni fa

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

cocktailpeanuts9 anni fa

It's a JS framework, it's new. No?

[deleted]9 anni fa

modularfurnitur9 anni fa

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.

dustinfarris9 anni fa

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

config_yml9 anni fa

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

erikpukinskis9 anni fa

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

tomdale9 anni fa

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

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.

ng129 anni fa

I absolutely hate any sort of HTML directives or non-trivial templating which in my mind violate the RoLP. You have a fundamentally simple technology and you're shoehorning complexity into it with the end result being there are multiple ways to implement everything. In my mind I'd rather have one tool to do everything -- Javascript. I don't think of JSX as HTML, I think of it more like Elm does -- a way to structure your UI in code which just happens to compile to HTML.

As for mapping JSX to HTML I think React's biggest strength is it's composability. But it comes with a price: things start to smell very, very quickly unless you religiously separate concerns.

boubiyeah9 anni fa

Yeah... That's my experience as well.

"Hummm, this string technology was meant for static webpages :( I think the solution is to create an arbitrary sub-language and add more string bits to it to make it dynamic" is more adapted when you quickly want to add a few dynamic behaviors to an existing static template here and there, but not so much when you build a complex app from the ground up.

Not to mention these opaque strings suck when you are serious about using a typed language :)

catshirt9 anni fa

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

boubiyeah9 anni fa

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.

a-guest9 anni fa

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

[deleted]9 anni fa

catshirt9 anni fa

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-guest9 anni fa

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

mlsarecmg9 anni fa

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.

[deleted]9 anni fa

LocalPCGuy9 anni fa

JavaScript takes time to parse and execute. My understanding is that the Glimmer solution reduces both parsing and execution time because it uses techniques that are highly optimized by the browser JavaScript engines, which makes it faster (sometimes significantly) than just using JavaScript templates. I also believe that's what is referred to when they use words like "low-level" and "close to the metal" in reference to what they are doing.

doublerebel9 anni fa

Specialized JS objects can conform to the Virtual DOM spec and therefore be most efficiently rendered by any Virtual-DOM renderer such as React, Maquette, Inferno, etc. It's easiest to use a template language or JS object builder that already conforms to the spec.

I use Pug/Jade, which always compiled to JS for speed and also supports Virtual DOM and server-side rendering. Pug can be written, understood, and updated by users who have no knowledge of JS but still gives me the full power of JS when necessary.

lowboy9 anni fa

> ease of use

WhitneyLand9 anni fa

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.

mnutt9 anni fa

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.

Jare9 anni fa

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

kolme9 anni fa

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

andai9 anni fa

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

jbergens9 anni fa

I agree that the page is very unclear. Look at the Guides part to see more about the component, for example starting at the file system layout and go forward in the menu.

I still don't think I will ever use this instead of react but maybe someone else likes it.

https://glimmerjs.com/guides/filesystem-layout

gexla9 anni fa

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

mikeryan9 anni fa

Personally - I got here through Hacker News

bphogan9 anni fa

If it's not ready to promote, it doesn't need a domain and a landing page. The README file in the repository would do.

If a project puts out a marketing page that doesn't clearly answer the "why should I use this and how will this make my life better" question, they're going to get feedback and criticism.

I found this link on HN. I literally have no idea what this is about.

[deleted]9 anni fa

digitalengineer9 anni fa

This is just an ad. Look at the DoubleClick script running on the page. No Google Analytics and/or Google Tag manager.

vvoyer9 anni fa

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

tomdale9 anni fa

The API docs themselves are a Glimmer app: https://glimmerjs.com/api/. The source code is here: https://github.com/glimmerjs/glimmer-api-docs

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

https://glimmerjs.com/demos/uptime-boxes/

https://github.com/glimmerjs/glimmer-demos

leeoniya9 anni fa

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.

mccoyspace9 anni fa

We built this with glimmer. https://mcast.io/katgraham-exclusives/

deno9 anni fa

What exactly do you need glimmer for on that page?

finchisko9 anni fa

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

ryantablada9 anni fa

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.

boubiyeah9 anni fa

Of course it's exaggerated. It's just marketing.

You could write a naive virtual-dom or string template implementation and it would still be the DOM operations that would by far take the longest time. So decent frameworks and libs are comparing their small overhead only.

0xADADA9 anni fa

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.

Touche9 anni fa

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

subpixel9 anni fa

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

mnutt9 anni fa

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)

tomdale9 anni fa

This is because we recently added the ability to specify a blueprint as an npm package, and it hasn't made it out of canary channel yet.

If you don't want to install canary Ember CLI, you can always just give it the longer git url:

ember new my-glimmer-app -b https://github.com/glimmerjs/glimmer-blueprint.git

mwpmaybe9 anni fa

This will do the trick:

    yarn global add ember-cli/ember-cli

johnrlive9 anni fa

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

johnrlive9 anni fa

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]"

dandare9 anni fa

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?

Matthias2479 anni fa

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.

cibernox9 anni fa

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.

dbbk9 anni fa

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.

Axsuul9 anni fa

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.

bluepnume9 anni fa

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.

pier259 anni fa

Can anyone compare this to Vue?

chrisabrams9 anni fa

Fast and "light-weight" Ember UI components

ergo149 anni fa

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

aligajani9 anni fa

Oh no, not again..

matthoiland9 anni fa

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.

mhd9 anni fa

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?

bjacobel9 anni fa

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

mhd9 anni fa

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.

deno9 anni fa

Which browser? http://caniuse.com/#search=async%20functions

conradk9 anni fa

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 ?

Touche9 anni fa

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

chancancode9 anni fa

This is _the_ abstraction layer below an existing framework called Ember.js

malindamartin9 anni fa

an essential difference is compiling templates into compact opcodes instead of vanilla JS and effective rerenders

leeoniya9 anni fa

to avoid repeating myself here: https://www.reddit.com/r/javascript/comments/6212ym/glimmerj...