Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 months ago.
Improve this question
Which is the best approach/framework for micro frontend development?
I have more than 5 apps based on angular, react and vue and want to display all 5 apps on a single UI.
We have many micro frontend frameworks like single spa, piral, moisaic project, Podium and many more.. available in market now.Need a clear picture which help me to achieve it using any framework.
It all depends.
Obviously, I am biased towards Piral, but in order for Piral to be efficient you'll need to check some (the more, the better) of the following bullet points:
[ ] You want an app shell (either for technical reasons, e.g., provide shared dependencies and / or for other reasons such as a shared / centrally governed design)
[ ] You have a clear tendency towards React (i.e., you have lots of different frameworks, but the majority of your apps is written in React)
[ ] You need to have components in components (e.g., a component from microfrontend A should be used in a page from microfrontend B)
[ ] Your application is "dynamic" / has a "tool" (or application)-like character; no-JS is not a requirement
[ ] You want to enable / disable modules on the fly (e.g., certain users should only see microfrontend A, but not B)
[ ] You'd love to have rich tooling support, e.g., when scaffolding a new module - and TypeScript support should be first-class, too
[ ] Lazy loading (not only of full microfrontends, but of individual components such as pages) should be possible
[ ] Communication via the different modules is never direct, but always indirect (i.e., your system will never break if microfrontend A is there, but microfrontend B is not)
The others you mentioned have similar lists.
Hope that helps!
I think web components comes to the rescue in your case. You encapsulate your react/angluar/vue/whatever in custom element and communicate each other with properties and events
But be careful, not all frameworks play well with custom elements - https://custom-elements-everywhere.com/
I believe Web Components (Custom Elements) comes as a rescue for you.
Customized built-in elements inherit from basic HTML elements and these are capable to run as standalone
Bundle your any javascript framework into single bundled JS file and wrap it in custom elements (its framework independent)
Share Data across MFE using custom events
You can find a good example here - https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements
First of all, let's figure out why you are going to use micro frontend?
Complex business logic in your current frontend?
Distributed teams?
Restructure your legacy systems?
Any other reasons?
We are going to use micro frontend because we have distributed systems and want to provide our customers with consistent experience when they need to use different web service for their daily work.
We are using React to structure our micro frontend services, because it's easy to manage those components that following our material design, there must be some team or someone to doing and maintain the overall architecture, like styling, common components and practices.
For details, we mainly following this great article
We are still on progress, hope to discuss more about it.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 10 months ago.
Improve this question
I wanted to develop a large-scale web application using Tailwind CSS.
Is Tailwind CSS suitable for large-scale web applications?
& Tailwind CSS worth investing time and money, or should I go with Vanilla CSS or another UI framework?
In my case, I have a design system and extensive database records, and I will need to use Animations, Drag & Drop ..etc. to build my SaaS product (Dashboard Builder).
I am looking forward to your guidance.
Just offering some counter points to these answers saying don't use Tailwind:
Setup properly (eg. using webpack/postCSS, not just pulling in a .css file from a CDN), you actually have a lot of control.
You can use a tailwind.config.js file to configure almost all aspects of the CSS - setup new colours, spacing, enable/disabled hover/focus effects etc. Once this file is setup correctly for your design system it is very easy to create a consistent application.
Tree shaking is built in by default - on running a production build your bundler will scan your code and strip out any classes which aren't used, resulting in the smallest possible file size.
It comes with a bunch of functions, mixins and helpers where you can create your own classes if need be - while keeping it consistent with default tailwind classes.
Another big one is that any future developers working on the project won't. have to learn your CSS system, they can read Tailwinds well-written documentation and know how to use it fairly quickly - if they don't already.
It's been tested by thousands of developers worldwide, so it covers a huge amount of edge-cases and browsers quirks you might miss if you're building your own system. A lot of developers think they can build a better system but that's not always the case.
This isn't to say it's right for your project - there's only really you who can weigh up whether having absolute control of your styles is worth losing the time saved using Tailwind - but a lot of the regularly thrown out negatives of Tailwind (file size/control/'need lots of classes') are not really issues if setup correctly.
I wouldn't recommend in your case. TailwindCSS should not be preferred if you have a design system at hand. Your code will get messy when you try to apply tailwind classes conditionally. You can work around this by using selector utility functions to decide which classes you'll use. I would prefer something like SCSS or a UI framework.
In my experience, Tailwind is useful for rapid development - for when the priority is speed rather than extreme customizability. There is also rather a learning curve to be proficient at creating good pages with tailwind (outside of copy-pasting existing components).
For a large-scale application in the space of a "dashboard builder", I'd think that there'll be lots of custom-designed components, so I personally wouldn't use Tailwind.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've recently started on a large multi-year client project, and the first phase of front-end development is creating a pattern library to use across the project. I'm using Compass and Blueprint for my grid. The #include blueprint-grid mixin looks perfect for this project: it'll automatically generate semantic classnames (i.e., .span5) that the rest of the team can reuse across all pages.
However, the Compass documentation states:
Best practices discourage using this mixin, but it is provided to support legacy websites and to test the sass port against blueprint's example pages.
Why is that? Why is there a push to use non-semantic classes in modern grid systems? It seems less DRY to create a new CSS class for various page elements that will all share the same grid widths. For example:
.dashboard__chart {
#include column(6);
}
.dashboard__news {
#include column(6);
}
when I could simply just have a .span6 class to apply in my markup.
This may be situational: the non-semantic classes make sense if your entire project has a similar layout throughout (e.g., a news website or blog). However, this dashboard/reporting tool project has somewhat differing layouts throughout every page.
So back to the original question: why is it best practice not to use semantic classes, and what's the best way to avoid them?
it'll automatically generate semantic classnames (i.e., .span5)
I don't think that "span5" is a semantic name in that it doesn't describe the content at all but describes the layout in a fairly specific way.
Of course, the term "semantic" is thrown around a lot, but in its purest sense it should have little or nothing to do with presentation.
Reasons not to use names which describe presentation:
If the layout changes, the name is wrong
The layout may be adapted to for a different device for which it is wrong and/or meaningless.
The markup has less meaning to anyone reading it (i.e. your team)
Layouts can become brittle; changing one class that has been used in many different places and with many different meanings may break in some places in which it is used.
The biggest downside to generic classes like "span6" is that they are abused (I've seen this with Bootstrap, which has similar grid classes defined). "I need this element to span 2 columns...great! I'll just slap a 'span2' class on it and be done!"
This doesn't mean that you shouldn't look for reuse; but that reuse can come from class names that are related to the content (admittedly, this can take some effort) and through the use of mixins.
I've recently started on a large multi-year client project, and the
first phase of front-end development is creating a pattern library to
use across the project.
Most projects end up with exceptions/compromises for the sake of practicality, but you have the opportunity to start with a best-practices approach.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I believe that one needs to buy a license(?) to use devexpress. I'm currently implementing a gridview and want the sorting arrows to appear in column headers. I know that devexpress grids have that feature and I believe many more? Could anyone point out any specific reason why someone would pay for using a devexpress grid, or I guess the devexpress suite comes with a lot more than just grids?
Could anyone point out any specific reason why someone would pay for using a devexpress grid, or I guess the devexpress suite comes with a
lot more than just grids?
Here is your reason of paying for the third party controls, In Short features give preference to use these rather than the standard controls.
it’s unlikely for the client to have a specific request about some user interface component that can’t be satisfied with either default controls or 3rd party controls. Many of the convenience aspects like detailed view, sorting, auto completion, filtering, and changing perspective have already been solved by the 3rd party companies over the several versions of the controls.
When in need for some UI functionality, it’s better to search the companies’ websites for something suitable, instead of trying to develop from scratch. It will also certainly be cheaper than going over the document, develop, debug, test, and deploy cycle countless times.
By using 3rd party controls it’s easier to keep focus on the actual business functionality for your project, to spend time developing visible features for the application, than to work on solving the many background technical difficulties associated with developing every functional request.
On the other hand, if you reach the conclusion that the control would require some serious modifications in order to suit your needs, it’s probably better to do the entire development in house, eventually based on the simple default controls that come with the .NET Framework.
For example, I do use devexpress controls, on which project i am
working they specially require a developer with knowledge of
DevExpress control, because that will reduce the development time(
Project completion Time also) rather than using the standard control.
The Specific requirement make them to pay for the controls as those
guys commented in this SO thread.
Check these for feature comparison - Standard GridView vs DevExpress GridView. I like it's client side functionality..
Here's a reason. Because they want sorting arrows in column headers. Also, any of hundreds of other features these products provide that the default grid does not.
The point is, the extra features ARE the specific reason.
Not only does it take care of operations such as sorting and search. It is actually very useful in helping you populate data from your database easily by quickly mapping your fields to IQueryables (If you are using C# and not DevExtreme). If you're using the grid on many pages in your platform, you can easily configure all these grids from one single point (Themes, Functionality, Configuration, etc...). It also provides additional security measures to prevent certain injection attacks. Finally, it is always updated with new features and improvements with constant releases. One really important thing too is that the DevExpress help center and forums are very rich and you will find an answer for almost any question or issue you come across. So using the DevExpress component will bring scalability and increase reliability with time for your platform.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am building a web site for baby names. Users can submit a name, meaning and some tags, and moderators can edit/approve it. Very small amount of data is used for each entry/post.
Looking for some kind of framework that supports the following features or I can easily extend it,
Unicode support
I have large number of names, I should be able to import them into my website by code.
User roles and permision
Some kind of report options. For example, Display list of names that starts with some alphabet or list of names for a #tag
Full text search
oAuth/OpenID
Are there any frameworks like Orchard, Umbraco I can leverage or would I be better off writing a new ASP.NET MVC application?
If I were you I'd surely stick to some available CMS platforms (Orchard or Umbraco) instead of writing from scratch and reinventing the wheel.
From my experience with Orchard I can say that setting up a website as you described would be pretty easy and painless with this platform.
Features like those you mention are already available in Orchard, but I guess (as with just about every CMS) this will surely need a little customization to suit your particular need. All the custom functionality could be easily wrapped in a single, custom content part. How to do that is very well described in the Orchard documentation.
Of course.
Without a problem. You have three options: import directly into Orchard DB (into the corresponding tables), import using Orchard Import/Export functionality (which would involve exporting the data to XML recipe format first) or just use the current data source without the need of importing. There was a question on SO a while ago of getting data from a custom WebService. The solution provided perfectly fits here, so please take a look.
Out of the box - described here and here.
I don't know if you meant the backend (admin) view or in the frontend? Tagging and displaying tagged items is available oob. More complex, custom reporting would involve some custom coding (writing a custom content part).
Available and described here.
Sure! It's available via very nice OAuth Module, written by Nick Mayne. It allows you to bind Orchard accounts with OAuth providers.
I don't have much experience with Umbraco though, so I can't give you any direct help, but I guess it'd be nearly as easy to built your website using it.
Personally, I prefer Orchard for its flexibility, extensibility and code freshness. But the choice is a matter of your personal feeling and preferences. From what I've seen they have very similar functionality, although differ much under-the-hood.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm about to create a site that will act as public front site of company that sells furniture, but after user log in, he'll see much more options. Internal news, files to download, customized pricings, newsletters, etc. - stuff for wholesale clients.
I want to make it quickly and maintain/extend it easily. I'm asp.net developer and while I could write it in python, php, whatever else (I know these too), I still prefer asp.net. I was thinking about umbraco, since it gives a real productivity boost and that I familiar with it ( and extending it). I've had a short romance with ASP.NET MVC, so I know what it's all about, but I would still spend some time learning it (but what a fun!). Of course, there's also webforms, but that's my last choice here. Last but not least to mention is the SEO.
The question is, have anyone of you had similiar dilemma and what was your final choice?
EDIT:
Just wanted to notice, that this site will be maintained by me and by the client. And the goal is to set it up asap, but that doesn't end the development process. This product will live on for years.
This is the age old question - bespoke vs off the shelf.
With Umbraco you have the potential for an awful lot more site in a lot less time since the requirement is substantially to produce the content rather than the infrastructure. In terms of UI you can produce you should be pretty close either way - Umbraco gives you a lot of control.
With MVC you get to do anything you want - but one way or another you have to build it and, more importantly in terms of this question, you have to build the tools to maintain the content too.
And this is why there is a dilemma - because with Umbraco (or any packaged CMS) the question is 1) can you do what you need within its constraints and 2) where you can't how easy is it to extend the system to deal with those elements that need to be custom.
Finally there's the question of who is maintaining the content - if its to be the site "owner" (which it should be) how are they going to interact with the system? This is the advantage that Umbraco has in that the whole content maintenance thing is handed to you on a plate.
One last point - remember that you have a duty to your client to choose what is best for them and not to choose a platform because you want to play with new toys. Thankfully a lot of the time the two coincide (-: but its worth bearing in mind. (Oh, and before you write off forms completely, remember that ASP.NET Dynamic Data - forms based - will give you an instant database maintenance site which will go some way toward dealing with the maint problem that you'd have with an MVC site).
So... no absolute answer because there is no single "right" - you're almost always working on a case by case basis.
Comparing MVC and Umbraco is comparing apples and oranges really. Umbraco is a Content Management System and as such provides plenty of out of the box functionality that it seems your client needs, whereas MVC is a web development framework, and as such is at a lower level than Umbraco. Using MVC to implement the features needed by your client is very much the same as using asp.net web forms to implement the very same features. In fact, Umbraco could decide at one point to use MVC to implement it's features.
So I agree with Murph, the choice should be Content Management System versus implementing CMS features yourself using MVC or any other web development framework (and yes, MVC is brilliant).
Since you are familiar with Umbraco, as am I, you know that you will be stuck integrating packages. This may not be a bad thing, but it is a consideration. You will not be able to use that website with any other solution. As you know Umbraco consumes the entire website.
I personally would go with MVC, because I love it. Version 2 was just released today, making it even easy to put an application together in no time.
Just want to tell you that I'm going down the n2 + mvc road.
Thanks for the answers!