Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ember 2019-2020 Roadmap RFC #519

Open
wants to merge 4 commits into
base: master
from

Conversation

@tomdale
Copy link
Member

commented Jul 29, 2019

This RFC sets the Ember 2019-2020 Roadmap. This year, our two priorities are:

  • Further reducing the size and conceptual complexity of the framework.
  • Accelerating ecosystem growth and improving ease of adoption.

Rendered

@amyrlam amyrlam referenced this pull request Jul 29, 2019
7 of 8 tasks complete

Candidates for deprecation or extraction include:

- **Object utilities** such as `isBlank`, `compare`, `trySet`, etc.

This comment has been minimized.

Copy link
@efx

efx Jul 29, 2019

Contributor

Linking to @elwayman02's thoughts here: #516

This comment has been minimized.

Copy link
@elwayman02

elwayman02 Jul 29, 2019

Thanks! I intend to follow this up with an RFC once we've had a bit more discussion to make sure I'm not missing anything.

This comment has been minimized.

Copy link
@efx

efx Jul 30, 2019

Contributor

Linking as well to @snewcomer's older, similar proposal: #334

@Gaurav0

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

To point out the elephant in the room, there is no mention of another edition or of Ember 4.0

@rwjblue

This comment has been minimized.

Copy link
Member

commented Jul 29, 2019

there is no mention of another edition or of Ember 4.0

Indeed, I do not believe that is a mistake. If we happen to do 4.0 in this cycle, I personally would be fine with it but doign a major bump itself isn't an objective of ours.

RE: Editions, I don't think we ever expected to have an Edition per year or on any specific cadence. Editions are a tool to allow us to have a coherence point across the ecosystem after having a number of divergent features, this roadmap doesn't really include features that are incoherent and therefore doesn't benefit from an edition.

@MelSumner

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

To point out the elephant in the room, there is no mention of another edition or of Ember 4.0

Another edition so quickly after Octane would, I think, be equal parts defeating the point of an edition and monumentally exhausting. It's taken a ton of work from so many people just to see the Octane finish line.

@elwayman02

This comment has been minimized.

Copy link

commented Jul 29, 2019

Thirding Melanie & Rob's thoughts - I think we'd achieve "Edition Fatigue" within the community very quickly if we started churning out editions every time we shipped the last one, just for the sake of having an edition. Octane was needed because there were so many initiatives coming together to really change how we thought about and worked with Ember, so it was necessary from a messaging standpoint to wrap it up into an Edition bow. Not every major initiative needs to be tied in like this, and there should be a marketing purpose for the community when we decide to create an edition imo.

@MelSumner

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

Engage with standards bodies to help fill the gaps in existing web accessibility APIs.

I'm really excited about this one. I think we have a good idea of the things we need from A11y APIs and it will be great to bring useful things to the entire universe of web development.

@barelyknown

This comment has been minimized.

Copy link

commented Jul 30, 2019

Before I mention what I think is missing, there's a lot that's great:

  1. Reduced Ember surface area
  2. Further integration with the broader JS ecosystem
  3. Build system enhancements for optimized performance
  4. Accessibility-friendly defaults
  5. Clear communication and a great experience for all developers

But... I miss the focus on ambitious web applications.

All the attention paid to making the onramp to Ember more friendly and modern is important, and I'm for it! But, the best that Ember can ever do in those areas is be good enough; there will always be simpler frameworks that are easier to get started with. We need a steady stream of new entrants into our community to prevent us from shriveling away, and we need to aim higher, not lower to stay vibrant.

Specifically, the types of goals that would feel ambitious to me are:

  1. 🏆 A more robust vision for ember-data (probably built on Orbit.js) to enable optimistic UI patterns, connection durability, client-first development, undo/redo support, etc
  2. Enhanced hybrid app story, with more first class support for and documentation related to corber.io
  3. Formal embrace of ember-animated in guides, documentation, and marketing to push motion as a first class concern
  4. Maintained focus on FastBoot and the ambitious strategies that it enables (e.g. static first)

I ❤️ Ember, and I'm happy everyday that we bet our company on it. I just fear stagnation, especially in pursuit of goals that are unattainable. Plus, I feel like I've seen the 🌟 future 🌟 with Orbit.js, and so maybe I'm just wishing for a more perfect union.

@tleperou

This comment has been minimized.

Copy link

commented Jul 30, 2019

That sounds great.

Optimize for growth sounds a key here, specially to get more contributors.

@barelyknown you have a good point

Maintained focus on FastBoot and the ambitious strategies that it enables (e.g. static first)

