We Keep Coding

Using the Ionic framework with plain JavaScript

Can one use the Ionic framework with plain Javascript (aka. without the recommended frameworks like react, angular or vue)?
If yes, how?

yes, you can build Ionic apps using VanillaJS or take advantage of Vue, React or Angular or Stencil
all components documentation available for JavaScript
it's recommended to use React or Vue,... for large scale application but if you want use plain JS it's available.
From Ionic framework documentation:
One of the main goals with moving Ionic to Web Components was to remove any hard requirement on a single framework to host the components. This made it possible for the core components to work standalone in a web page with just a script tag

In short: Yes, in the same as way you can use wordpress.
According to the official documentation:
One of the main goals with moving Ionic to Web Components was to remove any hard requirement on a single framework to host the components. This made it possible for the core components to work standalone in a web page with just a script tag. While working with frameworks can be great for larger teams and larger apps, it is now possible to use Ionic as a standalone library in a single page even in a context like WordPress.

Rendering one single Next.js component separately outside the Next.js framework context

js and React experts,
Situation:
In our portal we have 2 completely different applications: CMS (PHP based with its own framework, templating engine and so on) and an Online Shop (Next.js based, React technology stack).
Now, there's one module which is already completely built in the Next.js world, but it doesn't exist in the CMS world.
Challenge:
implement the same functionality also in the CMS part of the website with minimal possible effort
Obviously, the naive way would be just to implement it once again in the CMS technology, which is possible, but not very elegant, as the implementation in Next.js will be supported by a separate team, which is going to change things over time and add features, that all would need to be implemented twice.
I'm new to React, but according to an example from the official docs there is a way to run a React app encapsulated in one div element (see https://nextjs.org/learn/foundations/from-react-to-nextjs). I tried it and this minimal example worked embedded in the CMS templating context just fine.
Now, the question is: Would that also work with a Next.js component? Can I render the complete subpage with a separate CMS engine and only one single encapsulated HTML element with Next.js? From what I understood Next.js is built to take over the rendering of the whole page completely, but maybe there's some advanced way to make it work React-like?
Thank you very much for your input.

best practice/architecture to combine multiple js components in a spa

I would like to have the following architecture for a single page application:
each page or a widget can be an independent reusable module (reusable for this project however it might be used on others as well)
there will be a core application that will use all those external modules. the core application will be able to communicate with the modules and vice versa.
each module can be written in any technology (react, angular, vanilla)
each module should be deployed independently (something like dynamic-lazy-loading)
the core app should be responsible for the config of the modules (api urls etc)
I have not been able to think about a good way of achieving everything i stated nor find anything on google.. but i might be missing the keyword for such architecture.
Any ideas, best practices or just some relevant input? thanks!

