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.

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

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!

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.

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

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.

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 :\

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

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.

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.

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

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.

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

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.

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.

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.

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

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

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.

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

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.

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

I wonder how it'll stack up to React Fiber. I love when libraries compete on performance, since it can end up benefiting everyone.

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

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.

TS already supports JSX.

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!

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

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

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

Works well for us :)

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.

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

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

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.

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.

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

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.

https://github.com/ember-redux/ember-redux

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

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.

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.

"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 :)

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.

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

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

i just can't convince myself "it looks less scary" is worthy of the technical tradeoffs (for me, at the very least).

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.

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

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.

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.

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

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

If you want to contribute.

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

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.

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

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

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

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.

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

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.

(edited for better command)

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

    yarn global add ember-cli/ember-cli

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

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.

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

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.

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

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.

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 ?