Installing applications from ports

I just got myself a new ThinkPad and I have installed Freebsd 13.0 and this time I wanted to install all my apps via ports and not binary and my question is - Should I install multiples ports like this

# cd /usr/ports/x11/xorg/ && make install clean BATCH=yes && cd /usr/ports/x11-wm/i3/ && make install clean BATCH=yes && cd /usr/ports/x11/i3status/ && make install clean BATCH=yes && cd /usr/ports/x11/i3lock/ && make install clean BATCH=yes && cd /usr/ports/x11/dmenu/ && make install clean BATCH=yes

I am trying to do others chores around the house :)

Will this work without any issues ?

That's one way of doing it. Maybe do not use the && and do each stage separately so you can see what is going on.

Alternatively, you can use a ports manager. There are many and you can read about them in the handbook. I use ports-mgmt/synth

As an aside, your subject "your input needed" could go for most threads here. You could change it to something more about the thread itself.
Will this work without any issues ?
No. Some ports may become to be broken.
All your process will fail on the first error because of &&
Rewrite your script for processing a list of needed ports independently one from other.

Read the full manual ports(7)
config-recursive     Configure OPTIONS for this port and all its dependencies using dialog4ports(1).
Make target 'config-recursive' can save your time.
It download and configure all dependencies BEFORE the building process.
So you will can run 'make' and have a rest.

To prevent unpredicted delays of the process you can use the scenario:
cd /usr/ports/*/somelargeport
make config-recursive
<Complete 'config' of the port and all dependencies, and you will not interrupted later>
make install
[make clean]

If you will build ports via remote connection then I advice you to use a 'terminal multiplexer' like sysutils/screen or sysutils/tmux.
It allows you to detach a remote console session without interruption of a build processes.
Also it makes the process independent from a management computer.
ports-mgmt/portmaster will prompt for all of the options at the beginning. The config file for portmaster(8) is /usr/local/etc/portmaster.rc. To save some time, it can use packages for build-only dependencies, which doesn't change options and doesn't have much effect on the way a built program runs. PM_PACKAGES_BUILD=pmp_build

Also, you can put the list of ports in a file, with a space or new line separating them. use the category with a / and a port. It works for ports, and for packages, while packages will ignore the category and /.
x11/xorg x11/xdm

Then, you can use pkg or portmaster `cat pkg-list.txt`. (The ` is the button of SHIFT ~, it's not the single quote.)

Also, for consistency in options, these can be put into make.conf, for instance:

                LIBX11 LTO
I want to install with default values and don't want the system to prompt me the blue screen for options.... Is BATCH=yes a good option?
Agree with im. There's just one little exception: ports/packages containing kernel modules (they're typically named *-kmod). In FreeBSD, the ABI is kept stable for the whole lifetime of a major release (e.g. 13.x), but this is not necessarily true for the in-kernel ABI. So, a kernel module built on e.g. 13.0 might be broken on 13.1. In the short time period when two minor releases of the same major release are supported (IIRC, 3 months), this can be a problem. There's only one repository for each major release, and the official packages will be built on the older minor release until it's EOL. So if you already use the newer release during this time period, you might want to build *-kmod ports yourself.

But apart from this exception, building yourself with all default options makes no sense. You'll end up with binaries that are bit-by-bit identical to the official packages – except if some "automagic" dependency is accidentally picked up by a build on your machine. The best way to avoid that is building packages in isolated environments – the already mentioned "synth" does exactly that, as well as FreeBSD's "standard tool", ports-mgmt/poudriere.

Some people seem to think modifying CFLAGS et al to build binaries "optimized" for your local machine was a valid reason for building yourself, even when using default options. An idea that seemed to be popular with Gentoo users, btw 😈. Well, that's not a good idea. In almost any case, performance benefits aren't even measurable. But there's a relevant risk optimizations lead to broken software. Just don't do it.

The only valid reason for building yourself is using custom build-time options, either by setting port-specific options or by modifying DEFAULT_VERSIONS. And if you start doing this, use a tool (poudriere or synth) that builds packages in isolated environments from the ports, so you can install them with pkg, that's the best way to keep your system maintainable.
I agree with Zirias , he's got a good post that hits the important points.

I'd like to point out that the Handbook discourages mixing ports and packages. The way I deal with that is to make the decision to stick with either BEFORE installing FreeBSD at all. I re-installed FreeBSD many times over before finally settling on ports. For me, that was a learning experience, and I'm savoring the results of those efforts. Yeah, it takes time and effort, but you'll get to savor the results afterwards. :)
astyle, sticking with one option is a safe way to avoid trouble, cause there are pitfalls when "mixing". But still, you can do it.

The single biggest pitfall is quite easy to sort out: mixing them from different branches (typically ports from "latest" with packages from "quarterly") will never work well.

I think there's a "gold standard" for mixing: Use a tool that builds a local package repository, but can put pre-built binary packages in there if it detects there would be no difference. ports-mgmt/poudriere-devel can do that, as well as AFAIK synth, although I never tried the latter myself.
… the Handbook discourages mixing ports and packages. …

If the discouragement is too blunt, then the Handbook should be improved.