The static first class is an important element of the Optimize for growth. To reach the new generation of server side rendering web sites' developers, we have to get rid of the (arguable) significant learning curve.

Like @MelSumner, I feel really excited about the Better a11y by default. There are plenty of - required - improvements on the Web. And plenty of room for Ember to provide great solutions.

@willviles

This comment has been minimized.

Copy link

commented Jul 30, 2019

@barelyknown I’d argue that your goals 2, 3 & 4 are solved by ‘clear communication’, as are a lot of concerns around increasing adoption of the framework and accelerating growth.

My colleagues at work (React & Angular developers) are very interested to learn Ember after I personally walked them through some Octane features, but are at a total loss as to how to start their own personal learning of modern Ember.

I think the learning team do an amazing job for keeping those already invested in the framework in the loop. However, the longer Ember goes without a well rationalized and designed marketing & docs site, the longer the framework will stagnate.

Far from doubting the ability of anyone in the Ember community, I’m generally sceptical whether open source contributions alone can produce and maintain marketing & docs in a timely and satisfactory manner. Even after reducing the surface area of the Ember API, it is simply a mammoth undertaking to communicate all the intricacies of this framework.

Whilst Angular and React have full time Google and Facebook teams working on documentation & marketing, Ember’s best learning tools are the fruits of the full time focus of the awesome guys at EmberMap. Unfortunately most of the essential resources are behind a paywall.

My colleague said to me after getting increasingly frustrated with trying to learn modern Ember from a handful of blog posts and merged RFCs, “Why don’t LinkedIn just hire some people to sort this out?” I gave him the stock, “Ember’s an open source community” response, but essentially I agreed.

I’d be interested to know what the core & learning teams think about pitching for funding from the framework’s most invested companies, in order to engage a full time team to be the mouthpiece of modern Ember.

  • Is it too against the core principles of the framework?
  • Would people agree that growth could be significantly accelerated by having a full time Ember team?
  • Would people agree that the Ember marketing & docs may be of better quality if a full time team were working on it?
  • Or does everyone believe Ember can be communicated to it’s best capabilities through open source contributions alone?
@tleperou

This comment has been minimized.

Copy link

commented Jul 30, 2019

@willviles, you've just brought it into focus. Personally, I share your point of view.

Let me know if I am wrong, but none of Emberistas, particularly core members, expect Ember to become the mainstream. However, more adoption means more potential contributions.

The Website of EmberJS - or an official commercial representative of the Ember Open Source community - should engage a stronger marketing approach to reach the real potential of Ember. Would sponsors be enough for supporting a fulltime team? 🤔

@mehulkar

This comment has been minimized.

Copy link

commented Jul 30, 2019

This is great! I’m looking forward to the marketing / branding push, as well as the focus on router/controllers and the default Octane blueprint.

One additional thing that I REALLY want to see is more on SSR. I see mentions of fastboot here and there (e.g. modifiers), but I think it’s time to make it a first class concern as well. @tomdale said in a recent talk that Ember for the next 10 years is about making web apps for the world, and I think web perf (which includes Fastboot and other SSR techniques) can/should play a role in that goal.

@pzuraq

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2019

@barelyknown I definitely agree that Ember needs to continue to be ambitious in the future if we're going to stand out and gain interest from the larger community. I also agree with all of the potential features you've listed, though I would like to say that the Ember Data team has been quietly iterating toward a newer, much more well rationalized future for Data that I'm personally really excited about (there have been several merged RFCs recently you can check out for more details!)

The thing is, the goal in slimming down the framework isn't just about chasing the same targets as other frameworks. Yes, we want to get smaller in part because it's important for performance, etc. However, it's also important from a maintenance perspective.

There are many bugs and loads of overhead that come with having to support the legacy object model, the utility methods, CPs and CP macros, observers, event listeners, etc. It's also a major time sink for documentation efforts, and it causes confusion in the ecosystem to have two ways of doing things. The build side of things has a similar issue - we're maintaining our entire build pipeline currently, one that grew organically over time and has quite a few pain points and issues. It's served us well over the years, but now it's more of a drag on our ecosystem than a benefit.

Embroider, template imports, and slimming down the framework are, to me, just as much about freeing up our plates and getting time back as they are about simplifying the framework and making it smaller, physically. I definitely want to get back to building new, ambitious features, and I'm confident that by this time next year that's exactly what we'll be planning for 😄 personally, I'd like to take the time in the post-Octane period to cleanup as much debt as possible, to prepare ourselves for that. I think this roadmap sets us up to be successful in that regard.

