Adding to this comment. Additionally, the author states you can have multiple panels. For those new to the command line you can do something similar using tmux.
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.
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"?
Thanks, maybe some effortful study of the fundamental properties and manipulation of the DOM would be helpful to me.
>> other useful things one can do in the dev console?
There just seems to be a suprising amount of built in stuff in the browser that does more than rendering text/layout.
I participated in some interesting work at a hackathon a while ago that used a web audio component to signal back and forth between various laptops and phones. It was mostly getting hacked together in the browser dev console.
(I'll come back with some code if I can find it...)
Yes. I wrote a blog series called "How Web Apps Work" that covers fundamental terms and concepts for web dev in general (HTTP, client dev workflow, HTML/DOM/CSS, JS, and data transfer), with some of that more focused on client-side concepts:
I'm a React / DevOps newbie and https://fullstackopen.com/en/about has been exceptional. Just need a little prerequisite HTML/JS knowledge, but even without I think a backend developer could grasp it with a little extra time.
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.
Are most frontend developers even able to leverage the browser console?
If you have transpiled react - which needs its own debugger - I'm not sure what interesting things you could do from there.
I don't think it's part of the culture anymore, unless you're doing vanilla JS or jquery. Happy to hear counter example, but I've had to show even node.js backend devs that the node interpreter actually exists.
There's very little in here that is _unique_ to front end developers. This is more of an introduction to the terminal article. You have a web background and so perhaps wanted to frame this with that context but I think this is better off with a title of something more akin to `Introduction to the Terminal`.
The only thing in here related to web is the `npm` command. Everything else, git, terminal tabs, meaning of `$` is generic to any engineer, front end, back end, ML, AI etc.
What's missing that is critical in any Here's How to Use the Terminal article is showing the `man` command. I think showing other popular commands like `mv`, `cp`, `pwd`, and using `ctrl-r` to reverse search should also be included.
I also think Hyper is not a great terminal to start out with. The default terminal that ships on someone's computer is usually the best. If you're going to use any other terminal emulator, I'd say iTerm2 or Alacritty should be suggested.
The author glosses over the differences between bash and zsh (and fails to mention that Apple used to use bash, and switched to zsh).
The author should have stressed that these and many other shells implement the POSIX shell, which is fundamental to them all from a scripting perspective.
POSIX-1.2017, man7, where Ubuntu man pages are online and other distro manual pages, macOS man page differences, understanding shell built-ins vs commands, etc.
Yeah. I don’t think I have ever once seen a blog article point to primary sources. MDN, for example for web developers, not a primary source.
Sometimes I wonder if people ever ask themselves how people answering questions on Stack Overflow or people writing Medium articles found out what they’re teaching to others.
MDN, for example for web developers, not a primary source.
I’m used to visiting the HTML standard, I think it’s quite friendly considering how much it has grown… CSS2 was still doable for me, but I find the current mesh of CSS standards completely impenetrable at this point. And with JavaScript plus the DOM… yeah, I’ll take MDN as almost primary, an authoritative encyclopedia for web development.
I gave an hour presentation on the basics of CSS to my department as a junior. Other asked how I learned it so quickly and where from.
I just read MDN and W3 for like a month while making slides, then played around for a bit with all I learned on an example app. No one had taken the time to do that before I guess?
you are right, but Hyber automatically has a bit of visual enhancements without needing to configure much and I believe that's the angle, the author is trying to bring to front-end developers who work visually a lot.
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?
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 possible but few people cares about it and it’s often a source of issues. And the last issue are the windows specific bugs in various packages.
The community that write the nodejs packages kinda doesn’t care about windows, and has no reasons to since WSL.
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).
Eventually, I worked around the problem by using a caching system to avoid blowing up the filesystem. It was necessary at the time, but it never felt like a satisfying solution. I wonder if anyone has the knowledge to make native Windows go fast on e.g. a large number of sequential git clone operations.
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.
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 their extremely late realization that they were never ever going to beat Linux at this. Hence WSL. (the Linux Subsystem for Windows :) )
> 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.
In my experience, everything on Windows is a shitshow compared to Mac or Linux. So much so that it’s genuinely hard for me to believe that people use it on purpose. WSL is great because it’s not Windows!
Because the Gates administration produced a primitive command interpreter/environment, that was barely acceptable for the original PC. Then the Ballmer administration blocked console improvements on NT for thirty years. Yes, thirty.
Meanwhile the internet was born and raised on Unix and had a competent (not perfect) design for terminals and shells.
The Windows terminal folks have done a bang-up job trying to make up the deficit, and mostly succeeded in the last few years. But it takes more than tools, it takes mindshare.
Was never interested in powershell, but there are other alternatives from WSL, like git-bash and the yori shell, both of which I recommend.
it's pretty crazy that this article only mention hyper or the built in vs code terminal as it's two recommendations, when excellent terminals like alacritty, kitty and terminator exist and aren't written in javascript
I have been enjoying Foot Terminal of late - minimal, fast, Wayland-first. Not sure about complete feature-parity, but I personally did not miss any feature of Alacritty.
Probably since those terminals are not cross platform and seems like the guide is written in that context. Alacritty is but not the most user friendly for beginners.
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.
Protip: If I'm reading your blog and an Alegria version of yourself made out of plasticine pops up over the text I'm reading and says "Hi there! Can I share a cool thing I'm working on with you?" in an obnoxious word bubble that also covers the text I'm reading... I'm bound to lose interest in your cool thing. And your blog.
Readit News
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
https://www.ocf.berkeley.edu/~ckuehl/tmux/
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.
Is there a "terminal developer's guide to front end"?
Then learn CSS.
Then learn Javascript, and realize that Javascript can be used to write HTML and CSS at runtime. The console is just Javascript in interactive mode.
The browser's dev console gives you access to the current page's DOM, plus anything you can do in JS.
So stuff like `document.querySelectorAll(".foo")` works. Also `fetch()` works within the page's context.
Apart from that, what are some other useful things one can do in the dev console?
>> other useful things one can do in the dev console?
There just seems to be a suprising amount of built in stuff in the browser that does more than rendering text/layout.
I participated in some interesting work at a hackathon a while ago that used a web audio component to signal back and forth between various laptops and phones. It was mostly getting hacked together in the browser dev console.
(I'll come back with some code if I can find it...)
EDIT: OK, here it is: https://github.com/cantino/ultrastound
https://blog.isquaredsoftware.com/series/how-web-apps-work
I've also got a set of slides on "JavaScript for Java Devs", which is a thorough cheat-sheet style overview of JS syntax, concepts, and ecosystem:
https://blog.isquaredsoftware.com/2019/05/presentation-js-fo...
and I helped put together a curated list of learning resources for JavaScript, TypeScript, React, and Redux over on the Reactiflux Discord site:
https://www.reactiflux.com/learning
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.
If you have transpiled react - which needs its own debugger - I'm not sure what interesting things you could do from there.
I don't think it's part of the culture anymore, unless you're doing vanilla JS or jquery. Happy to hear counter example, but I've had to show even node.js backend devs that the node interpreter actually exists.
The only thing in here related to web is the `npm` command. Everything else, git, terminal tabs, meaning of `$` is generic to any engineer, front end, back end, ML, AI etc.
What's missing that is critical in any Here's How to Use the Terminal article is showing the `man` command. I think showing other popular commands like `mv`, `cp`, `pwd`, and using `ctrl-r` to reverse search should also be included.
I also think Hyper is not a great terminal to start out with. The default terminal that ships on someone's computer is usually the best. If you're going to use any other terminal emulator, I'd say iTerm2 or Alacritty should be suggested.
The author should have stressed that these and many other shells implement the POSIX shell, which is fundamental to them all from a scripting perspective.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
Yeah. I don’t think I have ever once seen a blog article point to primary sources. MDN, for example for web developers, not a primary source.
Sometimes I wonder if people ever ask themselves how people answering questions on Stack Overflow or people writing Medium articles found out what they’re teaching to others.
People are too afraid of reading documentation.
I’m used to visiting the HTML standard, I think it’s quite friendly considering how much it has grown… CSS2 was still doable for me, but I find the current mesh of CSS standards completely impenetrable at this point. And with JavaScript plus the DOM… yeah, I’ll take MDN as almost primary, an authoritative encyclopedia for web development.
I just read MDN and W3 for like a month while making slides, then played around for a bit with all I learned on an example app. No one had taken the time to do that before I guess?
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 possible but few people cares about it and it’s often a source of issues. And the last issue are the windows specific bugs in various packages.
The community that write the nodejs packages kinda doesn’t care about windows, and has no reasons to since WSL.
Eventually, I worked around the problem by using a caching system to avoid blowing up the filesystem. It was necessary at the time, but it never felt like a satisfying solution. I wonder if anyone has the knowledge to make native Windows go fast on e.g. a large number of sequential git clone operations.
See e.g. Python, which runs just fine everywhere.
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 their extremely late realization that they were never ever going to beat Linux at this. Hence WSL. (the Linux Subsystem for Windows :) )
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.
It took me a bit to get the settings right to mimic zsh/oh my zsh but now it's fine. It's just slower than mac/linux.
Meanwhile the internet was born and raised on Unix and had a competent (not perfect) design for terminals and shells.
The Windows terminal folks have done a bang-up job trying to make up the deficit, and mostly succeeded in the last few years. But it takes more than tools, it takes mindshare.
Was never interested in powershell, but there are other alternatives from WSL, like git-bash and the yori shell, both of which I recommend.
https://codeberg.org/dnkl/foot
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.