after researching this subject bit more, the architecture that i think that will match my requirements is based on web-components (can read more about it here - http://webcomponents.org/ and would recommend using a library like polymer).
the advantage of a web-components is that they can hold everything they need in them (html,css,ajax requests, basically anything that can be in a html document) and using shadow or shady dom imply those components into the document just like we would have done once with iframes.
by using this architecture, you will be able to migrate your components without caring about the wrappers technology (angular 1/2,react, knockout, vanilla js etc). for example, in order to use it in angular, we just wrap a component with a directive and thats it.
the other bonus is that you can even host those components in different servers and therefore deploy them separately.

Integration of other js/app components (e.g. jQuery) into react.js SPAs

It seems pretty challenging to integrate other js libraries and apps into single side applications based on react.js - except for using iframes.
Does anyone know a proper solution/workaround for visual integration of non-react apps into react.js SPAs?

You will have problems to integrate any kind of libraries, which are working with the DOM directly.
jQuery (or many of jQuery-Plugins) are manipulating the DOM. People which decide to use React, don't want to access the the DOM directly, instead the DOM is generated by React automatically.
So, there are many JS libraries which you can use with React, like Redux, underscore.js, lodash.js, moment.js, i18next.js and so on.. But this libraries are basically for Data-management, Modeling, Validations, API communication and so on.
All UI / DOM Rendering stuff should be managed by React Components.

Creating and reusing custom elements with jQuery vs Polymer vs Dust.js

I've written some widgets to use in my web app, and I'd like to be able to plug these widgets in throughout the app without pasting big chunks of widget code. So far I've been writing custom HTML tags and using jQuery selectors and CSS to populate and style my tags. The end result allows me to write <myTag></myTag> anywhere on a page, and have my custom widget appear.
Recently, I've learned about Dust JS and Google's Polymer Project. My understanding is that Dust would allow me to write a template and "swap out" parts of the template with my content, while Polymer would allow me to create custom HTML tags as I've been trying to do and place them wherever I'd like.
Would it benefit me to use Dust or Polymer? What is the difference between those two options and simply using jQuery to select my tags and plug in my widget/styles? Obviously these are three drastically different libraries/frameworks, but it seems to me that there is some overlap when it comes to my use case. Please correct me if I'm wrong.
Edit: Say I have a plain old HTML page. The question I'm getting at is what would prevent me from using {myCustomWidget} in Dust to "plug in" my widget throughout the app, other than the fact that this may not be standard usage? Similarly, why would I use Polymer to create "shortcuts" for my widgets over using a jQuery selector?
Thanks!

I don't know a ton about Dust, but I've made fairly heavy use of both jQuery and Polymer. Someone with more Dust experience should totally weigh in. It looks like one of the main advantages of Dust is that it's designed for efficient server-side rendering. It's also format agnostic whereas jQuery and Polymer are both specialized for HTML.
Polymer is designed for the use case of creating encapsulated widgets that can be easily reused. It's got a few advantages over rolling your own system with jQuery:
A Polymer element can be imported with one line, and the import will pull in its html, js, and css, and it will register the element within the page.
Polymer has support for data binding, meaning that you typically don't have to write code to ensure that the widget is updated after some data changes. When the data changes, all of the widgets that are interacting with that respond immediately and automatically.
Polymer interops really well with jQuery, so if you've got a site that's doing a lot of jQuery style interaction today you can gradually introduce Polymer elements and they'll play well with the rest of your page. e.g.
$('<my-slider>').appendTo('body') // append the slider widget to the page
$('my-slider').attr('value') // get the current value of the slider
$('my-slider').attr('value', 100) // set the value of all sliders
etc
The styling of a polymer element is encapsulated, meaning that a widget will not mess up the rest of the page with its CSS, and the enclosing page won't mess up the styling of the widget (though the enclosing page can style the widget it has to be fairly intentional, just setting something like * { padding: 5px; } won't throw everything off).
There's great docs at http://www.polymer-project.org/ (and after getting started, I strongly recommend the API docs, they're quite complete and informative: http://www.polymer-project.org/docs/polymer/polymer.html )

I've not used Polymer before but I've used Dust and jQuery extensively.
Dust is simply a template library, just like Handlebars,Mustache, Twig and the myriad of other template libraries out there. It's written in javascript and can be used with NodeJS or can easily run in the browser if you're building client side applications.
Both Dust and jQuery can be used together. Dust would render your HTML templates and as always, jQuery would be used to manipulate them and do whatever else you normally do with jQuery such as listen to events and handle them accordingly.
It's important to note that the two aren't alternatives but rather they work together. Dust cannot do the things that jQuery does and is not meant to. Dust works very well when you have large templates that require partials and blocks.

At its core, Polymer is a platform of polyfills for the current implementation of the WC3 web component recommendation as well as some aspects of ECMA 6 such as Object.observe() and WeakMap. Included in the Platform are the libraries NodeBind and TemplateBinding which enable observable (two-way) custom element data-binding.
Dustjs is an asynchronous logic-less templating engine for client-side and server-side(Nodejs)
rendering. There is no native concept of an observable in Dustjs(as is the case for most template engines), meaning two-way data-binding is outside the scope of the project. However, the PayPal roadmap for Dustjs indicates two-way data-binding may receive official support by the end of 2014.
That being said, NodeBind and observe-js are separate repos not necessarily tied to the Polymer custom element implementation, meaning you can use them in your own projects--which is exactly what I did.
My biggest criticism of client-side rendering frameworks like Polymer (and in some respects, angularjs), is that they are not SEO compatible. So I actually combined NodeBind with Dustjs to make my own two-way data-bound custom element implementation derived from the Polymer platform. The idea is that Dustjs renders the template server-side(or even client-side, if SPA) and then upon rendering, you bind the Dust context to an observable and then parse the template fragment for attributes and keys, binding them to a path observer which maps to the observable. So, the bulk of the task is to write your own parser. The good news is that you can use the Dust parser to help your code. The bad news is that if you want to support arbitrary depths, it is far from a simple task(involves quite a bit of recursion). The other non-trivial task is to support path observer rebinding in the event of model list additions and subtractions.
A final note: Dustjs inheritance offers a superior way to reference your custom elements without relying on HTML Imports and ajax like Polymer.
You can do something like this:
{>my-element}
simply as a partial. And in my-element.html
<my-element>
<ui-template id="my-element-frag">...</ui-template>
</my-element>
this does require a second-step in your build process(grunt or gulp) that requires you to not only compile the external files but to parse your external files for your "template tags" and compile those as separate templates, which can then be referenced by, say, the id attribute(as the template name).