One final note: I do think that we've shipped some pretty ambitious features in Octane. In particular, tracked properties are a game changer, and I still haven't found much that's similar in other ecosystems. We definitely can do more, but I think we should also recognize what we've accomplished as a community, and also take a bit of a breather (and clean up some legacy debt!)

@barelyknown

This comment has been minimized.

Copy link

commented Jul 30, 2019

@pzuraq Yes, I totally agree that the features bundled up in Octane are excellent and exciting. 💯

I also totally agree that slimming things down in the wake of Octane is smart, and will free up valuable time and attention to push things forward. 💯

As it relates to Ember Data, I agree that there has been huge progress made over the years. Our company has built excellent features that heavily depend on Ember Data, and as it has improved, our app has improved. But... I don’t think that I agree that Ember Data represents an ambitious enough future (at least not as I understand it). I put the 🏆 in my comment above, because this is really the punchline to me. When I look at what’s possible with Orbit.js (and make smaller apps to explore those possibilities), it’s so far beyond what Ember Data is trying to do that it makes me wonder if we’re shooting too low.

I’ve tried to be careful to strike the right tone with my comments. I’m tremendously grateful to the community for what its built. That said, this is a roadmap RFC, and so it seems the time to bring these types of points up.

@elwayman02

This comment has been minimized.

Copy link

commented Jul 30, 2019

I would suggest that diving into the details of Orbit vs M3 vs whatever for the future of Ember-Data is a good topic for an issue thread on the E-D repo. I think you're both in agreement that E-D should be more ambitious in the future than it has been historically, and the only disagreement is whether the current direction is that. In order for you both to understand what the other is talking about would require going into a lot more detail than is necessary for this RFC. It's an important discussion, however, so I hope that it continues!

@MelSumner

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2019

That said, this is a roadmap RFC, and so it seems the time to bring these types of points up.

@barelyknown yes, definitely!! I also think it could be something that we explore and "unofficially" work on, maybe even submit CFP to talk at conferences about- it's good to have future-looking ideas and keep ourselves moving forward.

All the attention paid to making the onramp to Ember more friendly and modern is important, and I'm for it! But, the best that Ember can ever do in those areas is be good enough; there will always be simpler frameworks that are easier to get started with. We need a steady stream of new entrants into our community to prevent us from shriveling away, and we need to aim higher, not lower to stay vibrant.

I am 100% in agreement with this, so so much.

- **Computed property macros** such as `alias`, `mapBy`, `notEmpty`, etc.
- **Legacy object model features** such as observers, `setProperties`, `incrementProperty`, etc.

Perhaps the longest-awaited simplification is **eliminating controllers** from the Ember programming model, which we will do this year. This will require us to find a new home for query parameters.

This comment has been minimized.

Copy link
@mckennagalvin

mckennagalvin Jul 30, 2019

Wondering if dynamic query params is something that could be explored as part of these changes!

This comment has been minimized.

Copy link
@mehulkar

mehulkar Aug 3, 2019

Dynamic route segments also! e.g. handling both foo.com/posts/:seo/:id and foo.com/posts/:id with the same route handler.

@tschoartschi

This comment has been minimized.

Copy link

commented Jul 31, 2019

I really like the roadmap RFC 🙂thanks for putting it together. I also read a lot of #EmberJS2019 blog posts and I think the RFC summarizes it very well.

🏃‍♀Accelerating ecosystem growth

I want to mention three things concerning the "Accelerating ecosystem growth" goal:

🧳Ember-Data

We started a new Ember.js project this year in March. Our team consisted of people with no background of Ember.js, some had experience in React and Angular and some come from Android development. Despite Ember-Data is a great piece of software it was one of the main pain points for our newcomers (we do not use controllers, we just create top-level components, so we had no problems in this space).

The problem for them was often to distinguish were Ember.js ends and where Ember-Data starts. Also, it was hard for them to grasp what's the role of Ember-Data in the Ember-Ecosystem. I often got questions like: "Is Ember-Data the Redux of Ember" etc. These problems with the mental model made it really hard for them to feel comfortable.

Furthermore, the part of the guides speaking about Ember-Data is very small. This is bad because Ember-Data does a lot and after reading the guides it does not seem like it. Another pain point was that there are a lot of issues (from March until now, we had to work around many things). Relations are very tricky and better guides about this topic would improve onboarding a lot.

We use the DS.RESTSerializer and we encountered some rough edges especially with links within the payload.

I know this is a roadmap RFC for Ember.js but since Ember-Data comes as default with ember init I think the Ember-Data experience should be as great as the Ember.js one. I'm sure 90% of the problems can be fixed with more and better guides, examples and "recipes".

