I want to develop projects with js or ts. I learned expressjs and found it's very flexible like ruby on rail. Then I found this nestjs is like RDF. Make the developer write code in the same/fixed way. I think it's good. How do you guys think about it?
Related
I'm learning Vue, and it's ecosystem, and now I read about nuxt.js.
As I understand, this is tool which help us to build Vue apps, but don't we do the same with vite.js?
What's the difference between them?
Vite is a build tool like Webpack, that will basically allow you to work locally on your app and build it for production. It will also bring to the table various loaders, Hot Module Replacement capabilities, environment variables, assets managements etc.
Nuxt is totally unrelated to all of this. It is comparable to Gatsby/Next/Vitepress for a React/Svelte equivalent.
It's goal is to provide more capabilities to VueJS. For example, Vue can only be run as an SPA, meaning that you will not get any kind of indexing with search engines, while Nuxt do have SSR and SSG modes that will allow your websites to be efficiently crawled.
It also brings a lot of Developer Experience niceties: auto import of the composition API, of the components, simple routing, huge ecosystem thanks to all of Nuxt's modules, simpler configuration etc...
It's more like VueJS apps on steroids basically!
Also, latest version of Nuxt (v3) works with Vite out of the box. So, both of them are complementary because you need a build tool to work nowadays in the JS ecosystem + you get more features than just VueJS.
There are tools like vite-plugin-ssr and vitesse (created by one Nuxt's core maintainer btw) who can solve the basic needs of statically generating some routes/etc but it's not as powerful, have smaller communities around it and is overall moving a bit slower.
Trusting people who are behind Nuxt/Vite is also an important aspect, and most of them are well known in the community + are serious daily maintainers!
I've been developing in Aurelia-CLI for about 3 months and like it so far. I think it's a solid framework and obviously escalating in support and usage. That's a good thing!
Before I develop much more of my large app, I'm wondering if I'm using the best build system. I've only tried Aurelia-CLI and am not really familiar with Webpack or JSPM, and therefore I don't know what I'm missing. Are there any clear advantages or disadvantages in using either of the other two build systems, or is using the CLI the most clean and supported approach? Since I'm developing independently, I don't have any external constraints.
Thanks for your help.
UPDATE
This answer is almost two years old. Feel free to research updates and provide another more complete answer and I can replace this answer or point to that answer. Thanks!
Aurelia CLI
Aurelia CLI is great for getting started. It's important to understand that under the covers the CLI is using require.js but proxies the configuration through aurelia.json in your application. This means that you need to understand how to configure aurelia to work with require.js at the moment. Once you need to start configuring to match your workflow or change build steps up it gets a bit cumbersome at the moment. We are working to improve this. There are many features planned for the Aurelia CLI but given at the time of writing this that it is in an alpha / beta state it should generally be used on proof of concept or other smaller apps, not production-ready large scale apps yet.
WebPack
WebPack is arguably the most popular kid on the block at the moment. WebPack is not a module loader, but a bundler. It's important to understand this because while we strive to make Aurelia work great with all module loaders WebPack by default is not in charge of loading modules so a dynamically loaded application requires the developer to expand on this. WebPack is strong in creating optimized bundles and can be easy to use as long as you are comfortable with configure WebPack. WebPack has considerably more GitHub stars due to the popularity from React using WebPack it's hard to say whether the choice is better when using Aurelia simply because of the number of GitHub stars.
JSPM / System.js
Some of the skeletons use JSPM and System.js. The reason is that these are the closest to 'spec compliant' solutions. JSPM tries to help as much as possible when loading from the JSPM registry. If not yet available in the registry you can load from NPM or GitHub directly. From a module loading perspective you use a config.js file that is (usually) automatically maintained when installing dependencies to improve the developer workflow.
Side biased note
On most larger apps at the moment I typically prefer using JSPM / System.js simply because I have a great understanding of the tooling and prefer the control that I am provided. I work on a great number of Aurelia apps that are in production and typically reserve CLI for smaller proof of concept apps and WebPack is a great alternative but I prefer the flexibility and understanding I have with JSPM / System.js at the moment.
The CLI isn't currently feature complete, but it is a much simpler setup. Webpack can basically do anything you want to do, but you'll be maintaining your webpack configuration just as much as you maintain your Aurelia code.
Ok, maybe not just as much, but you'll have to learn Webpack to use webpack. The Aurelia CLI is simple to get started, but has some definite limitations. For example, CSS files that reference external resources won't work w/the Aurelia CLI, but they should work fine with Webpack.
First, I can understand if this post gets shutdown due to its subjective nature.
I believe it's time to re-visit the answers about Aurelia CLI being a second-class tool. I respect both PW Kad and Ashley Grant immensely, but I am just not convinced that a statement like this is true anymore:
There are many features planned for the Aurelia CLI but given at the
time of writing this that it is in an alpha / beta state it should
generally be used on proof of concept or other smaller apps, not
production-ready large scale apps yet.
Notably, I have a production application that way back in the day I started with Aurelia CLI, and changed it to JSPM precisely for the reasons noted. But recently, I rebuilt the same app from scratch using the CLI and I realize that it is much easier to use, particularly managing modules and publishing! And this is an app with Google Maps, Google Analytics, Auth0, DevExpress, Bootstrap, etc.
Just think it is time to give Aurelia CLI a little love. It's ready.
Aurelia CLI is the most preferred option with this announcement.
http://aurelia.io/blog/2017/08/18/aurelia-cli-webpack-update/
Now It has more flexibility for your choice of preferences.
I want to integrate the Foundation (5) front-end framework with the Yii (1.1) PHP framework for developing a web application.
Since i am new to both of them and learning to use it as i move along with the development, I am unaware as to how will i be able to use both of them for the same project.
Logically speaking i understand that the Foundation 5 directory has to put into the Yii project directory structure. But i am not sure as to which directory to use in Yii project for that.
I tried researching on the web, but since i am new i am not able to understand which is the right way to go about achieving what i intent to.
Step by step instructions to do it would be appreciated. Thanks in advance.
First you have to realize that Foundation is just a collection of html, css and javascript. So you use it like every other html, css javascript in Yii.
Then if you are learning do not create something yourself for now. Use something that somebody else has done: http://bootstrap3.pascal-brewing.de/ Here are instructions for using twitter bootstrap (another kind of Foundation) in Yii. With examples and everything. Start using it, be happy that you manage to do stuff right away... study the code when you get stuck, understand what happens in there.
http://yiifoundation.2amigos.us/
They have done a good work in packaging it as an extension for yii.
I recently found out about Yeoman and found it can be very useful in improving workflow. However, I noticed it seem to focus only on client side projects? ExpressJS is a popular framework that seems to be been missed out?
However, I still think its possible to integrate it into Yeoman, perhaps with custom generators? Is there something like that already available? If not how might I start?
It will not be as simple, along with Express, I will be using Jade/Stylus the defaults express uses for precompiling HTML and CSS.
The initial goal of Yeoman was to tackle front-end web apps.
Opinionated workflow with the back-end is planned, but is currently a bit cumbersome to do. Use of Jade/Styles is possible, but a bit ugly.
All this will be much easier with Yeoman 1.0, which will be more customizable and will let you use whatever grunt tasks you want.
I'm writing an API using a non-rails framework. I normally use Cucumber for BDD and testing of API's when I'm writing them in RAILS.
Is there a strong reason not to use Cucumber when I'm testing an API written on top of node.js (or any other framework, really)?
Strong technical reasons to not do this might include:
Dependency of Cucumber on Rails
The existence of a better framework for node.js
Some other technical reason I don't know about.
First of all, Cucumber doesn't depend on Rails.
I have been trying out some different javascript testing frameworks to try to work out what I want to use. So far I like mocha with expect.js for unit testing but I haven't found anything for integration testing a node app that I'm happy with. It's possible to do with mocha and supertest, and I've also tried cucumber.js which is getting there but it's not as mature as the Ruby version - so that's what I intend to use.
I can't think of a good reason not to do this, apart from it may be harder to do things like set up fixtures - but that may well be a good thing as it would force your tests to deal only with the public interface of your API - as it was intended to be used.
As said cucumber has nothing to do with rails.
You could perfectly use it to test API's written in any languages.
In case you want to use node.js full stack cucumber.js is a good option.