Need to build an interface. So want to know what is the best and easy way to do it in vue.js
As with a lot of things, there isn't a "best" thing as this is a very subjective matter but we can focus on the "most popular". I will give you an overview of the current state of most popular Vue.js styling solutions:
Vuetify
A complete material design UI framework has a lot of components and is very active, very customizable as well It probably is the most popular UI solution for Vue.js
Quasar Framework
Quasar is also a material based UI framework but it focuses on performance and developer experience, very active and releases often. It also has its own CLI and allows you to target apps using Electron or Cardova, its more of a complete app-bootstrapper than a UI framework.
Bootstrap-Vue
It is like the name suggests, a bootstrap-based UI framework and is the most comprehensive one with full implementation of bootstrap and a lot of custom components as well. It the way to go if you are going with bootstrap-based UIs.
Tailwind CSS
Tailwind is a utility-first CSS framework that uses PostCSS, it is really easy to get started with and very productive, it is my personal favorite because it stays in the CSS and HTML realm, while UI frameworks are very cool and productive, you cannot escape the overhead they introduce and not all designs are based off bootstrap or material anyways. Tailwind manages to stay productive while being very flexible but requires having decent knowledge of CSS and how properties interact.
Again there isn't a "best" framework out there for styling, so you need to study the options and pick the one that "better suits you".
Related
Not sure it's the right question for this forum, but I couldn't find another place for it.
Our design team built their design system based on fluent ui libraries as described here. They downloaded the design from here.
Unfortunately, our engineering team is using Angular, so we naturally reached for the option of web component but found out to our surprise that the library is completely different - different set of components, abilities, and of course - a completely different design.
I thought that all fluentui platforms are supposed to be an implementation / interface of the same design. Why is this not the case? What am I missing?
Is there a way we can use the design described in here in Angular? (Except actually using the react library inside my Angular project).
Thanks for helping and very sorry if this question is inappropriate for this forum.
fluent web components integrated with angular.
take a look at documents
I'm building my first vue.js app and I'd like to have some help on deciding a design approach.
This app is going to be embedded inside a page of a site - built with Drupal 8.
Both app and site are going to use bootstrap 4 as base framework and we're going to use sass to style.
It's a quite simple app: a multistep form with some ajax call done to the aforementioned site.
It has anyway some components - one for each step, for some of the more complex input, for a sidebar showing the result of the ajax calls and so on.
I need to decide the "guideline" for styling this app and I'd like to get some help\insight to what solution is better.
On one hand, I could put the style inside the app itself; on the other hand I could leave all the style to the one present on the site.
As far as I can see the benefits of the first approach are the use of scope of each module, thus having a better "modularity".
However, putting the style all inside the site would avoid code duplication - simple example: custom color variables.
Personally I can't see for now other differences right now.
I haven't found material about the suggested approach and the pros\cons.
Could advice me of which approach is the best? Thank you.
It depends on the project, but you can make a list of cons and pros based on your project brief. If there are very few (or 0) changes in the future or it's based only on small components (not much style) then go with component-scoped styling. If the project is big, always go with a style pattern like the 7-1 pattern
I prefer working with the 7-1 pattern pattern.
Pros:
- Scalability or future updates like you mentioned the color variables case.
- You don't depend on Javascript to load the style, depending on how you write the app or how it loads, it may have glitches.
Angular 2+ offers Modules (NgModule)s that "configure the injector and the compiler and help organize related things together." They are another layer of code organization, to facilitate modularity of parts of large scale applications.
I am NOT talking about Node modules. Angular has those too. NgModule is unrelated to that.
So far in learning Vue.js, I'm not coming across anything that is analogous to NgModule. Searching for this information was not fruitful on search engines. Is there anything? Or does Vue.js in some way make them not necessary?
They are another layer of code organization, to facilitate modularity of parts of large scale applications.
No, ngModule is the only way the Angular ahead-of-time compiler can discover, walk and tree shake providers that are not required for the project. This includes things like components, directives, services, etc that you would define in modules.
So far in learning Vue.js, I'm not coming across anything that is analogous to NgModule.
You shouldn't because this is an Angular specific feature. Vue has no dependency injection or lazy loading as a core feature.
Or does Vue.js in some way make them not necessary?
You might be confusing Angular NgModules with JavaScript modules. The two are not the same, because Angular uses NgModules to make it's dependency injection system work. Without the DI there really is no need for NgModule. Angular would then work the same way Vue and React work, and use the JavaScript import to resolve dependencies.
Angular is an opinionated (I don't mean that as a negative) and monolithic framework. It uses ngModules for organization. They are a benefit by default. Vue is a progressive framework that allows you to include as much or as little as you want.
Vue Plugins allow for mass registration of components if you need it, but you can just as easily narrow your dependency tree using explicit import/export statements.
Vue Bootstrap has a Vue Plugin mechanism that allows you to include all of the features outright including the custom elements it provides but also allows you to import each component individually if that is what you want.
Angular Powered Bootstrap provides an ngModule in much the same way but also allows you to include components piecemeal if you want.
The key thing here is that Vue tries to be as non-opinionated as possible and lets you configure how you want dependencies included whereas Angular wants you to do everything its way. Neither way is outright better than the other. You benefit from knowing how do to things by default with the opinionated way vs having way too many choices with the non-opinionated way.
Consider this question, how do you perform network requests with each of these frameworks? The answer is obvious for Angular: HttpClient. However, you can use whatever request library you want in Vue, be it fetch, axios, jQuery.get() or anything else as long as you appropriately deal with Vue's reactivity model. You can likely do the same thing in Angular, but you're going outside of Angular's suggested approach.
You likely don't see a lot of documentation about comparable things to ngModule because Vue doesn't really push for organization in that manner. Again, not a judgement, it's just a difference in how the frameworks are intended.
I've been reading about Durandal and Aurelia every time I read something new on Javascript. I hear developers asking to upgrade from Durandal to Aurelia, or similar, on so many blogs. Although I do have an idea, I am confused about what the two really are and how they are related, or if at all they even are related.
Here's how I see it. Durandal is a lightweight SPA framework that allows you to leverage the best of other JS libraries and utilities to build an app. So it's not really a whole package in itself (unlike Angular), but can use different external JS libs - such as Knockout for binding, jQuery for DOM, Sammy for routing, etc.
Aurelia, on the other hand, is where the confusion comes in. Is it also an SPA framework? Or is it limited to being a client-side (front end) framework only? To add to my confusion there is a Durandal blog that talks only about Aurelia. I know from the internet that Rob Eisenberg worked on Durandal before he started working on Aurelia. So is Aurelia an upgrade of Durandal, or something completely unrelated?
I still have some questions but I'm guessing the structure of my question so far will be only asking for opinionated answers. So before this question is closed, any description, links and references in regard will be amazing. I'll be sure to update and add useful links here too.
According to Rob Eisenberg:
"Aurelia is just a vNext of Durandal. On occasion we've even called it Durandal Aurelia. Much like XBox 360 vs. XBox One. The web is significantly evolving, so we're evolving Durandal into Aurelia to match."
Aurelia, on the other hand, is where the confusion comes in. Is it
also an SPA framework? Or is it limited to being a client-side (front
end) framework only?
Yes, it is a SPA framework. Actually, it is a framework for building Javascript clients, it means you can develop apps for Browser, Desktop and Mobile. Take a look at this video https://channel9.msdn.com/Events/Seth-on-the-Road/DevIntersection-2015/Rob-Eisenberg-on-Aurelia
Different from Durandal, Aurelia comes with the full package, everything you need is there. However, it is perfectly pluggable and extensible, and you can combine any other technologies if necessary.
Here is description provided by the official site www.aurelia.io
What is Aurelia?
Well, it's actually simple. Aurelia is just JavaScript. However, it's not yesterday's JavaScript, but the JavaScript of tomorrow. By using modern tooling we've been able to write Aurelia from the ground up in ECMAScript 2016. This means we have native modules, classes, decorators and more at our disposal...and you have them too.
Not only is Aurelia written in modern and future JavaScript, but it also takes a modern approach to architecture. In the past, frameworks have been monolithic beasts. Not Aurelia though. It's built as a series of collaborating libraries. Taken together, they form a powerful and robust framework for building Single Page Apps (SPAs). However, Aurelia's libraries can often be used individually, in traditional web sites or even on the server-side through technologies like NodeJS."
Some of the greatest advantages of Aurelia (in my opinion) are:
Powerful Data-binding. Different from others frameworks like Angular, Aurelia uses new features of Javascript. So, all data-binding stuffs are usually faster in Aurelia (source http://blog.durandal.io/2015/12/04/aurelia-repaint-performance-rules/)
Simple Conventions and Simple Syntax. It is really easy to develop in Aurelia. There are a lot of features ready to use. If you want to overwrite some convention, usually 1 line of code is enough. (see http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.0.3/doc/article/getting-started)
Hope it helps!
I am working on enterprise-level business applications, and now is the time to start thinking about the non-desktop experience.
We have a common component code-base that is using dojo, and are trying to get as much code re-use as possible.
I am really struggling to determine if I should re-use the same code base, or have separate code bases for desktop and mobile.
A big factor in my decision making is the viabliity of dojox/mobile.
It seems pretty cool, and uses the dojo infrastructure which is a huge win, but the fact that it is in dojox scares me a little.
Some questions:
Is dojox/mobile something that can be relied on long term?
Is it a smart idea to try to swap out dijit components for dojox/mobile components depending on what has.js can tell me?
Will dojox/mobile be a part of dojo2.0?
I would add that in Dojo 2.0 the plan is to converge as much as possible the desktop (dijit) and the mobile (dojox/mobile) widgets which should help in your use-case. See: http://mail.dojotoolkit.org/pipermail/dojo-contributors/2013-June/029041.html
You can rely on dojox/mobile. DojoX will indeed disappear from the Dojo Toolkit in 2.0, but most matured (and probably maintained) modules will be pushed to the dijit/dojo library. I quote the reference guide:
In the future (Dojo 2.0), the DojoX package and namespace will
removed. Sub-Packages and modules will be either integrated into the
Dojo Core, Dijit or separated as their own stand-alone package. For
the 1.X code stream though, in order to ensure backwards
compatibility, all these packages are contained within the dojox
namespace and package.
If we look at the explanation of Mature, we can read the following:
This package or module is considered mature and is being actively
developed and maintained by committers within the Dojo Toolkit. It is
expected that it will persist into the foreseeable future.
Source
And if you look at the link above, you will notice that dojox/mobile is categorized as mature.
Another reason you can rely on it is that IBM (which can be considered a pretty big company and committer to the Dojo toolkit) also relies on dojox/mobile for their mobile product called IBM Worklight. If they rely on it, then there's no reason you couldn't.
I don't think it will be easy to start from the same code base and swap out dijits for dojox/mobile components. Usually mobile app development requires an entire different strategy than web applications. You will probably have to split certain things into multiple views and some dijits may not have a mobile alternative.
You can probably re-use most of your utilities and business logic, but I think you will have to start from scratch again if you want to write your view(s). But I'm not really an advanced mobile developer.