👩🏼‍🔬 Innovations

With Octane we modernized the look & feel for developers a lot. DX improved drastically. Ember feels now like a thin layer above regular JavaScript. Octane also laid out the ground for new innovations and I think we need to show off some innovations other frameworks do not have. I think on things like, binary templates, render engine as WASM. Personally, I would also love to see an integration of css-blocks.

💪 Types and TypeScript

For our newest Ember.js project we use TypeScript and it works very well. Especially for our newcomers, the features TypeScript provides helped them a lot to improve their understanding of the framework and helped them get up to speed quickly. But across the ecosystem, we miss a lot of Types. Therefore I believe that improving the typeing story should be an ecosystem goal where all the addon-authors, core-team-member and Ember.js users work together. It should be easy to contribute type-definitions. Furthermore, it would be great to see things like typed templates happening.

💡Other thoughts

Since we are Glimmer.js users we would like to have a statement what the role of Glimmer.js will be in the Ember ecosystem in 2019. This is very important for us, especially because new projects are around the corner and these projects will need something like Glimmer.js. Without knowing anything about the plans it's hard for us to argue why we are not using things like (P)React or Vue.

Last year we had a section about the none-goals. I think it would be good to have such a section again so that everybody has an objective view on what will happen and whatnot.

@pzuraq

This comment has been minimized.

Copy link
Contributor

commented Jul 31, 2019

@barelyknown

But... I don’t think that I agree that Ember Data represents an ambitious enough future (at least not as I understand it)

I think you may be pleasantly surprised. The data team's plans are quite ambitious, as far as I understand them, though these things do take time, and there's a lot of work to be done still, so I'm not sure everything will be landing in this year's roadmap. I actually expect 2020-2021 to be a big year for Ember Data 😄

@tschoartschi

The problem for them was often to distinguish were Ember.js ends and where Ember-Data starts.

This is actually a pretty big part of the reason why it's taking a while to ship things in Data, there's a lot of debt, and it's tied pretty deeply to Ember's own implementation details. Separating the two out is a huge part of moving forward, with larger refactors to follow.

@bfitch

This comment has been minimized.

Copy link

commented Aug 2, 2019

@MelSumner @barelyknown

All the attention paid to making the onramp to Ember more friendly and modern is important, and I'm for it! But, the best that Ember can ever do in those areas is be good enough; there will always be simpler frameworks that are easier to get started with. We need a steady stream of new entrants into our community to prevent us from shriveling away, and we need to aim higher, not lower to stay vibrant.

I am 100% in agreement with this, so so much.

This assumes that Ember's current learning curve/complexity is inherent or unavoidable to the problem space, but as this RFC shows, it's really not! Controllers, the build pipeline, ember-data, and the Ember object model are all being replaced with conceptually simpler and more powerful alternatives.

I love Octane and this RFC specifically because they're all about honing in on and removing those vestiges of accidental complexity that have accreted over Ember's long history. The Octane programming model is as clear and rationalized as any other framework out there at the moment. Combined with Embroider and better JS ecosystem integration, we have no reason to settle for Ember simply being "good enough" here.

There's no zero-sum game between (1) simplifying Ember and (2) tackling ambitious new features, in fact, they go together and reinforce one another. Pruning and simplifying APIs and the programming model means: smaller learning curve, less maintenance burden, easier communication, and more time for ambitious features! Win win.

@dgeb

This comment has been minimized.

Copy link
Member

commented Aug 2, 2019

As both the creator of Orbit.js and a member of the Ember Data team, I'd like to echo what @pzuraq has said about the ambitious plans for Ember Data. I've been working for a very long time to bring the benefits of Orbit to Ember Data. This has involved working with the rest of the team on refactoring and slimming down internals, as well as defining new public interfaces within Ember Data. My goal all along has been to be able to "plug" Orbit into the new interfaces being defined within Ember Data, which should unlock quite a few of Orbit's capabilities seemingly "for free" (well, to the developer, anyway). I outlined this vision in my EmberConf 2018 talk.

It's fair to say that we (the Ember Data team) haven't been heavily selling this ambitious future. We've talked a lot about the process to date, without focusing as much on the potential benefits. Part of the reason is that we still have a little ways to go and want to see everything working well together before making any pronouncements. Another reason is that Orbit compatibility isn't our singular goal. On the other end of the spectrum, we want Ember Data to support simple use cases, such as a basic repository for fetch results. We also want to support libraries, like ember-m3, that take a different view of data normalization. Ember Data will soon be a leaner, more flexible, and more "pluggable" library than it is today. It will be a "big tent" that supports a wide spectrum of use cases.

