A better education path (in a bootcamp, university, book, youtube, whatever) would start with the fundamentals and build it from the ground up... not the other way around.
(I just realized how lucky I am for being taught in the best possible order, from the ground up... first the basics... and how so many people didn't have this opportunity)
I argue that this is why schools are terrible for teaching. They try and teach fundamentals without making kids interested in the topic first. As someone who taught many kids, the struggle is always making them interested, not the rate at which they learn.
I remember when I started programming, the worst advice i got was on stack overflow, that I should learn from this thick c++ textbook as a start... Wasted couple months on that book, where the concepts went through one ear and out the other, became extremely disinterested. Only until someone told me to just learn Javascript and build things was when I progressed and learned rapidly. Took me only a year after that to get a job with me becoming interested very quickly on learning fundamentals from there. If I kept learning from a book, it would've taken me several years before I got to even building. It's silly to assume someone who learns from the top down can't learn the fundamentals at some point.
Now I've learned game development and currently learning ai on the side. I've tried bottoms up learning many times, but it is incredibly slow to get my goals. Top down and learning fundamentals after you get your hands dirty has been the absolute fastest way for me to learn new topics. With bottoms up, while you may learn many of the basics, you also happen to learn a bunch of extraneous information that you may never use, and will forget because you don't use it.
From my experience with bootcamp people, it leaves them woefully underprepared. But my sample size is small: 3 people, 3 separate bootcamps, similar results. They knew one portion of react, no fundamentals.
And sadly a couple of them really took to using Copilot. So they don't know how to do what they're doing and couldn't explain their submitted code.
Just the worst of all worlds there. They were effectively incredibly expensive Copilot subscriptions (not to belittle them, they did that themselves)
I had some friends being honest about only wanting some good money, not top high, but in comfortable zone, and preferably fast, in less than a year. With that kinda of mentality, I usually recommend going straight to the most used stack where I live, React, Angular or Java.
They are usually just starting and want to feel the waters, I tell about the basics and link some online courses. Everyone can start on one tech and learn another later.
I myself learned frontend before high school and only had a formal education on software years later on college, and now I feel like pretty proficient on software as a whole. The answer to it, is usually giving some time and experience
I think a failing of a lot of these bootcamps is they encourage people to present themselves as more experienced than they actually are. I don’t mind someone who’s starting out, and has a lot of potential, but please be honest about your skill level, as it just disappoints the interviewer and misrepresents you.
Give that "senior CSS developer" a day and figure out how to manage state, then what you get is a crap.
Once in a while, (lower level) software needs to be rewritten as underlying invariants go out of fashion. Think filesystems due to hardware access patterns etc. - to unlock magnitudes of performance improvements. The scary part is maybe we'll never have enough programmers to know how to do "the hard stuff" anymore. I hope I'm proven wrong though!
The biggest single thing I think I ended up doing during that session was getting him to re-frame his thinking from "I'm a React developer" to "I'm a developer", emphasising how all the fundamentals remain the same, just the nitty gritty implementation changes a bit from time to time. It was interesting to watch that lightbulb moment happening with him as we were talking, while also frustrating that the bootcamp etc. training he'd been through had so fundamentally set his thinking up wrong from the outset (since had a few more interns that came via different bootcamps, and it has been the same story with each!)
This was around 2017, most students didn't become React devs. Most students did end up in the JS ecosystem, but 30% did something else [1].
[1] When I say 30%, that's not an official statistics. It's just on my impression what I've personally seen from students who connected to me on LinkedIn. It's a guestimate at best.
But yes, to anyone in a boot camp, get yourself some Khan Academy or whatever you need to get the fundamentals. This is an art, a science, and a craft, and you need to study to show your pride in that craft.
I'm glad I've only been around the industry for 25-some-odd years. We already had many high level abstractions to work with. If I were old like you and had to start with flipping toggle switches, I'm sure I would have zoned out immediately and never progressed further.
I could handle flipping toggle switches now, but only because I've been engrossed in the bigger picture thanks to those high level abstractions.
Nobody learns block how devices work before filesystems because it's backwards. Filesystems are the motivation, block devices are a means. The processors course in college comes after the intro programming and after systems programming.
So the options are bootcamp or not. Not from the ground up or not. Bootcamps cater thst group. Ideally skilled, smart, willing to learn but on a tight schedule and in need of a job.
This also changed my mind a bit on how to think about bootcamps. They are a way to give people who couldn't afford a longer education on the discipline an entry point.
All the success or failure is still on the person, and there is a lot to learn, but I respect everyone going through the hard path.
So let's take you, for example.
How far back did you start ? Did you write a basic HTML site in notepad?
Did you program your own TCP/IP stack?
Of course you at least configured the actual Web server using Apache on your Debian vps, right?
See how tired this argument is?
As for me, I just directly manipulate the platters of my hard drive using a magnetized needle to encode sequences of ones and zeros.
Also I find the colour scheme hard to read but maybe it’s just me.
If you started your career in the last 5-10 years then yes, it might be news.
An entire generation of web developers has been trained to think that every app big and small needs to be a convoluted SPA. The results are a disaster.
* as it’s simplest, it’s a really easy to use templating tool.
* there are a tools that compile to mostly static HTML, so not performance hits
* theres almost always something that pushes you to want some JS. React is handy to have. It also opens the door to all of the the community packages. No sense to re-invent the wheel.
What besides shitty/illegal tracking code and cookies do you need to include? Honest question.
edit: hm, she says it's a yaki imo / satsuma imo color theme. I love yaki imo.
The site has poor contrast ratio - fails all accessibility guidelines for text contrast ratio requirements.
For me, the main problem is the font weight. I'm sure it looks better on high-density displays, but it is way too thin to read comfortably at a regular pixel density.
> Coding a basic vanilla multi-page application (MPA) saves time in development (goodbye babel/postcss/SSR config) and builds are fast (this site builds in less than 1.2 seconds).
I'd hope that builds would be on the order of a small pile of milliseconds! (or zero: a site like that could just be handcoded, really).
> I'm only using these 2 lines of Javascript to add the current year in the footer copyright tag
This could also be eliminated. At least in the US, there is no legal reason to add a copyright notice at all, and you certainly don't have to add a year. Those requirements were removed years ago.
But, if all you want is the year, why not do that server-side? Or bake it into the html and set up a bit of automation to replace the year with a new one every Jan 1.
Another advantage of setting it in the build is it'd show even without javascript. If I disable JS, no copyright statement at all appears on the page. So if it was really necessary to declare your copyright, then would it mean anyone who disables JS can freely infringe?
I agree just leaving the copyright out of the footer would be best.
In this case I think I'd argue that the JS solution is the most simple to implement+maintain.
It's like when remix people talk about progressive enhancement to me. Sure, cool, you can do things differently. But why? If you already know the ins and outs of a framework or tool and are productive with it, use it. I'm never gonna hire someone because of how much they "flexed" with their vanilla site, just like I won't hire someone who flexed with their cool fresh-from-bootcamp react animations.
All the tooling we have is exactly why React has an overhead which is far from nil. Every package goes through a period of changing its best practices, some go through multiple. Entire packages go in and out of season, seemingly depending on the phase of the moon. There's a new bundler every year, each with its own quirks. For some things there's 4 "go to" packages that achieve the same thing but take a different path to get there. You have all these packages and tooling you have to learn, stay in touch with, maintain and fight against. All of that so you could ship megabytes of JS that ultimately just changes some text on a page. You can do all of that with vanilla JS and spare yourself the headache.
But if you're already doing that, because you work in the field, or are passionate about it, then that checkbox is ticked.
I wouldn't do all that JUST to build a static portfolio, but if you already learnt and kept up with all of that stuff, then I still don't see why not use it.
npm install -g vite
vite init my-react-app
npm install
npm run dev
The most popular build tools have mostly stayed the same. Some things have fallen out of fashion sure like gulp. But overall the abstractions built over complicated tools have only improved and only made it easier to get started with web dev. I’d argue it’s never been easier to start a modern statically typed react app.
Remix is an improvement over react as a framework though because you can fall back on native browser functionality where the framework will fall short (high latency, slow devices, no JavaScript).
100% agree here. But if I were going to rewrite a whole application, I'd need a really good value prop.
> high latency, slow devices, no JavaScript
I don't see why high latency would be improved by remix, you're still fetching everything it's just without the waterfall. I've yet to see a modern-ish device (going back to iPhone 7s) that struggle so hard with rendering that progressive enhancement is valuable.
Are there modern devices which are that slow? Or browsers without js?
Why was it developed?
I even wrote my own simple test framework that shoves the results on the bottom of a page. After adding a few features I decided to switch it to Jasmine.
One thing I'm noticing is how often you need npm which I find very annoying. How is a JS library or framework anything more than a single JS file that you have to include in your page? Why is everything npm this and yarn that? Jasmine has standalone install instructions that are easy to find but I can't say the same about Jest.
I'd much rather do `npm i whatever` than having to hunt down a bunch of git repos and copying files over and when they're outdated having to do the same thing to update them etc.
Jest is a different story, it's not a single JS file and has many dependencies. Running it globally is an easy way to reduce the need to include it per project.
Because, you know, users just love seeing a bunch of grey boxes shimmer and dance on a white background for several seconds before the magic really starts to happen.
So any exercise which demonstrates that there just might be an alternative to this philosophy should be applauded.
This has nothing to do with React, this is a placeholder rendering strategy employed by many different frameworks and languages.The rendering strategies are orthogonal to the framework.
I've written many websites entirely in React but you'd never know it, because they're all SSG. I've done hybrid SSR + SSG + placeholder/delayed load.
I could have done all of that with .NET, Elixir, etc. too because it has nothing to do with the language/framework.
Proceeds with a distracting animated image of the old portfolio, thought that was funny.
So while one doesn't have to know JS, it will definitely get you through a lot of doors. And not knowing it, or being too stubborn to keep your skills in it polished will keep you in the doghouse.
Someone forgot to tell these folks:
https://buttercms.com/blog/how-to-create-a-blog-with-react/
https://www.sanity.io/guides/build-your-first-blog-using-rea...
(and many more)
I'm firmly in the camp that React and similar frameworks are overused. However, the point is that there's a large part of our industry that is bought-in (and in many cases, built businesses around) the concept of "React all the things" and it's encouraging to see push back.
Not interested in reinventing the wheel (no framework), dealing with lots of boilerplate and over-complication (Next/React) or using multiple UI libraries (Astro). SvelteKit is a fine balance between simple and providing enough functionality that allows me to focus on generating content with minimal friction.
Instead of making sweeping statements about the choice of stack, I appreciate that someone took their time and built something of their own. Congrats. Next thing they should do is an accessibility audit and learn from it.
P. S. Needs to be even more garish. Remember the "space pigs" theme of FastTracker II? Man, those were the days.
When I started my first Node/Express project I picked pug too but quickly realized it was too removed from vanilla HTML I was seeing in the books/MDN and switched to Handlebars. Immediately discovered that Handlebars didn’t have a built in support for something fairly basic I needed and I either had to roll my own extension to it or look for something else so I ended up switching yet again to EJS and I’m still using it a year later today. EJS is perfect if you want vanilla HTML + vanilla JS.
Not really. Doesn't your experience, reflected in your CV and the technical interview, already prove that? A portfolio site is nice to have, particularly if you're a designer and want to showcase your work, but it shouldn't be a requirement for a developer, frontend or otherwise.
While the paperfuge is cool and may even reach higher RPM/G than some bench top ultracentrifuges, it cannot do so consistently.
Putting "Samples were centrifuged at whatever amount of G:s yours truly could crank out on a hand built paperfuge for a solid 10 minutes" in the materials and methods section doesn't exactly scream reproducible science.
Before that I had a Phoenix site and I feel like every time I touched it (months apart) I had to update something.
Not such a big deal at work where monitoring for security vulnerabilities and updating dependencies is paid work that we make time for but I hate that kind of busy work on my own time.
My concern here is that your website _is_ your portfolio - including how you build it. It's not just the content and long narrative that's going to sell you. This new approach has switched from showing what you can do to telling what you can do.
I don't have to use any of Hugo, Jelkyll,..., because i can cook my own SSG toolkit right inside React.
