I have an app that has a dependency on a few bigger libraries and ember addons. From those dependencies, I use a very small subset of functions and components so I was surprised that in the final output is everything. I would like to stripp off everything that's not used.
Looking over the internet, I wasn't able to find any useful resource about this topic. What's the recommended setup for dead code elimination or tree shaking for Ember app in 2017?
PS: I know that Tree shaking is a bit different than dead code elimination, but the purpose is basically the same.
At the moment there is not an easy way to do so if the addon you use doesn't help with it. The Ember-CLI folks are working on making it easy to swap in any bundle step you want (to experiment with Webpack, Rollup, etc), but at the moment Ember-CLI does a fairly simplistic concatenation/minification.
More information about the work in progress can be found here: https://github.com/ember-cli/rfcs/pull/110
Related
In the context of a TS monorepo, VS Code appears unable to track call hierarchies across libraries. I haven't been able to find a solution in repos based on yarn workspaces nor Nx.
I'm currently working with a micro frontend architecture; because components tend to straddle multiple libs, a typical call hierarchy trace gets maybe one component up, if that.
I have no issues with any of the standard cross-lib IDE features - auto import / code completion / inspection / yadda.
Is there a configuration setting I'm missing, or is cross-lib call hierarchies just beyond what's supported?
--
Update 11/09/22 - Still no luck on finding an answer to this. VS Code's docs have limited details on the call hierarchy feature. Perhaps I'll explore the feature API and see if there's any hints.
There is a medium-sized application written in Vue 2.7 (vuex, vue-router, etc.).
Until a certain point, we had SSR "with our own hands." Works crookedly and slowly, but works.
Recently, it has ceased to satisfy the needs of the project and we realized that we would be migrating to Nuxt.
Relatively recently, Nuxt 3 was released. It is now in rc state. We are betting on the further development of Nuxt. Therefore, we want to migrate to version 3. In addition, I think that in the near future we will consider switching to TypeScript, and in Nuxt 3 TS support is at a good level.
But there is an ambiguity: Nuxt 3 works with Vue 3. Also, it is recommended to use pinia instead of Vuex.
In this regard, questions:
Will most components work on Vue 2 when using Nuxt 3? I also want to move to Vue 3, but for now we want to speed up the process as much as possible. But I don't want to use crutches like "Vue 3 Migration Build" either.
Is Pinia definitively replacing Vuex? I mean, is Vuex going to be obsolete anytime soon?
Maybe there are more pitfalls that you should know BEFORE moving?
I would first off migration from Vue2 to Nuxt2, for the simplest + fastest approach without too many breaking parts. That way, you can at least benefit of some SSR capabilities until your whole migration is done.
Then, as Estus Flask said, the main issue would be the packages themselves (like Vuetify, which are still not fully Vue3 compatible in a stable state).
Also, you can totally migrate to Nuxt3 while keeping most of your components with the Options API (no need to refacto towards Composition API).
Nuxt3 is runnable in production but you may still need to troubleshoot it depending on what you are planning to use. Also, keep in mind that not all the modules are migrated yet, here is the latest roadmap.
So to answer your questions:
depending on how your components are now, you may need to update some of their parts, for further details you can check the migration guide and see if you are anyhow impacted by the changes when going from Vue2 to Vue3. If you want to iterate faster (and in a safer way), migrate to Nuxt2 first (should be quite fast!), then try to move towards Nuxt3
Pinia is better on pretty much all aspects when compared to Vuex. Will it be un-usable in the next 18 months? Probably not. It's still the official recommendation and will be the way to go overall (it's just better overall) but Vuex is still totally usable as of today. More details can be found here
as always, you gonna add a layer on top of Vue so it may impact several things:
depending on the amount of features you are using (Nuxt modules, Nuxt specific modules), some releases may take a bit more time overall to ship to production (using Tailwind with Vue3 was made possible earlier in comparison of Nuxt3)
Nuxt is a meta-framework, so it will bring some amount of complexity to properly understand all the Nuxt2 hooks, the way an isomorphic app works, how to use Vue2 packages, some gotchas etc... This is not coming from Nuxt itself, but more from the SSR part.
Nuxt3 is using Vue3, so you will need to then understand a bit more
how composition API works to get the benefit of using useAsyncData
composables etc... So the same work will be needed there too, hence why
I recommend a transition to Nuxt2 first. Of course, it all depends of
your team and if your members are already at ease with Composition
API
Overall, if you need a production-grade solution for your SSR needs, it will be quite useful to use Nuxt for sure but it will also require a bit of a learning curve.
You will also get quite some DX out of it, so that's a nice bonus!
Also, there is no real competition to Nuxt in Vue's ecosystem so at least, you don't need to fully compare meta-frameworks. AstroJS could be another approach but it goes out from the Vue ecosystem quite a lot overall (you won't benefit of Nuxt's modules/nice features for example) and solves some specific needs.
PS: Nuxt's team is working on the same approach regarding server-only components + heavy improvements regarding the hydration.
I really want to start learning Angular2 but the thing is I don't like the idea of having typescript. I want to do it using pure Javascript. But it seems like there is no proper documentation made for it. Do you have any recommended links where I could start with? 2nd question will be: Is it really worth learning Angular with Javascript since it has no docs for it? Or should I just embrace Typescript?
Or should I just embrace typescript?
Yes.
As a practical matter, you are going to find very few, if any, code examples, gists, tutorials, or blog posts that describe Angular without using TypeScript.
The reason is that 95%, or probably more like 99.9%, of Angular users are using TypeScript. That is because it brings a lot of benefits with very few drawbacks. You should re-examine your reasons for not liking the idea of having TypeScript. Yes, there's a learning curve, but it's also an investment in your future, one that will start paying dividends from day one in the form of improved productivity and code quality.
The only really compelling reason for trying to use Angular from JavaScript is if you want to use some subset of Angular's functionality, such as perhaps DI, from a non-Angular application.
It is possible to develop an application with ES5, ES6 or ES.next (transpiled with Babel). The difference between them and TypeScript is how DI and modularity are implemented. This example shows how it's done. And this document in Angular 2 documentation explains the differences.
JavaScript is currently considered second-class citizen in Angular development.
Almost all learning resources use TypeScript, which is not a problem if a developer knows how this code translates to JavaScript; the conversion involves the removal of types and refactoring DI annotations. If a developer doesn't use Babel for transpilation, he/she should be aware of modern JS features that are supported by TypeScript but not target browsers.
The problem is that JavaScript isn't supported by official Angular CLI tool and Ahead-of-Time compilation. This seriously limits the usage of Angular JavaScript applications in production.
I'm adding another answer here with some real technical points.
It is possible to get something running using JavaScript and not TypeScript. But you will have two major problems which mean you shouldn't do it:
You will need to do a lot of configuration. Here is a good article explaining how it can be done, but you'll have to make some changes to get it working with the latest version of babel and webpack, which is not trivial.
You will never be able to get the production bundles down to a sensible size. This is because you won't be using the angular-cli to do your builds, but will instead be using purely webpack. angular-cli appears to do some intelligent building with webpack and the typescript compiler to output much smaller, production bundles. For this reason alone, it's a non starter. The smallest bundle I've managed to get for a hello world app is over 800kB. The equivalent app built with typescript is about 140kB.
I feel that the angular team should update their documentation to point this out.
Atom and Visual Studio Code are probably the biggest Electron apps so far and they're both quite extensible, and the are other smaller examples like N1. By extensible I mean, they support plug-ins.
The problem is: I thought I would find something on Google on how to make an Electron app extensible, or something on those cool "awesome" lists, but I found nothing. Besides, digging into these apps source-code would take a while.
What I'm looking for (OR):
A built in feature that I'm not aware of
A library like electron-extensible (fake name)
A guideline
So, how do I make an Electron application extensible?
If you're the one writing the app, would be the one to create the layout/conventions used in the plugins.
That being said there are many ways you could do that, one being dynamicly require statements for substitute functionalities.
Coming from an OO background, I would recommend looking into Factory and Conposite design patterns.
Here are some electron resources: https://github.com/sindresorhus/awesome-electron/blob/master/readme.md
I have just been asked to describe the architecture for a large scale dashbaord style project that i will be working on.
I have bever worked on a application of this size and am a bit lost as to what to say.
Could i be pointed in the direction of any articles that may help me get started and hopefully finished.
I have gleaned the following information thus far but i am not really sure that it describes the architecture.
1) Use classes instead of seperate functions and each class or group should be contained within their own JS file
2) Prior to production there should be a compile step where said JS files are compiled and minified
3) Step2 does not have to contain all the files. Jsut the common ones to start
4) Use a classloader to load classes, plugins etc when they are needed. On research could jQuery's getScript function be used for this or even a jQuery plugin loader:
http://api.jquery.com/jQuery.getScript/
http://www.unwrongest.com/projects/lazy/
Am feeling way out of my depth at the mo so any help would be massively appreciated. Be honest, if the above is competely irrelevant then i guess i am in the wrong job :(
Everything you need to know can be found here:
http://addyosmani.com/largescalejavascript/
Create a library of loosely couple components that communicate through an application controller (e.g. event bus).
I would recommend looking at using ExtJS 4 for this. Its APIs and development methodology closely track what you would expect from .NET or Java for developing a large-scale desktop app.
Version four answers all four of your points. It has...
1) A system for defining Java/C#-like classes in Javascript that work almost exactly the way a Java or C# developer would expect.
2) Dynamic resource loading.
3) The ability to create a final product from the SDK which is a neat, compressed version which contains just what you need.
If you are to do this with pure Javascript, ensure you use some reference architecture in the job. What HDave pointed above is really good material. If you want a ready-made reference architecture as a project startup code, have a look at BoilerplateJS:
http://boilerplatejs.org
After some large-scale projects, I have compiled some of the learnings in to this framework. Look at the samples too. Some of the concerns you raised are already addressed in this codebase such as use of OO concepts, minification and optimizations, decoupled moduler design and many more too.