Last but not least, I'm really energized by the enthusiasm for Orbit and its ambitious goals shown by @barelyknown and others. At times, working on Orbit has felt like a walk in the desert, but it's gratifying to see a lot of work come to fruition for my projects as well as for others. I suppose we shouldn't dive too deep in this discussion thread, but if you are curious about Orbit and/or ember-orbit, please feel free to reach out to me in the #topic-data-management channel in discord or in Orbit's gitter channel. And if you want to reach out to help accelerate the work to bridge these two worlds, reach out in #dev-ember-data on discord.

@@ -0,0 +1,88 @@
- Start Date: 2019-07-29
- Relevant Team(s): All teams
- RFC PR: (after opening the RFC PR, update this with a link to it and update the file name)

This comment has been minimized.

Copy link
@elwayman02

elwayman02 Aug 2, 2019

Reminder to add the link here! 🙏


Perhaps the longest-awaited simplification is **eliminating controllers** from the Ember programming model, which we will do this year. This will require us to find a new home for query parameters.

Building on the simplicity of Glimmer components, we’ll also implement **template imports**, which make it explicit which helper or component is being invoked, and **named blocks**, which make it even easier to build ergonomic, reusable components.

This comment has been minimized.

Copy link
@elwayman02

elwayman02 Aug 2, 2019

Where they exist, can we link to the RFCs for features like template imports throughout this document? I imagine that people will find it very useful to know what has already been planned, particularly if they are not already aware what these terms mean in a practical sense. That will help people reviewing the RFC better understand how the planned direction will manifest!


There are more people building web applications than ever, and Ember must adapt to their changing needs and expectations in order to stay relevant.

This year, **we’ll share with the world how Ember Octane is modern, productive, and _fun_.** Through blog posts, videos, social media, meetups, and conferences, we will share our knowledge and experiences with the wider JavaScript community and encourage them to give Octane a try.

This comment has been minimized.

Copy link
@elwayman02

elwayman02 Aug 2, 2019

This, to me, is one of the most important pieces of this roadmap, and I hope people do not gloss over it. I can't remember the last time I attended a conference/meetup that was not specifically focused on Ember and saw someone giving a talk about Ember. We need to make a concerted effort at outreach, and I hope that someone will be writing a follow-up RFC detailing exactly how we will accomplish this rather than simply jumping straight from this roadmap into "executing" at this broad-stroke level.

@unibum

This comment has been minimized.

Copy link

commented Aug 4, 2019

Disclaimer, I’m not a coder/developer and being following Ember pre 1.0.

Has anyone considered an Ember Infrastructure team to attract more developers (and start-ups)? Through the lens of a cash strapped start-up as an example, I don’t really want my self-taught javascript/front end guy deploying and configuring any other software in any environment let alone my production webserver, Db and every other system needed in-between. Ember has a number of great things that I simply wouldn’t want or trust a front-end guy to do, simply because security and scalability are hard problems. Would be nice if e.g. LinkedIn or a hosting company sponsor this by providing a number of open source scalable software in say containers/Kubernetes or whatever that will just work with Ember (SSR as an example, or deploying to only a subgroup - hand picked production users/early adopters, or deploy to one server/region to ensure nothing has broken before deploying out to everyone else, automatic rollbacks, etc.) and can easily be turned on and just works.
A start-up with a maxed-out credit card may not be thinking this far ahead, but if Ember offered this out of the box it may persuade new developers and/or start-ups to use Ember over something else if they can easily install a pre-configured secure production scalable solution (most just want HA but dream they’ll one day need scalable). I only mention LinkedIn because they have open sourced a number of software (assume ember compatible) and probably have the largest Ember team and are best placed to provide / sponsor and make available pre-integrated production Ember solutions/ecosystem that can be trusted to work.

