react-boilerplate for development is using older libraries - reactjs

I am looking to develop a React JS web app, using react-boilerplate for development
https://github.com/react-boilerplate/react-boilerplate
But the above boilerplate doesn't seem to be updated quite often, which boilerplate should be used for building simple web apps

Create React App is pretty much a single command setup with all the basic React boilerplate code for you from the command line.
Although as others have said, ideally you should look into setting up your own boilerplate to suit your own needs and maintain it as you best see fit.

There is not a simple good answer to this problem. Ideally, you should create your own boilerplate and maintain it over time, because only you will know what are your most common needs. There are no perfect boilerplates and almost every boilerplate is opinionated.
You might try to create a boilerplate for yourself from React CRA or other sources that might fit your needs in a great measure. It takes time in the beginning, but after a while you might update it every few months to make sure it is up to date and make it the starting point for all your new projects.
Sometimes a good point of inspiration would be the Yeoman Generators. Take
a look here: Yeoman Generators

React-boilerplate no longer to maintain, it has some library doesn't upgrade yet. You can try this repository, same about structure and way to use.
https://github.com/react-boilerplate/react-boilerplate-cra-template

React-boilerplate is not being maintained. You can use ARc which is a React starter kit based on the Atomic Design methodology, while I'll suggest you use create-react-app which is strongly recommended by the community.

Related

Do I need a localization framework for a small PWA in React?

I'm working on a small web application in React and I want it to be in two languages. I've seen several localization libraries like react-i18next and react-intl but I'm hesitant to install something maybe too big for such a simple application. Is there a lightweight library to do simple localization or should I look into a more straightforward approach like a string replacing component?
Thanks!
If it is a small project you probably do not need it.
However, it would be a really good experience to write your own localization component, integrate it with redux and opensource it.
Also, there are some simplified versions already available so you can reuse it and/or contribute into.
Here is a simple react-localization implementation.

Why use create-react-app when I can just use react in the browser?

I want to use react/redux. So I did "create-react-app test" after 5 minutes, I get a directory with 22,538 files and takes 131MB.
Meanwhile if I google, "jsfiddle react redux" and look at the first link I get a jsfiddle with just a few files it loads, all within the browser.
So why should I use create-react-app versus just loading a few dependencies in the browser? Is the overhead worth it? Is it mainly due to webpack?
I use create react app (CRA from now on) since react redux has too much boilerplate to manage things.
CRA is basically a startup-kit: that explains why has so much basic package asset in terms of import.
I can assure you that maybe you'll pay the cost to use redux on large projects (and dependencies...and packaging!!!).
Mostly depends on teams anyways, if you need to standardize how to operate on things and your team is large, Redux should be useful since this way of act avoids unexpected implementations because "there's a way" to do things.
my personal preference is not to use CRA. it was meant to be a starter kit for developers who want to learn react without wasting time on configuration and setting up the environment.
It is a fantastic learning tool if you start from scratch because all the magic is hidden from your view, you just focus on React and let cra take care of the details. but production projects are not that simple to handle. there are a lot of requirements which may come in and your cra may not support it. as it was meant to be a generic tool for learning react. you can eject it but then you should really avoid ejecting it as the config is extremely complicated.
with cra you are missing a very important base of your project. ie the webpack.
The way cra solves this problem is by hiding all the config by default, so after starting your project you are not exposed to Babel, Webpack, dev/prod environment, or any other config.
You start learning with a tool that does everything for you, but when you are ready to know how things really work under all that, what are you supposed to do?
With cra you have an eject script that can uncover all the config that is hidden beneath.
If you feel so adventurous to do it, you will find yourself into a really huge and scary config, meant to do a lot of stuff and designed to not be exposed to the end user.
if you are a senior developer then you must really try to configure your own webpack config according to your project requirement. webpack, babel, etc are very important because they are not just for react. you can use them in any modern javascript project. as a senior developer, you should really know how things are working, in case you decide to remove a library and add another you should know where and how to do it. and really should not rely on a tool that makes things simple for u.
All of this is not a hard rule to follow. but my personal experience .

