‘Yarn add package’ ‘Import package from “package”’ Without any other ceremony.
-
-
-
yes please.
-
1: I would actually be delighted to see an RFC describing an implementation strategy (and would like to get this done as it's a top request).
-
2: Some questions: - how to deal with browser/module/main/etc entry points (which should win, what should its semantics be) - is it ok for CJS modules to export just a default export with its exports as a data bag?
-
3: - for CJS, what kind of tree shaking is required (or is it ok to pull in the entire package) - how acceptable is it to end up with a lot of package duplicates? Is it tolerable? Would it be important to at least provide a warning? Does yarn --flat work?
-
4: I think people have a sense that we could just do what browserify would have done, which is definitely possible. I'd feel much better about it if someone wrote up an RFC at least exploring these questions.
-
5/5: fwiw, almost the entirety of why wrapper packages are needed in Ember today is because there is no persistent, long-lived defacto standard about these questions. We could live with whatever, I think, if we at least explored the questions and had answers.
-
(I hope this doesn't come off as dismissive or stalling; I'm hoping to unlock some effort by writing down what thorny issues have made this hard to do historically)
- 15 more replies
New conversation -
-
-
I honestly think people don’t use Ember because of React. Faced this problem when I was involved in the Wicket project. You propose the framework and it’s benefits only to be met with “but Forester tells us to use React or Angular”
-
Forester the analyst?
-
Yessir. The gateway to an Enterprise Architect’s heart
(or Gartner) -
I guess it doesn't matter to them that Thoughtworks added Ember to ADOPT on Tech Radar?https://www.thoughtworks.com/radar/languages-and-frameworks/ember-js …
-
That would help! Thanks for the ammo.
End of conversation
New conversation -
-
-
Ember desperately needs a "community package love" czar or something. There are FAR too many "big" packages that are left unattended because the dev left their company and aren't using ember anymore.
-
Ember desperately needs to move away from Ember Data, its got weird side effects everywhere and the file-based configuration is a nightmare.
-
Can you elaborate?
-
Using ember data on write or multiple read workloads is good in the simple case, but quickly becomes useless. And as your app grows in complexity updating models and having things change crossed the app causes bugs.
-
Do you prefer something like redux?
-
Well I like the one directional data flow of redux. I don't love its implementation/word choices. I prefer something akin to the Elm Architecture. (I've built in apps in all three now).
-
Can you summarize what you like about the Elm programming model? (I know elm, I specifically want to know what is appealing
) -
Msg+Data's go out of views, data comes into views. The same high level architecture of Redux.
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.