This content originally appeared on DEV Community and was authored by Lloyd Smith
If you're starting a new project and trying to decide on which frontend framework to use, then this article is for you. Here are my top 7 reasons not to use Ember.js on your next project.
1. You Aren't an Ambitious Web Developer
Ember markets itself as "A framework for ambitious web developers," and let's face it, not everyone is ambitious—or a web developer. Ambitious developers work on ambitious projects, and ambitious projects need infrastructure that Ember just includes out of the box.
Back in 1998, I created my first website, "The Track Shack." It was a site about our high school track team, of which I was a member. I didn’t know how to code back then. I wrote articles using Microsoft Word 97 and used the "Save as Web Page" feature to export them to HTML, which I then uploaded to my Geocities website. One day, my coach asked if I had created a website—apparently, other coaches across the state were using it to get track and field news from our area. I’d even included meet results from The Commercial Appeal (which back then wasn’t online) and added dramatized accounts of our team's events from local meets.
If a simple site like that meets your needs, go right ahead and use Word's "Save as Web Page" feature.
2. You Want to Assemble Your Own Framework
Ember is an opinionated, batteries-included frontend framework. If you'd rather spend your time selecting each library, right down to the patch version, and crafting your own bespoke setup, you’ll be sorely disappointed with Ember.
In Ember, you start a new project by running:
npm install -g ember-cli
ember new my-project
And voilà—a new project is ready to be run with:
npm start
Note that unit tests will already be configured, which brings us to reason number three.
3. You Don't Plan on Writing Any Unit Tests
Ember automatically sets up unit, integration, and acceptance tests and generates stubs in the correct locations any time you use its built-in code generators. For example, if you create a new component with ember generate component big-button, Ember generates the component files and test stubs for it, which you’re supposed to fill out with assertions to test your component.
If you don’t want tests, you’ll end up with stubs that might raise eyebrows in code review, potentially requiring you to actually write tests—or spend extra time deleting the stubs before you submit the pull request. Sure, you can skip test generation with a command line flag, but that’s hard to remember and not recommended.
4. You Hate Native JavaScript
Ember makes heavy use of native JavaScript features, and using libraries like jQuery to manage the DOM is generally frowned upon. For example, here’s how a class-based component might look:
import Component from '@glimmer/component';
export default class DeleteJavaScriptButton extends Component {
handleClick = () => {
fetch(`/api/v1/languages/JavaScript`, {
method: 'DELETE',
}).then(() => console.log('deleted JavaScript'));
}
<template>
<button {{on 'click' this.handleClick}}>Delete JavaScript</button>
</template>
}
If you’re not a fan of native JavaScript, Ember’s definitely not for you.
5. You Hate Separating Templates from JavaScript
In the old days, we built HTML pages with good old JavaScript strings, like this:
var myHtml = '<script>\n' +
document.getElementById('#myInput').value +
'\n</script>';
document.getElementById('#myContent').innerHTML = myHtml;
Template languages eliminate this need, automatically escape dangerous values, and enforce a separation of concerns between logic and presentation (HTML)—which is concerning for some developers.
Another potentially annoying thing about Ember’s template engine is that it automatically updates the HTML in your app when the data changes, which is known as "data binding." If you prefer manually managing the DOM, concatenating strings, or using a different template engine, Ember is not for you.
6. You Hate Updating Dependencies Ever
A core value of the Ember community is "stability without stagnation." The framework is regularly updated in backward-compatible increments, following semantic versioning. Any deprecated functionality triggers a warning in development, telling you when it will be removed and how to update it.
These deprecation messages can create more work if your manager insists on a warning-free build. Updating Ember is generally straightforward, especially if done regularly, but if you’ve ignored updates for years, you’ll have some catching up to do.
7. The Ember Community Uses Discord
If you need help with an Ember project, the community's Discord server, is one of the best places to find it. But if Discord is against your company’s policy (or just not your style), this might be a dealbreaker.
In the Discord server, you will find Ember newbies and framework developers alike, and you can get help, share ideas, and even chat about the future of the project. But beware: these conversations can get interesting—and distracting, which may be why some companies ban Discord.
So, if you prefer AI to real people, Google searches over expert advice, or really hate Discord, save yourself the trouble and skip Ember.js.
Conclusion
And there you have it—my top 7 reasons not to use Ember.js on your next project. If you choose to ignore this advice and dive into Ember anyway, you might just find me lurking in the Discord server. If you have a question and I know the answer, I might try to help—but someone more knowledgeable probably will get to it before I can. So maybe we can just chat about more reasons not to choose Ember for your next project!
This content originally appeared on DEV Community and was authored by Lloyd Smith
Lloyd Smith | Sciencx (2024-10-25T22:37:55+00:00) The Top 7 Reasons You Should NOT Use Ember.js on Your Next Project. Retrieved from https://www.scien.cx/2024/10/25/the-top-7-reasons-you-should-not-use-ember-js-on-your-next-project/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.