Live data from Hacker News

The Front-End Developer's Guide to the Terminal

joshwcomeau.com

51–60 of 61 posts

Re: The Front-End Developer's Guide to the Terminal

#51

God, please don't use Hyper, it's literally a terminal built with Electron, possibly the slowest practical way to implement a terminal. If you're on macOS or Linux, use the built in terminal. If you're on Windows, use Windows Terminal [0], the new one, not cmd prompt. [0] https://github.com/microsoft/terminal

God, please don't use the built-in terminal on macOS. Use iTerm.

Why? Terminal.app has the lowest latency of them all on Mac!

Re: The Front-End Developer's Guide to the Terminal

#52
post #32

Earlier quoted context omitted.

Windows is not great for NodeJs based dev stacks, which are very common for web development these days. Because JavaScript developers tend to write their development tools in JavaScript. NodeJs is not great on windows because the packages/modules model uses many tiny files and the Windows filesystem, NTFS, is extremely slow for this kind of load. Another problem is compiling C/C++ NodeJS dependencies on windows. It’s…

Part of it is Windows being Windows, but part of it is languages/runtimes treating Windows as a second-class platform, which is understandable but a predictable source of problems. See e.g. Python, which runs just fine everywhere.

The situation has probably improved (WSL of course is an option now), but when I first got started, I found developing in Python on Windows to be a nightmare of compatibility problems that I simply wasn't experienced enough to figure out. Lots of things I needed just wouldn't install and I'd see inscrutable C compilation errors or log messages about eggs and wheels. I actually ended up switching to Linux for work and personal use because of it.

Re: The Front-End Developer's Guide to the Terminal

#53

Earlier quoted context omitted.

That's true but it's another thing that beginners will have to install. It's better to let them use the basic tools first and then suggest iTerm afterwards, in my experience teaching others programming.

Honestly you can get iterm2, zsh and oh-my-zsh installed in like <10mins and have a great looking terminal that you never have to mess with again it’s not really a newbie overhead.

the thing with newbie is no overhead and teach them lessons. leave tweaking and aesthetics for their own time. if they really are into the terminal, they will find their own way and time to decorate em.

Re: The Front-End Developer's Guide to the Terminal

#54

Earlier quoted context omitted.

Windows is not great for NodeJs based dev stacks, which are very common for web development these days. Because JavaScript developers tend to write their development tools in JavaScript. NodeJs is not great on windows because the packages/modules model uses many tiny files and the Windows filesystem, NTFS, is extremely slow for this kind of load. Another problem is compiling C/C++ NodeJS dependencies on windows. It’s…

No kidding. When I was heavily contributing to Julia's Pkg (which uses roughly the same model for modules as NPM, at least in terms of the file system), our test suite would run roughly an order of magnitude slower on Windows. This was very annoying on days where a lot of PRs where in the pipeline. I poked around the problem about for a while, and eventually came to the same conclusion (but I'm no Windows expert). Ev…

fun fact: the solution the Julia package manager currently uses is to just read from a compressed tar file because ntfs is so shit that decompressing on the fly is faster.

Re: The Front-End Developer's Guide to the Terminal

#55

Earlier quoted context omitted.

God, please don't use the built-in terminal on macOS. Use iTerm.

Why? Terminal.app has the lowest latency of them all on Mac!

Small, slight improvements. The switch is practically seamless.

Re: The Front-End Developer's Guide to the Terminal

#56

God, please don't use Hyper, it's literally a terminal built with Electron, possibly the slowest practical way to implement a terminal. If you're on macOS or Linux, use the built in terminal. If you're on Windows, use Windows Terminal [0], the new one, not cmd prompt. [0] https://github.com/microsoft/terminal

God, please don't use the built-in terminal on macOS. Use iTerm.

Quick dismissal with no reason is quite a waste of space.

I think the rendering is better and faster than iTerm.

I still use iTerm for a few features but there's no reason not to recommend the default terminal to people.

Re: The Front-End Developer's Guide to the Terminal

#57
Three things that you could add to the article that would benefit most beginning terminal users:

1. Variables

2. Pipes

3. Shell substitution (using `` or $())

It is important for new programmers to understand that their shell is a REPL - this is something that isn't clear to them. Teaching them about variables and composition drives this point home and just unleashes their intelligence. This has been remarkably effective in my experience mentoring new programmers.

Re: The Front-End Developer's Guide to the Terminal

#58

Earlier quoted context omitted.

That's true but it's another thing that beginners will have to install. It's better to let them use the basic tools first and then suggest iTerm afterwards, in my experience teaching others programming.

Honestly you can get iterm2, zsh and oh-my-zsh installed in like <10mins and have a great looking terminal that you never have to mess with again it’s not really a newbie overhead.

That setup takes about 10 minutes to launch too. Slap fish on the default terminal and you have something that launches fast and works out of the box and requires less additional stuff to install.

Re: The Front-End Developer's Guide to the Terminal

#59
post #25

Honest question: Why is web development such a shitshow on Windows that that every single 'tutorial' like this doesn't even attempt to make it work, and instead just immediately directs Windows users to WSL?

I don't want to pick on the OP, but as perhaps an old timer, it is surprising to me that this isn't obvious. Linux and free and open software is what gave birth to the web, and so quite naturally working with it evolves better and more naturally there. Bill Gates and Windows famously absolutely missed the boat on the Internet nearly entirely. And yes, to this day they're still trying to catch up -- this is evident in…

> Bill Gates and Windows famously absolutely missed the boat on the Internet nearly entirely

This is revisionist, butthurt Linux people and Netscape investors always repeat this lie.

Time has proved that nobody is willing to pay for a browser but it has to either be free or come as free with the OS.

Time also proved that people who know that they are top notch in their field want a top notch quality of life. If you are one of those top notch people and go work at Microsoft you end up with a beachfront property in Miami and boat not smaller than 40ft, if you take your skills to Linux you end up with a pat on the back and maybe become a moderator role in some obscure online forum.

Microsoft won because smart people understand that when you start talking about compensating them with exposure or social status instead of money that's the signal to get the hell out of there. If you don't you end up in a cult.

Re: The Front-End Developer's Guide to the Terminal

#60
post #6

I'm kind of trying to go the other way. I am amazed at how productive great front-end/js-first developers are with even just a browser console --- but I am totally flumoxed by this environment, and have trouble sinking my fingernails into the first ledge on that learning curve. Is there a "terminal developer's guide to front end"?

I am an amateur "full-stack" developer for some 10 years (with some 20 more years of various dev before that). I administer systems through a command line :)

I found that the easiest way to learn front end was to take a framework (I use Quasar which is very complete) and learn on that. If you have some knowledge of development you will progress quickly. Before that you may want to read and try the introductory docs for Vue.js

This will give you a solid hammer to address all nails, even the points that are not really nails.

The advantage is that it will work fine, and you can then try to optimize (or de-nail) your projects.

Post reply on HN