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 5 years ago.
Improve this question
My company have a really big application, with a lot (!) of data.
We have an argument using 3 modules for the main areas, and the main as flat module in store,
or using sub-modules as much as needed. (for each main sub-module about 6-8 sub-modules)
I wanted to get opinion only from people with experience in complex application using vuex.
Is it better to keep the module flat? or to use sub-modules?
Pros vs Cons
If you go by separation of concerns, It really makes sense to have submodules for different part of your system. It makes the feature enhancement easy and adding in one submodule does not alter anything in other modules, which makes collaboration also easy with different people working on different modules of your application.
Vuex submodules also helps keeping states of different submodules isolated from each other, otherwise it is too easy to have all the state variables mingled among each other. it implicitly emphases this discipline.
But in case your application is very simplistic and it is too much trouble to separate those in different submodules, than it will be definitely a overkill to use submodules.
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 2 years ago.
Improve this question
Can I use multiple frameworks on a single website page?
I try to use multiple frameworks like Angular, Vue, or React in one website view .. is that good or we can only use one
Yes. It is usually done in big enterprise setting with many separate front-end teams each responsible for a smaller portion of a single web app. Architecting a clean approach for it can be difficult so I recommend that you avoid it if you can. Problems include:
How to handle routing such that intra- and inter-framework routes work.
How to share state (such as auth tokens) between apps.
How to share components (and code in general) between apps.
How to avoid importing the same library used by separate frameworks twice.
A popular approach is called micro frontends which mimics the micro service approach for the front end. I’m not aware of any research for how well this works in the wild.
An example (meta) framework that handles this kind of architecture for you is single-spa.
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 4 years ago.
Improve this question
At the moment Im using a bunch of script elements which are referring cdn/local files which is not so great.
I think I would like to declare all required packages using npm/yarn and serve cdn files with self hosted fallback (is this even a good idea?).
Should i go for a webpack/browserify solution or is this overkill for this purpose (because AngularJs is already handling dependency injection by itself)? Im getting somewhat lost in the amount of frameworks/information about this topic.
This is an opinion question, so we can only try to figure out what we would do given our knowledge of your needs. With that grain of salt:
What you are describing sounds like way overkill. Unless your performance needs are huge, manage your dependencies with npm and package them with your releases. If you really need to, use a build tool to minify and package your resources together (like webpack).
There are tons of great JS build tools, and if all of the boilerplate is overwhelming, take a look at something like Yeoman which can help out with that.
In my opinion, a self hosted CDN is probably the worst option possible, because it adds huge support requirements with almost no benefits, because as soon as you stop caring about this project someone else will have to refactor all of your code to new CDNs or local resources.
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
How many classes/functions are best put into a module (which is later required, f.ex. by RequireJS, the Mozilla addon loader, ...)?
As the module seems to be imported wholesale (contrary to f.ex. Python, where you can do from module import class), would it be best to keep them as small as possible? Any other guidelines?
What is the best practice?
(There are similar questions about Java (which recommends "the more granular class layout you have, the better"), Python (which allows for more objects and states "Python is not C#/Java. Trying to bend it to make it look like $other_language will cause frustration and poor user experience") , etc, but nothing JavaScript-specific appeared.)
Maybe these questions were old enough to pass the site standards then. Nowadays, it might be really too broad for some.
I personally do the following when using RequireJS:
One class per module
Module file named after the class name
This allows for easy maintenance, plus dynamic loading of the needed classes.
Only drawback could be the amount of files, but you can bundle the ones most used later using RequireJS optimization features.
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 8 years ago.
Improve this question
I am not asking "what are differences between Ember and Backbone." It's been asked before, and doesn't answer my question.
I don't need to consider syntax, or origin stories, or my developers' coding backgrounds, community size, or which is more lightweight, or readability.
But strictly based on features and performance, which framework is better suited for an app with the following characteristics:
Tons of very similar views with nested subviews.
Lots of complex data to display and sort and update.
Backbone by itself is just a library to create your own framework, whereas Ember is a full-fledged framework for building apps. If you were to go with Backbone I would suggest something like Marionette. That being said, if you're looking for a framework where almost everything is already done for you and you just want to crank out screens, Ember makes this task fairly trivial. The complexity with Ember happens when you want to do something the non-ember way, in which case Backbone can allow for more flexibility.
From what you said it sounds like you are tasked with something that is large, but most of the work is fairly repeatable. I would probably go with Ember if that is the case.
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 come from the Java/C# world where namespaces are absolutely necessary. However, comments like these make me think that modules are of no utility in typescript (and javascript). For large typescript/javascript programs (probably several hundred .ts/.js files by the time we're done), are modules a good practice or do they just get in the way?
ps - I know that opinion questions are not allowed here. But, IMO, this is more a "please explain how javascript works" question.
Having a deep namespace hierarchy is mostly an overkill. Having a single top level namespace is definitely a good idea though.
e.g.
module appName{
class Foo{}
}
instead of
class Foo{}
But not so if you are using already using external modules (commonjs / requirejs) as they isolate code for each file.