Does it make sense to use Vuejs and Reactjs on the same project

So my question is pretty self explanatory. Does it make sense to use Vue.js and React.js together on a same project ?
No. Both Vue.js and React are for the same purpose - building UI components.
The only situation that it might make sense is that if you are doing a migration. From Vue.js to React or from React to Vue.js.
But I think in most scenarios it doesn't worth to do this kind of migration. Both Vue.js and React are really great. So my conclusion is, no, it doesn't make sense.
Both Vue and Reactjs are javascript Frameworks that are in themselves self sufficient. Also since both do the same job it makes sense to use either one of them.
If you use both Vue and React together it will make it more and more difficult for you to share states and data between parts written with Vue and Parts written with React.
What you would have to do is to keep them as independent modules.
Also both Vue and ReactJs have different APIs so it makes it difficult for a developer to code it out too. This will lead to bad patterns and hacks developing in your code which will later lead to issues such as maintainability and feature extension.
If you have control over your entire code, its better to just evaluate what better suits your purpose and then choose that framework for development of the entire app.
P.S. Certains exceptions to using both of them together will include a migration from framework to another in progress or your app having various modules in your App each of which independent from one another and included as plugins in the main code.
You can use the two together but you will have to carefully consider the architecture. You might have to consider something like the Microfrontend architecture but remember this comes at the cost of a lot of complexity and is not suited for all use cases.
Good intro to Micro Frontends

AngularJS 2.1.0 official scaffold & style?

Google knows best… but they're inconsistent!
The official ng CLI generates a scaffold one way, whereas the official tutorial chooses a different way.
I'm not talking just directory layout, typings.json vs types in package.json choices are also particularly worrisome.
What style am I meant to work with?
Angular 2's tutorial basically just shows the quickest and easiest way to get up and running with the framework. It omits mentioning things that could scare away a potential newcomer to the ecosystem, it is meant to be simple.
angular-cli on the other hand actively incorporates best practices, latest technologies like Webpack 2 Beta and tries to give developers a piece of software to quickly scaffold and develop scalable production apps without worrying about build-tools and configuration.
QuickStart
This is not the perfect arrangement for your application. It is not designed for production. It exists primarily to get you started quickly with learning and prototyping in Angular
angular/quickstart/README.md
angular-cli
The Angular2 CLI makes it easy to create an application that already works, right out of the box. It already follows our best practices!
https://cli.angular.io
See also: https://angular.io/styleguide

What do Yeoman Generator's add "really" to Ionic Projects

I don't understand why the generator-ionic (along with other ionic + Yeoman project)s are so popular.
I don't see what the advantages are in using a yeomen generator in this case, this is.
I understand why the Ionic framework is useful in a Cordova project (as we all know, the UI, ngCordova plugins, it uses AngularJS, ect) but what specifically does the Yeoman component add that a basic Ionic project doesn't already have or that cannot be easily added with a bower install.
It seems to me that the Yeoman ionic projects just seem to be unnecessary bloat and can lead to more errors and library issues. I just do not see how components like karma and grunt (as opposed to ionic using gulp) fit into help with development.
True, you can set all this up by yourself. However, imagine setting this up on each and every project that you start. Kind of cumbersome, don't you think?
That's why some people tend to create these generators - to save you (if you like) the time of having to scaffold your application every time from beginning. Usually they provide some features (about which you can read on the Github pages) or they may even enforce some kind of project directory layout (which may help with big projects).
All in all, you don't have to use them, or stress about them. For instance, I personally don't use them on every project, but I appreciate the community effort and when I want to try something quick I tend to test them from time to time to see how they've evolved.
Don't hate, donate ;) (Sure sure, I know you're not hating, the statement just seemed appropriate).

Resources