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 5 years ago.
Improve this question
I'm trying out some modern Javascript frameworks like Angular, React, Vue and Ember, and they all want me to use build tools like npm, grunt, gulp, maven, etc.
Web-programming used to be fun. Just change some files, refresh the browser and see if it works. Now every time I change something, I have to build it again, which takes quite some time. I really hate to see that web-programming has become like this. I know the building can even be done automatically with these tools watching for file-changes, etc., but still, it just sucks.
My question is, when I want to use one of the mentioned frameworks, am I supposed to use the build-tools every time I want to run, or do I just need these for deployment and testing purposes (or not at all) ?
You don't have to use these tools. They're mostly aimed at people who want to use frameworks in larger projects, and have features that let you compile hundreds of JS components into one file. I personally use them mostly for automating build tests, unit tests, and bundling all the assets together on release days. Let's address the frameworks you mentioned one at a time:
React: React provides an already compiled version of their code on their getting started page
AngularJS: Same as react, there's just a file you can include, just look up "angular cdn"
Vue: They also have a file that you can just include.
Ember: See above
For most frameworks, you can just look up "name of framework CDN" to get an online hosted js file that you can quickly throw in to your projects for web development the old way.
Some libraries require building the code, some don't. From the list that you had, none of them require it technically. They can all work by simply including the js file in a <script> tag. However, there are many frameworks/libraries (such as sass or coffeescript) which do require a build tool, because the source code must be compiled to become html/javascript/css as understood by the browser.
Also, there's not really any reason to be so against using build tools. As you said, they can run automatically on file change, so they're really just in the background.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I'm kinda confused about how node frameworks work. I've been suggested to use Express.js and ejs because of a specific feature I need (importing html). I'm not sure if it has everything I need, because I haven't done much research into what framework works best for me.
I need the feature as soon as possible to get my website back online. Can I use multiple frameworks at the same time? If not, can I use ejs and some other framework together? How easy/hard is it to uninstall a framework if I can't use 2 at the same time?
I know this sounds like I could just google this, but I've tired searching everywhere and all I get is "Top 10 Nodejs Frameworks for 2020" despite doing things like putting quotes around "at the same time".
Edit: just to clear up some things, I do know that ejs and express work together well. I don't know what framework I want to use, and I need to use ejs now.
EJS is designed to work with Express as they are different and complementary things.
Express is a web server framework. EJS is a template engine and is designed to work with Express. They work together just fine.
You can install 100 template engines or 5 web server frameworks and then just code with whichever one you want for any given project. Installing a template engine (or any NPM module) just puts some code on your disk. It sits there dormant until you actually load it into your project with require() or import. So, you can install as many NPM modules as you want and then just program with the ones you actually want to use for any given project. "Installing" an NPM module just puts code on the disk. It doesn't affect your project at all until you actually load and run that code with require() or import.
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 3 years ago.
Improve this question
Backstory: My boss has given me the mission to figure out how to implement react into one of our existing codebases. The idea is to use this to test integration and see if we can slowly migrate out projects over to react. As well to demonstrate to those in charge improvement react can offer over jquery. The problem is I only have less than 2 years of web experience most of which is jquery and near zero of that is react. So I'm struggling to learn the process of integrating react. This is made more challenging by figuring out supporting systems like webpack, npm, and varies libs used with react.
Goal-1: Get a single page running react inside an existing layout that can support modules/libs
Goal-2: Get this page to play well with our jquery menu (option as I can rewrite it)
Goal-3: Get everything placed into its respective folders inside our src/main/webapp
Current state: I have a page loading react and babel using simple script tags. This works but is rather difficult getting any other react libs to load. As most assume npm is being used or commonjs at the minimal. Neither of these I have much knowledge with using/implementing.
What I need: Some guidance on how to implement react into an existing project. I've run over a few articles talking about the process but many lack details needed to understand what is going on in each step. For example getting webpack to export into the target directory so it can be bundled for use in tomcat.
Before this ends up closed, my high level thoughts is get your spring project into a state where it is exposing RESTful endpoints for getting and saving your data. Then build the react project separately from the current java or jquery projects, and have the react ui consume those REST apis.
Apart from that, this is a very broad question you are asking, with lots of ways to solve it, the above mentioned is only a starting point. I couldnt possibly go into complete architecture here..
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 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 building a website that will have facebook-ish features (friends and what not) along with a marketplace and some forums. I've decided to use bootstrap as I'm not a good designer and rather than using Jquery I've come across a replacement for their plugins written in angular (UI bootstrap is the name).
Should I just have one giant angular file for my entire website, aka the plugins for UI one and add whatever else I need to do that, or should I load in two different files? One will be the pre-written plugins and the other one will be the web app needed for that page (for example having the marketplace web app in its own file and include both of them on the same page).
This is my first website so I'm trying to make it as efficient as possible, thanks for the input!
I'd do one for the scripts that you wrote and another for the vendor scripts.
But if you are starting new to gulp or grunt you should really consider using a scaffolding tool such as yeoman. If you use angular-fullstack generator you will see some good examples for both angular and grunt, as well as node.
Definitely not, you should only have one angular component per file. Working with a scaffolding tool such as Yeoman or Slush will make this much easier.
Additionally, I would recommend reading some of the AngularJS styleguides out there. John Papa's guide and Todd Motto's guide are good places to start. Here's a full list of AngularJS resources to get you started. Good luck!
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
I am making a library to generate some custom content. It is pretty verbose, about 1100 lines of code. Although the code is very readable and follows strict naming conventions, I am unsure where to document the API available when including the script file. When including the script in a page, intellisense does not pick up the "public" methods, nor does it for jQuery. jQuery has an awesome website for their API ( http://api.jquery.com/ ), but I do not feel inclined to make something as awesome as that.
Where should I document this custom API?
If in comments, what structure of comments would you suggest?
Edit
My point for intellisense was that even good naming conventions are going to require documented API. So I am definitely interested in a generic approach.
I think jsdoc is pretty popular.
http://code.google.com/p/jsdoc-toolkit/
You would document inline, following the conventions on the link. You would distribute a minified/obfuscated production build for deployment, and the documented one for development (i.e. you could do that)
Edit, you could also find more options here: http://o2js.com/2011/05/01/how-to-document-a-javascript-framework/
It's not generic, but if you didn't mind maintaining separate versions for different editors, Visual Studio's IntelliSense will load and parse XML comments in your JavaScript code. I would suppose MonoDevelop and SharpDevelop could use the same file as well, but I don't think IDEs like IntelliJ or Eclipse would get any use out of it...
HTH.
it depends how complex your api is, for my own small libraries i just make a big comment at the top of the file that contains
a quick writeup of what this is all about
if the library operates on html markup some example code that can be copy&pasted
a list of the functions with their parameters and one-line documentation for each
examples of how the library is typically used
notes/warnings/limitations. there's always something weird going on people won't expect
basically this is what you'd put in a C header file.
i guess you could do all the things i mentioned above in a separate file and then use markdown syntax (i'm too lazy ... also i prefer having everything in a single file).
p.s. some people mention inline-comments (i.e. directly where the functions are).
this is of course an option too. but to me it seems this is convenient only if have the docs auto-generated, it is a horrible way to quickly study the documentation inside the file because it lacks a big picture view.