We Keep Coding

Migrating to Nuxt 3 from Vue 2?

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.

Introduction in developing Cinnamon Shell Extension (Desklet) in CJS / GJS (Gnome JavaScript)?

I started learning how to write Cinnamon extensions. Well, I try to ... While I managed to write a first simple desklet, I still didn't find a really good and up to date documentation and introduction.
I have the following questions and would be very glad to get some hints:
What is the best / suggested development workflow?
For now, I do:
copy the changed files from my project directory to .local/share/cinnamon/uuid,
open Melange / Looking Glass,
search there for the extension and reload it via right click
switch to the Log tab and check for errors
Compared to vue.js development with automatic hot-reload of changes in the browser, this seems a bit ... well ... time-consuming.
Where do I find an introduction to the available widgets and widget libraries?
I understood that there is Gtk and St and both have JS / GJS / CJS bindings.
The Gnome Dev Docu doesn't mention St. And I read in another answer here that it seems that shell extensions doesn't use Gtk, but rather St instead (and not in addition?).
I didn't find any documentation for CJS at all, but as far as I understood so far, it seems to be quite similar to GJS. Seems that the way desklets and applets are defined is different?
But now, I still would enjoy to have a (at least brief) introduction which widgets are available. While in Gtk there seems to be a whole set of different list-like widgets, I didn't find any list widget in St. And it seems that I can't use Gtk widgets as children of St widgets ...? This St documentation lacks any overview of available widgets and classes and what they can be used for.
Documentation about events
I found that there is the St.Entry widget that can be used for single-line text input. I found somewhere that I can bind functions to key press key release events like this:
this.input.connect('key-release-event', (widget, event) => {
const input = widget.get_text();
// ...
return true; // event has been handled
});
I didn't managed to get some information for the event.
When printing with JSON.stringify(event) It shows an empty object.
This Gtk documentation looks like there should be fields such as keyval and state, but these are undefined.
This is really kind of frustrating when it takes ages for every very small step to understand ... so, I would really appreciate any hints and suggestions!