Also, as someone who doesn’t live in the USA or a large country for that matter, mobile is the biggest consideration when choosing a language along with access to good developers, so React wins hands down here… you cannot even find an Ember or Vue dev here because of the demand for mobile which in turn drives people to learn React. I cannot stress enough the importance of a hybrid/native solution/option is needed ASAP! Great to see Chad do a PoC for NativeScript etc but seems to have gone quiet. Would also nice to see first class support for CSS Blocks, as I fair that may die off which would be a shame, as it seems quite quiet there and when people are even volunteering to fix performance/fundamental design problem (Parallelization #184), I don’t see anyone telling them to go for it...

Lastly, perhaps Ember 2020, after sorting out mobile native, could target other devices/platforms like Tv Browsers and apps (thinking Panasonic here have a lot of apps), Xbox, VR devices etc. Lots of potential users and potential paying customers are on these other platforms. A point of difference Ember could offer.

You would have quite a compelling story quite quickly for start-ups in my view.
I think the above can essentially tie into the developer focus of the RFC so hopefully it may at least start a conversation for considering other perspectives like StartUps and what could bring them onboard which in turn can drive more developer adoption of Ember.

@pzuraq

This comment has been minimized.

Copy link
Contributor

commented Aug 4, 2019

I cannot stress enough the importance of a hybrid/native solution/option is needed ASAP! Great to see Chad do a PoC for NativeScript etc but seems to have gone quiet.

While it's not officially supported by the Ember core team, a community solution has been being worked for this actually! I've been helping out @bakerac4 when possible with Glimmer Native, and am excited to see where it goes too 😄

@unibum

This comment has been minimized.

Copy link

commented Aug 4, 2019

While it's not officially supported by the Ember core team, a community solution has been being worked for this actually! I've been helping out @bakerac4 when possible with Glimmer Native, and am excited to see where it goes too 😄

I hope that Ember can pick up and officially support as anything that is done by a single person and not supported in core kind of scares me. I hope others get behind what @bakerac4 (and CSS Blocks) is doing.

@rajasegar

This comment has been minimized.

Copy link

commented Aug 5, 2019

I am just trying to mind map the roadmap for my understanding.
ember-2019-2020-roadmap

@roomle-build

This comment has been minimized.

Copy link

commented Aug 5, 2019

We use Ember.js a lot and also since pre 1.0. We love the productivity Ember gives us and also how it helped us to grow as a team and together with the framework. I think 2019 and 2020 will be a challenging but important time for the Ember ecosystem. Especially because many new frameworks borrow heavily on Embers ideas without the need for carrying the whole legacy baggage. For example vue-cli is doing a great job. Therefore it is important to get this RFC right and bundle our forces to improve the most crucial issues.

I really like the high-level goals of the RFC but to create momentum within the community we should create measurable action items. Maybe in sub-RFCs or "tracking-issues" (whatever fits best).

I want to rever to some things already mentioned in this RFC. I think they are important and not covered well enough by the existing draft of the RFC.

👩🏼‍🔬 Innovations
... I think on things like, binary templates, render engine as WASM. Personally, I would also love to see an integration of css-blocks ...

When we started with Ember it was at the forefront of frontend tools. Ember cli, ES6 modules etc. Right now it seems we are lagging behind and all our efforts only bring Ember on a similar level as all the others (not ahead of them). Therefore it would be awesome to see initiatives happening in the innovation field. I think a lot is already 80% finished. Would be great to get them to 100%.

💪 Types and TypeScript
... Therefore I believe that improving the typeing story should be an ecosystem goal where all the addon-authors, core-team-member and Ember.js users work together. It should be easy to contribute type-definitions. Furthermore, it would be great to see things like typed templates happening ...

Since Ember sees itself as a framework for ambitious web apps I think it's essential that TypeScript becomes a first-class citizen. The work @chriskrycho and the ember-cli-typescript team is doing is just amazing and I think they deserve a mention in the RFC and should get even broader support of the community. I would also love to see type-definitions as a part of EmberObserver score.

Would also nice to see first class support for CSS Blocks, as I fair that may die off which would be a shame, as it seems quite quiet there

I hope that Ember can pick up and officially support as anything that is done by a single person and not supported in core kind of scares me. I hope others get behind what @bakerac4

The Ember community started a lot of great efforts like the two described above. But often it seems that these things slowly die off after some time. I think this is mostly a management problem. It's true what @unibum mentioned, if only one person is doing something it's very likely that the project won't be continued after some time. This is not because these persons are lazy but life situations change and therefore priorities. This is totally ok but it's a pity for the eco-system if such great initiatives just fade away if only a single person leaves the project.

This could lead to the impression for people outside of the eco-system that Ember just does not finish/continue their innovations . I look at you Glimmer.js, binary templates etc.

Maybe it would be good to add last years topic "finish what we started" again.

Update text/000-2018-2019-roadmap.md
Co-Authored-By: Chris Krycho <hello@chriskrycho.com>
Candidates for deprecation or extraction include:

- **Object utilities** such as `isBlank`, `compare`, `trySet`, etc.
- **String utilities** such as `camelize` and `dasherize`.
text/000-2018-2019-roadmap.md Outdated Show resolved Hide resolved
@chriskrycho

This comment has been minimized.

Copy link
Contributor

commented Aug 5, 2019

Since Ember sees itself as a framework for ambitious web apps I think it's essential that TypeScript becomes a first-class citizen. The work @chriskrycho and the ember-cli-typescript team is doing is just amazing and I think they deserve a mention in the RFC and should get even broader support of the community. I would also love to see type-definitions as a part of EmberObserver score.

First, thanks for the kind words!

Second, although I suggested that we do just this in one of my own #EmberJS2019 blog posts, I've changed my mind over the past few months—because as I've dug further into some of the problem space ahead, I actually don't think we're ready for this yet.

You should keep your eyes on the issue tracker for ember-cli-typescript, where I hope to be posting a public roadmap in the next few weeks, but the short version is: we need to do a lot of work to stabilize the ecosystem (including developing a story for safe semantic versioning around types and TypeScript compiler versions to mesh with Ember's semver story) before we can make a recommendation at the ecosystem level. I and others will be working actively in that direction over the next many months, but at present my hope is that over the next year we can get things to where this is part of #EmberJS2020.

In the meantime, the core efforts that are outlined here—simplifying and modernizing the build tooling, simplifying the mental model by reducing the number of concepts, and so on—are actually really helpful pieces of the puzzle for a future where TS is a first-class citizen of the Ember ecosystem.


I will add two other bits that I think this roadmap should include:

  • a commitment to remove EmberObject from of the framework entirely. Doing so is one of the single largest performance wins we can ship, both in terms of the overhead of the legacy class system in runtime lookup work and in terms of payload size. New apps starting out this time in 2020 simply shouldn't be paying for it at all. Given the other commitments, that means getting Route and Service to use native classes instead of EmberObject for their base classes. EmberObject has served us well, but its time has passed, and this is the year we should drop it.

  • svelte builds or more regular major releases. I don't intend to litigate which is the right course in this RFC, but a roughly 2-year-long cadence for major releases necessitates svelte actually shipping, while more regular major releases would decrease the need for svelte builds by making it so deprecated code just doesn't hang around as long. We need to sort this out as a community.

@jenweber

This comment has been minimized.

Copy link
Contributor

commented Aug 5, 2019

My colleague said to me after getting increasingly frustrated with trying to learn modern Ember from a handful of blog posts and merged RFCs, “Why don’t LinkedIn just hire some people to sort this out?” I gave him the stock, “Ember’s an open source community” response, but essentially I agreed.

@willviles if you and your colleagues are trying to learn Octane-style features, please share the Octane preview guides with them. They are still WIP, until Octane is released, but are still helpful in the interim since most features are already available in stable releases.

@pzuraq

This comment has been minimized.

Copy link
Contributor

commented Aug 5, 2019

I hope that Ember can pick up and officially support as anything that is done by a single person and not supported in core kind of scares me. I hope others get behind what @bakerac4 (and CSS Blocks) is doing.

The Ember community started a lot of great efforts like the two described above. But often it seems that these things slowly die off after some time. I think this is mostly a management problem. It's true what @unibum mentioned, if only one person is doing something it's very likely that the project won't be continued after some time. This is not because these persons are lazy but life situations change and therefore priorities. This is totally ok but it's a pity for the eco-system if such great initiatives just fade away if only a single person leaves the project.

I definitely think this is true, and this is actually a major part of the reason that the core team is hesitant to overcommit itself at the moment. Historically, we've had lots of great ideas, and not enough contributors to implement them all. I know @rwjblue merges like a million PRs a day, but we only have one of him 😛

We would instead like to see ambitious projects like Glimmer Native grow organically in the community (with core team support) before we commit to maintaining and fully supporting them directly. A great example of what we mean here is the way that Typescript support has grown in Ember. The core team has been very excited about Typescript since it was released (Large parts of Glimmer and Ember are actually now written in TS!), but we also realized we didn't have the time or resourcing to make it a first class citizen with features like template-typing, etc, ourselves. In fact, we had high priority work to do (native classes + decorators) that was required to make TS even viable in the framework.

However, community members like @dfreeman, @chriskrycho, and @jamescdavis all stepped up and started working on ember-cli-typescript, and many other contributors have joined their ranks. The core team regularly consults with them to make sure we're building things in a way that is type-able, and future proof for TS, and we're getting close to being able to have a typed template solution and other great features. This also means we have a pool of talented contributors who can join the one of the core teams (or create a new Typed Ember team, as some blog post roadmaps have suggested) when the time comes, so we can actually grow the core team as we add official support for new features, making it easier to maintain rather than adding to the maintenance burden.

Developing it this way also allowed the community to show us that (as we already thought) there is demand for Typescript + Ember, without us investing a large amount of developer hours into the features. While I personally think there would be similar demand for Glimmer Native, there is totally legitimate concern that we would be investing a large amount of time and effort, and in the end there would only be a few users and it would not actually be as valuable as other initiatives (like better Fastboot, typed templates, etc.)

I feel like this discussion is getting more and more off topic, so this will be my last post on the roadmap about this (happy to keep discussing on Discord or elsewhere!), but in the end I want to make it clear that the core team whole heartedly supports initiatives like Glimmer Native, and will try to give time and effort when possible to help them grow. Every core team member has their commitments to the framework and there are only so many of us, but we also realize this is a great way to grow the framework, the community, and ultimately the core team(s)! That's why I've personally been taking time to help @bakerac4 in between my work on Octane, and will continue to do so 😄

TL;DR: A healthy Ember ecosystem consists of many more projects than just those led by the core team members. If Ember is to grow, then we have to do open source really well - anyone can participate, anyone can lead, and the core teams do their best to provide mentorship and guidance to help projects like these succeed.

@frank06

This comment has been minimized.

Copy link

commented Aug 8, 2019

I agree with @willviles here... COMMUNICATION! Having a big company fund part of the marketing efforts is a fantastic idea – as long as it doesn't affect Ember's great open source governance model.

"Optimize for growth" has been stated as a priority but... below "a11y improvements"? It should be BY FAR the first priority.

Maybe I say this because I am happy and at ease with all the technical efforts gone into Octane (in the same way that I trust the devs spearheading the new work on Ember Data). So yes, I feel a lot has been done in the direction of simplifying and modernizing the framework. But marketing efforts pale in comparison. I just checked emberjs.com and that dreadful and outdated site is still up.

In the community things are happening. EmberMap keeps being a top notch resource. @pzuraq 's articles on Octane are simply excellent. And personally I went on a journey to update most of Ember Igniter to Octane.

But we need the official site to be way more appealing to developers (new ones, or old ones who have been disappointed), definitiely with "a way to give developers a preview of Ember’s productivity, even if they’re not ready to jump in feet first".

@shankarsridhar

This comment has been minimized.

Copy link

commented Aug 12, 2019

@tomdale The rendered link to the RFC, in the original comment gives me a 404. Am I missing something ? 🤔

@rajasegar

This comment has been minimized.

Copy link

commented Aug 12, 2019

@shankarsridhar The link got changed due to the rename including RFC number. This is the new one
Rendered
@tomdale I think you need to update the new link in the comment

@joukevandermaas

This comment has been minimized.

Copy link

commented Aug 12, 2019

I'm confused as I'm missing some of the sections that are usually found in RFCs, specifically:

  1. How do we teach this
  2. Alternative designs

Could someone explain why these are missing?

@hjdivad

This comment has been minimized.

Copy link
Member

commented Aug 12, 2019

@shankarsridhar @rajasegar thanks for pointing this out. The link in the description is now updated.

@jenweber

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

@joukevandermaas RFCs usually have those sections. For long-term planning RFCs like this one or last year's roadmap, the "how we teach this" and "alternative designs" are not included. Instead, those sections will be covered in smaller, more feature-specific RFCs. For example, one goal last year was to use Native JavaScript classes, but the "how we teach this" goes in the RFC that is about that feature specifically.

@joukevandermaas

This comment has been minimized.

Copy link

commented Aug 13, 2019

@jenweber thanks for the reply.

I'm confused because I think it is still a challenge to teach the community about the roadmap itself. I know from experience many Ember devs are not aware of long term goals of the project.

For alternative designs I was just curious what else was considered but dropped, and why.

Anyway thanks for explaining why these sections are omitted in this case.

@jenweber

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

@joukevandermaas it’s definitely a challenge to get the word out. Overall I think there were about 30 different possible areas of focus proposed for the roadmap - too many to describe one by one here. Although we can only choose a few priorities for the Roadmap, many people will continue working on these other areas, and are encouraged to do so!

You can read more about the Roadmap process here: call for posts. I also recommend sharing the Ember Times with anyone who feels out of the loop. It's a lot to keep up with, so hopefully this Roadmap RFC is a good place where people can quickly review the plans. Thanks for reading this RFC and participating!

@jenweber

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

One more thing, I think after the RFC is merged, we do still have work to do to circulate it. If you have ideas of places to share besides the Times, Twitter, and Reddit, please get in touch on the Ember Discord Learning channel. I think I understand now why you were concerned that the "How we teach this" was missing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.