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.
The Front-End Developer's Guide to the Terminal
51–60 of 61 posts
Re: The Front-End Developer's Guide to the Terminal
#52Earlier 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.
Re: The Front-End Developer's Guide to the Terminal
#53Earlier 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.
Re: The Front-End Developer's Guide to the Terminal
#54Earlier 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…
Re: The Front-End Developer's Guide to the Terminal
#55Re: The Front-End Developer's Guide to the Terminal
#56God, 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.
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
#571. 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
#58Earlier 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.
Re: The Front-End Developer's Guide to the Terminal
#59Honest 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…
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
#60I'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 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.