Firstly I should note I have no idea what's been happening in CJS since it was split from GJS. Things have been moving pretty fast in GJS, so you may have to ask for help from the Cinnamon community if CJS hasn't been tracking upstream GJS.
The first place you should start is gjs.guide, which is the actively maintained portal for GJS and GNOME Shell extension documentation. There is also an Architecture page which briefly describes the relation of GNOME Shell extensions to the GNOME platform.
Workflow
There is a tiny snippet about how to test an extension by either restarting GNOME Shell or running a nested Shell, but it will need to be expanded at some point:
To restart GNOME Shell in X11, pressing Alt+F2 to open the Run Dialog and enter restart (or just r).
To run new extensions on Wayland you can run a nested gnome-shell using dbus-run-session -- gnome-shell --nested --wayland.
But again, I don't if the above will work with Cinnamon/CJS.
Overview of Widgets
Bindings for GJS are generated from introspection files, which are also used to generate the API documentation. In other words, our "GJS" version of the API documentation will only include material parsed from the C source. In the case of libraries like GLib, Gio, Gtk and so on, you can reference the C documentation for any other material and it should still make sense.
In the case of Clutter, I like to think of it as Gtk if the only widget was GtkWidget, with all of it's machinery. When it comes to St, almost every class is a direct analog of a Gtk widget, such as GtkButton and StButton. If you don't know what a class is for, chances are you can just glance at the Gtk documentation and you'll realize "Oh, StIcon is basically just GtkImage".
Mutter, on the other hand, there is no such high-level tutorials or overviews. It's best just to join Matrix or discourse.gnome.org and ask the community of extension developers and shell developers.
Events
With regard to Clutter.KeyEvent, I had actually forgotten how this situation was a little tricky and non-obvious. Put simply: "events" in this context are sort of polymorphic (I believe they're unions in C) which is why the generated API in GJS is a bit confusing. If you see Clutter.Event.get_key_symbol() and then browse around that page I think it will become clear and you should find all the accessors you need.
Here is the list of key symbol constants and the list of key symbol constans as C definitions in the source might be easier for searching.

I just found https://projects.linuxmint.com/reference/git/cinnamon-tutorials/ that also includes the Cinnamon-specific parts (but haven't looked into the details yet, I'll update :-))
I added some links to the referenced manuals below. For St I did not find an online version yet. But: you can install some dev documentation offline via sudo apt install cinnamon-doc. This adds the Devhelp program in the Programming category of your menu and it has reference manuals for Cinnamon components and for libraries it uses.
Overview
The documentation of Cinnamon is separated into 4 different parts (5
if you count muffin). What you are currently reading is the tutorials,
which includes the general top-level overviews and tutorials you will
need for Cinnamon. This is named “Cinnamon Tutorials”.
The second part is the Javascript reference, which describes the
Javascript part of Cinnamon. This is named the “Cinnamon Javascript
Reference Manual”. This is a technical reference for the individual
functions and objects available in Cinnamon. Note that this
documentation is aimed at both applet/extension developers and
Cinnamon developers themselves. So depending on who you are, some of
the information might be entirely irrelevant.
The third part of the documentation is for the C part of Cinnamon,
which is simply referred to as the “Cinnamon Reference Manual”.
The last part is the documentation for Shell toolkit, or St. This is
the graphical toolkit used to draw widgets on the screen (similar to
Gtk).
The modules covered by the Javascript documentation are those imported
via imports.ui.* and imports.misc.*. The global object is documented
in the C part of Cinnamon, as well as things accessed through
imports.gi.Cinnamon. Things accessed through imports.gi.St are,
unsurprisingly, documented in the St part.
imports.gi.Meta refers to Muffin, while others (eg. imports.gi.Gio)
are third-party (usually GNOME) libraries that are documented
elsewhere.
Accessing the documentation
There are two ways of accessing this documentation, one of which is
what you are currently using. The first method is accessing it online,
which will be available at http://linuxmint.github.io.
The second method is to access it locally. Install the program devhelp
and the cinnamon-doc package (might be named differently in different
distros or included in the cinnamon package itself). Then run the
program devhelp to access all documentations you have installed in
your system (not limited to Cinnamon).
And also worth a look might be the Linux Mint Developer Guide
The CJS repo in GitHub includes also some docs and examples (that are GJS apps in fact, but nevertheless a source of inspiration).

Ember and Dead Code elimination / Tree shaking

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

Working with Angular 2 [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Our team is way too excited with the alpha release of Angular 2 and we're just eagerly waiting for it's stable release and getting started with it.
But during the ng-conf 2015 on Angular 2 by Misko, we came across following things which made me confused
TypeScript! Is it really needed to use typescript to gain better performance instead of writing plain simple JS code we've been doing all along. We've came across a few comments that says typescript helps in better performance.
ES6 features. Since angular 2 will be using a lot of es6 features, would that mean we'll have to wait for all the browsers support at least those features needed by angular 2 before we can kick start with it on our production applications.
Web components. Since angular 2 provides the facility to create web components and I've came across a few blogs on creating your own (using polymer), how hard is it gonna be for our team to create them? Or is it better if we just stick to old directives creation thing ?
Performance. I've seen this video of Angular + React which provides a good comparison of angular vs angular + react vs angular 2. But I'm not sure if that's the case that angular 2 is really fast all the way or if we can go ahead with building angular + react app to avoid waiting for angular 2 to stabilize or the browsers to have support for es6 features that angular uses.
I'm not sure I've structured my question well, but above are my concerns before I start learning angular 2 because with their demonstration of angular 2 + typescript seemed like it's gonna involve a lot of earning curve for me and my team.
I'll really appreciate if someone can clarify on the above listed concerns I have.
Thanks.

TypeScript! Is it really needed to use typescript to gain better performance instead of writing plain simple JS code we've been doing all along. We've came across a few comments that says typescript helps in better performance.
TypeScript is about static analysis for better type-safety. It also has a pretty nice suite of editor tools (e.g. WebStorm). You don't need it for performance. It's more a tool for helping you author. Personally though, I love it.
I've begun migrating some of my existing open-source libraries to TypeScript because it's so much easier to work with. For example, check out Task Runner before and after.
ES6 features. Since angular 2 will be using a lot of es6 features, would that mean we'll have to wait for all the browsers support at least those features needed by angular 2 before we can kick start with it on our production applications.
A lot of ES6 features can be polyfilled. Check out https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills.
Web components. Since angular 2 provides the facility to create web components and I've came across a few blogs on creating your own (using polymer), how hard is it gonna be for our team to create them? Or is it better if we just stick to old directives creation thing ?
Web components are also polyfillable (see here). In this case, I'd suggest you follow the Angular team's recommended practices for creating your components. Also perhaps keep an eye on what's coming out of the Polymer team in this regard.
Performance. I've seen this video of Angular + React which provides a good comparison of angular vs angular + react vs angular 2. But I'm not sure if that's the case that angular 2 is really fast all the way or if we can go ahead with building angular + react app to avoid waiting for angular 2 to stabilize or the browsers to have support for es6 features that angular uses.
This sounds to me like premature optimization. Build for (plain) Angular first and optimize only if you notice performance problems in particular parts of your application.

TypeScript! Is it really needed to use typescript to gain better performance instead of writing plain simple JS code we've been doing all along. We've came across a few comments that says typescript helps in better performance.
TypeScript is not required to use Angular2.
Most examples you see will use JavaScript:
classes (ES6)
decorators (ES7/Typescript)
types - (Typescript)
Except, browsers don't support those features yet so all Angular2 source will need to be transpiled to ES5.
So in ES5:
classes can be faked by extending prototypes
decorators can be faked using wrapper functions
types aren't really necessary to begin with, they're synctatic sugar added for safety
It would be unrealistic to expect existing users to inherit the risk of using experimental/bleeding-edge standards. As such, the documentation covers writing Angular2 apps in ES5, ES6/7, and Typescript.
Aside: I personally prefer not to use TypeScript. Traceur can be configured to support with experimental extensions for #decorators, and system.js provides a polyfill for the proposed es6-moduler-loader spec.
Here's a look at the Angular2 Documentation.
ES6 features. Since angular 2 will be using a lot of es6 features, would that mean we'll have to wait for all the browsers support at least those features needed by angular 2 before we can kick start with it on our production applications.
As I said already, ES6 isn't officially supported yet in all browsers. Even if it were, most sites will still require a polyfill to provide backwards compatibility to older browsers.
One of the cool features of the es6-module-loader is the ability to dynamically load dependencies on the fly. By the time Angular2 is out of beta, it should be easy to incorporate this into your app as a feature-detection strategy.
Web components. Since angular 2 provides the facility to create web components and I've came across a few blogs on creating your own (using polymer), how hard is it gonna be for our team to create them? Or is it better if we just stick to old directives creation thing?
Not hard although you may need to use Angular2-specific web components. The reason being, Angular2 is more than a front-end web framework. It's can also be used for isomorphic (ie prerender on the back-end), native, and mobile apps. That means, touching the DOM directly is highly discouraged.
As for the creation of the components themselves... It's no different than creating any other component in Angular2. Unlike the old MVC model of grouping code by type (ie models, views, controllers), the component model encourages grouping code by context.
When you import a reusable component, it should come with any directives, services, etc required to use it.
For an example, see the I created. In addition to cloning the repo directly from GH, the code can be installed and imported directly via JSPM.
Simply import it, add the component class to your view directives and any <ng2-markdowm> element in your template will just work. It doesn't get much easier than that.
Performance. I've seen this video of Angular + React which provides a good comparison of angular vs angular + react vs angular 2. But I'm not sure if that's the case that angular 2 is really fast all the way or if we can go ahead with building angular + react app to avoid waiting for angular 2 to stabilize or the browsers to have support for es6 features that angular uses.
There are 3 major performance improvements introduced in Angular2.
1. 2-way data binding is no longer the default
Elements that require data binding need to be explicitly marked in the template (ie don't fret, the new syntax makes this really simple). As a result the overhead required to do dirty checking on the DOM is dramatically reduced.
That means, no more $scope, $scope.apply(), and weird scoping rules in the HTML markup. Instead, the hierarchy of custom <elements> is defined in the Angular2 components.
2. Angular2 leverages the virtual DOM
jQuery made it extremely simple to directly manipulate the DOM. As a result, it also made it extremely easy for inexperienced developers to thrash the DOM and trigger layout reflows via frequent incremental updates.
The VDOM is basically a simplified in-memory representation of the DOM. Incremental updates get applied directly to the VDOM which later get applied to the actual DOM in batches.
Aside from network requests, DOM manipulation is JavaScript's greatest performance weakness. The VDOM on the other hand is an order of magnitude faster. Instead of expecting devs to follow 'best practices' by manually batching updates to the DOM, Angular handles batching transparently.
Fewer DOM manipulations = less UI rendering/reflows = a much more responsive user experience.
3. Angular2 runs on a background worker
This isn't exactly a new concept. Desktop GUIs have worked this way for years, it just wasn't technically possible the introduction of HTML5 background workers.
In most desktop applications, the main context runs synchronously+ and the UI runs asynchronously in it's own separate thread. That makes the user experience responsive regardless of whatever the application is doing in the main context.
+Note: This isn't necessarily true, but for clarity sake.
In the browser, all execution happens in the main context+. That means, every time Javascript has to block on a CPU-heavy operation, the user interface becomes unresponsive to the user. This is not ideal and makes for a lousy/inconsistent user experience.
+Note: In practice browser implementations vary greatly but lets keep things simple.
With web workers, it's possible to push everything but the DOM+ into a background worker context. Ideally, Javascript's should have little-or-no impact on UI responsiveness.
+Note: The DOM's state still needs to be accessible to the renderer.
One side-effect this transition is, the Angular2 architecture is now completely decoupled from the UI/DOM. Meaning, it's now possible to write UI adapters for other platforms (ex for IOS, Android, SmartTVs, etc) that run on the same Angular2 code natively.
React
As far as I can tell React is using all of the same performance improvements as Angular. They use the VDOM to batch updates, and mentioned native portability to other platforms so I assume they went through the same architectural change as Angular.
Honestly, using background processing to free up the UI is just another step in the evolution to reach feature parity with desktop applications.
Angular2 vs React
I encourage you to watch the video again all the way to the end. The presenter screwed up when he wrote the code so the live demo wasn't an honest comparison.
With that said, it doesn't really matter which is faster. Neither will be dramatically faster than the other but they'll both be dramatically more responsive and scalable compared to other UI frameworks.
Update:
Rewrote the section about web components to better answer the question.

Note that Angular 2.0 does promise to work well with Web Components and Polymer, but in the current stage, i.e. Angular 2.0 alpha, it doesn't work (see this). So you'll have to wait for a while I guess.

How do you manage your DojoX code?

How are you managing your usage of DojoX code or widgets in a production application?
The Dojo Toolkit is comprised of Core, Dijit, and DojoX. As an incubator for new ideas to extend the toolkit, DojoX code and widgets are functional with varying degrees of instability.
DojoX Code like QueryReadStore (for fetching batches of data from the server) or widgets like Grid (for utilizing a user interface grid component) are not included in Core or Dijit. But they are functional enough to utilize in some cases, with the caveat "developer beware", because in future Toolkit versions the API or the component location in the source tree might change. Another catch is that you may have to tweak the DojoX component you are using for it to function properly in your environment, as there's not yet a high degree of robustness in the code.
So, how are you ensuring that as the DojoX components you use evolve, your application stays on a smooth track?

This may be an obvious, but much more involved, solution ... but: Get involved! It actually is one of the best ways to familiarize yourself with the overall power of Dojo in one sitting, teaches a lot of good JS-foo, and ensures you have inside information as to the future of a particular module. Most of DojoX is community contributed, and aiming for stability and usefulness. The more people reviewing, testing, hacking on the code -- the more likely it is to succeed and become stable.
Regards,
Peter Higgins

There are several ways to do it:
Stick to one version of Dojo and use it consistently.
Move modified code to your own namespace and include it from there.
Effectively it is a forking of an existing DojoX module. All code syncing and back porting is your responsibility.
Pay attention to the rest of Dojo — if it changes in such a way that it breaks your forked version, be ready to patch your module as well.
Copy modified files somewhere and include/require them before the original file is required.
To illustrate the latter technique imagine that there is one file I want to patch located in dojox/charting/abc.js:
dojo.provide("dojox.charting.abc");
// the rest of the file
...
I can copy it to my directory as, say, my/patched_abc.js, and make it look like that:
dojo.provide("my.patched_abc");
// now I include the rest of the file with my modifications
dojo.provide("dojox.charting.abc");
// the rest of the file
...
In my code that uses dojox.charting I include it like that:
dojo.require("my.patched_abc");
// now I can include dojox.charting,
// which will use my patched dojox.charting.abc module
dojo.require("dojox.charting.Chart2D");
// the rest of the file
...
Just be careful to avoid circular "require" statements.
This technique works very well for backports and minor customizations. If your changes are more extensive than that, you should consider writing your own module.