"What they mean" isn't correct or reasonable and is largely part of the same grumbling groupthink that willfully refuses to come to grips with the realities of the tools they've decided they don't like.
React is not large, is of moderate complexity (most of the complexity of "a React app" lives well outside of React itself), and can be stripped down to a fully static templating language without much effort. As I've linked elsewhere, I turned React into an email templating engine once because I don't like Handlebars; rendering JSX as static, no-JS HTML is a one-liner when you throw it a React component.
My hot take: there's a general feeling of looking down on "web devs" or UI/front-end stuff. It's not really necessary to have React for a portfolio site, but it's not really an issue if they do.
I wouldn't consider myself a frontend developer--I've run infra teams, built backends, built desktop applications, all that too--and I'd definitely agree with that.
There's a lot of strange smugfacing about using fit-for-purpose tools that translates into the shitting on people by the old-at-heart and the underinformed. Like, stepping away from JavaScript for a second, you still see people getting mad about C++ on HN and defending the use of C outside of a micro because "just be a good programmer" even though maybe a few dozen such good programmers have ever existed. It's very weird and it's one of the things about this profession that bothers me a lot.
I am fortunate that I have reached a place in my career where I can simply refuse to have that sort of person on my team.
Beautifully said. Ironically (or maybe not), the worst engineers I've worked with in the last 15 years are strictly backend engineers who vocalize how frontend is easy / isn't real software engineering / etc.
One’s free to code their portfolio in COBOL if they find a way to do it.
It’s the underlying narrative of the “oh look, there are things called HTML + CSS + JS that work so well and they’re even faster” behind this kind of posts that tbh makes them quite insufferable.
Agreed--it ignores that JSX, even baked statically, was a pretty nontrivial life improvement for front-end development because you got to get away from text manipulation as a first-class citizen.
I guess I don’t? Are you referring to the framework comment? Next.js is a great example of a react _framework_. It’s opinionated, it provides tools to make a fully-fledged website. If you just drop react into a site with a script tag, you get what react offers. You get a way to manipulate a virtual dom and render components.
Instead of saying “you understand what they mean”, please give an example of how I mis-stepped. I don’t want to come off as antagonistic for no reason.
I'm baffled by how how many web developers have the attitude of "React projects are too complex, let's put another layer of abstraction on top of React to simplify things". Of course, usually for things that should never have been React to begin with.
Anyway, good for that guy that he discovered Vanilla HTML and CSS late in his career, but I also don't see how this is front page worthy.
My comment even got downvoted. There’s certainly some React diehards around I guess who really don’t want to hear that their overconvoluted approach could be simpler and leaner 95% of the time.
Ever heard of “being ironic”?
I will never fully understand such a devoted stance on policing tone.
Especially when the comment is not even half as harsh as half of the other comments that pile on, even calling this post unworthy of the home page.
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.
"A convoluted SPA" is fully orthogonal to React. If you're making a blog into a SPA, that's a you problem. It's been possible (and recommended for many things!) to just bake a static website with React and use JSX as a templating language for a long time.
React is completely happy to spit out a DOM tree as HTML for you; wiring up the in-browser JavaScript side of React is optional. This is how static site generators like Gatsby or NextJS work (with some hacks that as a user you don't really care about) and (eliding some detail) how React Server Components now work generally. I've also used it to generate email templates[1] with some success, too.
I use JSX because it's a nicer templating system than EJS or similar. It allows me to write components to encapsulate reused fragments rather than text manipulation. And I like it, which counts for something.
Candidly, this is something that people who fulminate about React probably should know before they start talking.
Obviously there's a spectrum. A static website just means the files are served statically from a folder, and routing is just the folder path. You can still serve JS files and have a static website. If you put an alert on a button, you're not suddenly a SPA
It's more than that: you can just call methods in ReactDOMServer to get a DOM tree. The tools to wrap this vary widely; you can use Gatsby (ehh) or NextJS (yeah!) to do it if you want a full-featured framework around all of it, you can use something like react-snap if you want something simple and less all-in, or you can just call them yourself and plop some files in a build directory.
Generally, a static website refers to any website where the server just serves files rather than running application code for each request. JS runs on the client.
For example, I've been working on a character generator for the Inquisitor tabletop game. It's completely static because I just SFTP the build output to my webserver, but it uses React and JSX.
You're missing OP's point. The website can be fully static (even without any JS) but you could still use JSX/React to generate it (during build time, not runtime).
If you've ever had to build a static website from scratch, with the same navigation, footer etc. on each page, and without using frames, then you'll appreciate the amount of work that a templating engine saves you (whether JS-based or else).
And you're missing the other GPs point. Even when building a static website, you might want to reuse components. Or use shared components. Or do some logic. Or easily compose things.
Note they said "JSX as a templating language". Why worsen the experience using Python + Jinja when you're just building a static site.
Mm, herein lies the problem, I was not thinking about Python at all, and I suspect we are all thinking about various different tools.
A static site is necessarily not dynamic though, as soon as you need dynamic features you need to reach for one tool or another. "Static site generators" are just dynamic sites with a pre-compile step instead of JIT.
When I think of a static site, I am thinking HTML, CSS, some server side includes for header and footer. A bit of vanilla JS if you absolutely need it. Apache and nginx both have native template includes so you don't even need an extra language like py or php.
No I was saying the opposite, a static site is necessarily not dynamic.
I would not want to pre-generate those pages. Your static files on an S3 bucket are still served by a webserver.
Anyway, can you honestly say, hand over heart, that server side rendered JSX or React is a robust and simple solution comparable to SSI or I don't know, a bit of copy pasting? Of course not. Server side rendering is a complex toolchain that will rapidly and constantly deprecate. My blog has been sitting on the same "stack" for 13 years, takes me 5 seconds to set up a new post.
I have worked on countless JS projects, sometimes they don't even build just 6 months later without faffing about with packages and versions.
Yeah at this point I have literally no idea what you're talking about?
The thread is about pregenerating static content, "can you honestly say, hand over heart, that server side rendered ..." is way off base. Seems like"static site" means "assets can be plopped into any server that can serve static assets" to one set of people, and to others it's an invitation to balk?
I'm in the former camp, if that wasn't obvious. If you want to talk about serving static assets to host a blog, I'm down. If you want to compare server stacks, I'm out.
Yeah I was going to point out this is getting pretty obtuse but didn't want to be rude. I think we're talking past eachother, or I'm missing something.
My TL;DR I guess, pregenerating/SSR, is a more complicated toolchain than is needed for a simple site (and what I interpreted the topic comment's point to be). How you serve it wasn't really the issue, that is the easy part. I might leave it at that, cheers for being gracious.
Static doesn’t mean no JavaScript. Usually it means it’s not rendered on the server.
Every time i start making a static website, i end up needing to include a table (or some other structured display of data) and then just switch to JSX to render the data with a loop. Sometimes i then render it as html and deploy, and sometimes i deploy it as react. But that’s how i usually end up using React even when static.
Indeed, static just means that the site files can be on a CDN and not need to change. Technically, SPAs are also static, if they spit out pure HTML, CSS and JS files that you can put on a CDN.
You use JSX the same way you'd use PHP - it just compiles into HTML. In this case, you just save the output after compiling it once. (as you can with the dozens or hundreds of non-JS options that do the same)
It's also been possible for 30 years to do the same with languages like PHP, ColdFusion, etc, no build steps necessary, and HTML is your "templating language".
You totally can, but for my money that's kinda not great. Because HTML isn't your "templating language", PHP et al are, and you aren't templating around the DOM with typed objects, you're templating around text with all the pitfalls that entails. Object structures save time, reduce errors, and give you more to-the-programmer natural tools for composition and reuse (just call a function that returns a JSX object! give it typed parameters! declare victory and go have beers!).
I wouldn't go back to doing text manipulation to generate HTML, because I value not having to make sure I've escaped all my quotes.
You can also write classes that return data and custom tags that return rendered html.
<cf_PeopleList queryObject="#people#">
I'm not saying we need to go back to those languages necessarily, but I think there's a ton of misconception about how those languages can be used, and quite a bit of reinventing the wheel in the Javascript world.
Sure, of course you can in some contexts and with many asterisks (though in PHP it is literally text munging and that's what you get).
But even, granting your correction: in the CF example you're writing representation and logic in two separate contexts. JSX does not do that. JSX is JavaScript and the constructs that JavaScript provides work without fail with the constructed trees (which need not be DOM trees, e.g. react-three-fiber) you're generating. It puts a lot of strain on the assertion that you must-repeat-must separate these concerns, which hasn't been materially true really at any point in my career all the way back to JSP or Velocity templates where (much like ColdFusion) you had worse tools for one context than you got for free with the other.
While JSX and something like CFML (or hell, Angular) look similar when you squint, this is a different thing. The closest equivalent is something like Scala or Visual Basic XML literals, which never took off; JSX is no-bullshit a step change in consistency and productivity and it's awesome.
That's not true, though; JSX can be entirely prerendered server-side. If you don't write client-side JavaScript, you're not going to get client-side JavaScript (modulo maybe a thin hydration layer if you're using particularly old tools, but nothing running pervasively). Your code becomes HTML files. It's more Hugo/Jekyll than it is "a SPA".
I am unaware of a major PHP framework that is designed around similar, though it may exist.
I think a culture has been created where anything resembling server-side rendering (other than Node spitting out JSON) is legacy to be avoided ..... until of course the Javascript creates its own convoluted version of server-side rendering, which is revolutionary and the new hotness.
The main benefit to JS being used as a server side rendered and client side rendered language is that you have a lot more control over which parts you want on the server vs the client, and you can introduce hydration where needed. You technically could do that in PHP and other non JS languages but that's annoying because you'll be mixing multiple languages together and it would be more clunky. So yes, there is some "revolutionary" benefit to having everything in JS/TypeScript.
My least favorite JavaScript argument is “Instead of using one good language for the backend and one lousy one for the front end, we’ll rewrite ALL the code in the lousy language to keep it easy!”
I fail to understand why anybody would use JavaScript - a language so bad everybody uses a series of wrappers around it - for anything they didn’t absolutely have to (e.g. client code).
The entire point of the MVC architecture is to allow you to pick the best tools for the job.
EDIT: I’m not saying PHP is good, though it’s better than JS. And TypeScript is still JavaScript with extra steps.
I mean, Django makes it very clear and very trivial which parts are serverside and which parts are client side, and I assume rails is the same way. I don't see how JS has any advantage over their approach.
Really? Firefox says the contrast ratios meet WCAG AA.
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.
* 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.
In my case, we wanted to gather feedback on a product we were launching. Because we wanted to move fast, we’re in a regulated industry, and our initial tests were simple, we decided to built a simple “chatbot” style feedback tool.
More generally, forms. Forms always seems to morph into more than just simple inputs.
Thanks for the reply, forms are such a pain in the ass. Of course you need hard input sanitizing on the backend but just helping people fill out a form correctly can require some JS.
That doesn't really parse. React as a thing is some pretty thin DOM manipulation and some helper stuff. Are you thinking of something like Next or some all-in React+Redux stack?
As misfortune would have it, I spent a significant fraction of the day reading the implementation of hooks for fibers. There's nothing light weight about virtual Dom, reconciliation, and micro task queues.
The reason react was developed is mostly null at this point. Modern javascript is so fast and plesant it's hard to imagine many real reasons you can't stay entirely within vanilla.
I am friends with the original 2 React founders who I met at facebook. I don’t need to Google, I’m asking because the comment was lacking substance and wasn’t adding value to the conversation.
Even many sites that are large and complex would benefit from being a server-rendered app. I've come across way too many sites that break in bizarre ways, and all they are doing is displaying text or HTML forms. Every time I check, they are React or Angular sites.
I think this is a pretty awesome statement. I'm always unreasonably pleased when I see a web page that embraces appropriate simplicity.
> 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.
Is it even correct to automatically update the year? Shouldn't the year be whenever the work was created or revised? Which could be set at build time.
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.
I am of the opinion that what you are suggesting is correct. You don’t want a programmatic copyright because you want the copyright to reflect the date created as that when the right begins, and it continues from there without need for refreshing.
I think it's also incorrect because it's getting the date client side. so it would just display the local client's year, not necessarily the correct one.
You can achieve very good results with Next, by using SSG, SSR and ISR. That implies being very comfortable with React. Otherwise there’s tons of solutions for a blog scrnario.
It doesn’t really matter what you write your personal blog in lol I’ve created some egregiously over engineered personal projects over the years just for the sake of learning a new technology
> I became a dev when everyone was hiring for React, so React is what I taught myself immediately after bootcamp in the scramble for a job
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)
Agreed, but it's so rare nowadays though. I still remember when I saw a junior frontend dev struggling to get some element to look differently when hovered in React. They went though loops and hoops to style it using CSS-in-JS and mousemove, only because they didn't hear about :hover.
Yeah that's gonna work out great when the entire app is built using weird overcomplicated solutions to simple problems, let's just clean it all up later! Doesn't matter how you write your code as long as it seems to work, well deal with all the bugs we discover later!
The proper way to do it is to do code reviews and teach newbies how to do things like this. Ideally they should have asked about it(or just googled) before the review.
I think "well just fix it later if needed" is asking for trouble and you're basically just writing legacy code.
The problem is that if the end state you want is a clean codebase implementing your use case, that’s also easy to modify and extend, then the mess such a developer will produce is a much worse starting point than starting from scratch.
Business doesn't fund "fix it later" -- it just becomes tech debt. You have to push to do it right the first time or approve merges you can live with in perpetuity.
My favorite experience with Bootcamp folks was someone who came in do an interview, and she could talk, was professional, had nice looking blogs, etc. and seemed really awesome on paper. However, I had her do a really simple React exercise, and she was producing some really strange code like using Ruby inside of a JavaScript onClick handler? lol
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.
I think this is an unfortunate side effect of boot camps trying to impart best practices on their students. They don’t really have time to learn and apply the actual practice well, but the names stick with them.
While that's possible, it's a lot more fault tolerant to use the declarative :hover rule, than it is to handle it procedurally. The browser knows how to handle odd pointing devices, touch states and won't ever have to deal with uncaught errors in a mouseover/mouseout event.
for sure, was just an example that there are apis, that could have been reached for even without CSS knowledge that would make it easier than trying to get the position of the mouse on the screen, the position of the target element and if they overlap
I think most of this comes down to the fact that these bootcamps are there to freshly bake people to work on the latest shiny tech completely ignoring the basics of computer science. I, like yourself, was very lucky to attend a university course that gave me exactly those fundamentals.
I worked at a boot camp that started off CS-"heavy" (relative to other boot camps). Unfortunately, they gradually just turned into a React shop to try to maximize profits. There were students who had been in the program for 4 months and couldn't write FizzBuzz. The placement rate was poor because students couldn't do technical interviews. I understand this particular company has made improvements since then (I've left), but it was fucking grim at the time. I now teach at a state university.
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.
Not always. The bootcamp I worked for did 2 months of pure HTML/CSS/JS and then did a personal project for another month of which students almost exclusively used HTML/CSS/JS, some did React. Only in the final week did I teach React.
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.
None of it, as those skills were not asked for by the labor market. And I tend to agree with it (as a CS bachelor and master graduate). What you need to learn is programming in a specific way. CS teaches a broad scope of things that are all helpful but they are not strictly necessary to know, especially not as a junior. I think doing a CS degree after having done web dev for 3 years in the field is a much wiser decision.
For example, I never really had to know how a compiler works or assembly, but I know it. I only needed my data structures and algorithms knowledge once. My knowledge of UML? Meh
You are describing the distinction between a scientist/engineer and a technician. Technicians only need thin slices of knowledge about the underlying abstractions.
The problem with _aiming_ only high enough to create technicians, though, is that you create a good chunk of _operators_, instead, who make do with both thin _and shallow_ slices of knowledge, making them poorly suited to any kind of generalization.
I think there's a place for what are essentially factory workers: taught specific skills for specific jobs. The problem is I think most don't understand the trade-offs and have unbalanced expectations.
For me, coming online in the late 1990s, I've never experienced as much "education density" as I did when learning HTML to build sites on Geocities. For those who didn't experience that, circa 1997, you could either upload files or write HTML in nothing more than a textfield. No highlighting, no WYSIWYG, no page builders. Just you and a blank canvas (if you were lucky you might use an editor like Homesite or HotDog)
Yeah, I was just chatting with another principal eng friend recently where maybe a whole new generation of programmers may be several degrees away from topics like operating systems, compilers, computer security and networking.
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!
This is sort of a FUD argument IMO. There will always be people who focus on low level software engineering. There will always be people who want to learn about the hardware of computers much more than the software. Proportionally there will almost certainly be less (we don't need nearly as many computer engineers as we do software engineers) but as long as the salaries remain competitive there will be plenty.
It's not just this but also the fact that there are many more layers of abstraction now than there were even 10 years ago, never mind 20/30/40 years ago, and the real world incentive to understand the entire stack of those abstractions is virtually nil in modern engineering environments.
It depends on the intention of the person trying to learn. When someone is starting and asks to me which language/tech is best to start, I always ask, what do you want from learning tech? Are you comfortable with X salary? Do you want to make a career of it? Go international/remote? Etc.
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
We had an intern last year, and I got a chance to do a 1-on-1 with him later on on his time with us. He was looking for some insights from the engineer in the org with the longest career in tech.
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!)
And that's why learning is best left as an individual pursuit. For me, it is always best to start with a complex system and then work backwards, understanding the thoughts and decisions that went into each step along the way. When I start with the basics I don't get a feel for the bigger picture and it means nothing.
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.
Well, yeah, but you'd have to be at least twice my age to have been starting out when this tech was in its primitive state. Comparatively, I'm still a spring chicken.
I have a strange feeling about the industry. It seems better received to know a framework 30% (or enough to make simple/intermediate things) even if you know next to nothing about the underlyings rather than the opposite. If you're an ES6 master but can't mesh well with react tasks / react convos in daily you will look as less useful.
I disagree. It's like telling someone who is somewhat interested in building cars to learn how an engine works before having them on the ground playing with the actual car parts. The issue becomes not whether they'll learn, it's about whether they WANT to continue to learn. Most people when they want to start coding, would rather want to build cool things. And then later on, they'll naturally be more interested in the fundamentals.
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.
There's space between "read this giant c++ tome" and "you're good to go with a couple of months of React", quite a lot even.
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 just think for some, bottoms up learning has quite some disadvantages and was an approach that I've used for a long time with okay results. It would get me to where I wanted to be...but it takes way too long sometimes.
Of course there are people like you mentioned though who only do top down learning but just never go into learning the fundamentals ever, which is another problem in its own right.
I've gradually taken towards "always learn as if it's a sport" as the approach to learning. Which, if you look at the sports science recommendations is:
* Isolate highly specific techniques into drills.
* Then go directly to practicing live gameplay. Ignore intermediate exercises.
And the approach with programming can, in fact, do this, if presented properly: definitely, we know how to isolate things into short follow-along examples. What tends to be missing is the "live gameplay" element, because it's hard to set up sample projects that are complex enough to reveal the need for a particular technique.
I don't know anyone who has ever learned programming bottom up. Now growing with the technology as it evolves is one thing, but being taught in that manner is miserable because it's unmotivated and the reason for the low level is the high level not the other way around. You just use even handlers in JS and then when you hit some confusing behavior you dive in at learn about how event propagation works.
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.
The opportunity one is really the core. A friend went through a bootcamp. Father of 3. I think this is the most viable option to join the field for him.
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.
My website is also completely static, but made with React. That means no React at all at runtime, it is completely static. React does not automatically mean dynamic. I get all the benefits of both. I love the flexibility nextjs provides here.
I don't get the value prop of all vanilla. The overhead involved in building a react app is nearly nil with all the tooling we have. Sure CRA was slow, but vite makes things sub-second again.
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.
It’s not a value prop, it’s just a statement of remembering to use the right tools. You even mention this yourself, just not explicitly, when you say “react app” and “vanilla site”. They serve different purposes and I’ve worked with many people who do not understand because react is all they know.
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?
> you're still fetching everything it's just without the waterfall
It's exactly because of the waterfall. If I have to make 3 roundtrip fetches, and the latency of each is increased by 150ms, then eliminating 2 subsequent fetches will save me 300ms.
> 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.
I have used an uncountable number of websites that are extremely janky, slow to load, and overall unpleasant to use on mobile while traveling on trains and busses between cell towers. Some of that can be attributed to ads but the reality is you don't need SPA's to serve news. Remix is cool in that it lets you develop like an app but serve like a website.
> The overhead involved in building a react app is nearly nil with all the tooling we have.
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.
It takes work to keep up with the latest-and-greatest in modern web frameworks. 100% agree.
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.
Because in a professional setting the guy who takes over after you also has to know or learn whatever tech you chose.
I worked on a team maintaining solutions in React, Vue, angular, Svelte, JQuery and more. It sucked. Basically every task I ever did there was my first time doing that thing with that framework.
I totally agree, simpler is better. Except for extenuating circumstances, teams working anywhere remotely close to each other should aim to stick to the same technologies and practices. If that's vanilla js, sure, go for it.
I'm not arguing everyone needs to move to react. I'm saying the opposite. Stick to the tools you know. I once worked in a strict java-angular.js shop, and it was awesome. Everyone was familiar with the tech and the company saved energy otherwise wasted on tool-related decisions.
My point is this
> it is more of a flex in this SPA era to show you know how to make a website the old-fashioned way.
is not valuable to me at all. If I were giving advice to a new programmer, I'd tell them learn the basics first, like your html, js, css, and then familiarise yourself with one of the frameworks. Then if you want to build your portfolio, build it in whatever you like, but for people at that level, it can be a great chance to practice and show off their skills to employers. If you're shipping 2MB, who cares.
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.
I've tried learning Ember, React, and Vue and have tapped out pretty early. Now I'm learning how to build a site using only vanilla JS and doing everything from scratch unless I find a reason to switch it. I think I'm making decent progress.
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.
Ditto on Ember, React, Vue and Elm. Was a jQuery minimalist, nut now moved on to Haxe-HTML5. Yes, it compiles Haxe to JS. But the JS it generates maps back to the Haxe very simply, and it's straightforward to debug in Chromium dev tools. There a nice declarative XML system for widget layout. It's up to you to choose how much you do declaratively, and how much in .hx code.
I'm confused by this, why do you think npm is needed? It just acts a central repo, you're free to self host the JS file yourself or pump it through a CDN.
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.
People use package managers because it lets us find everything in one place, install it and keep it up to date easily.
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.
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.
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.
I built my simple site with just Go, no libraries of any kind. Two years later it is such a dream to never ever have any dependency chores to do.
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.
Actually, yes. The conventional wisdom these days is to do everything in React (or something similarly bloated).
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.
I've just joined a team recently and had a chat with the head of product. We will work on a tiny internal app, it has 3 pages: sso login page, Excel template upload page where earlier uploaded templates are shown as a card and if you click on them it opens a dashboard: a map with markers, a bar and a pie chart. This is the whole thing.
This guy asked what we will use in the front-end. I said react and he was like "amazing, good job, it will be great" and the talked about we should always use react. So yes, there are places where react is used without question.
Also, we will use snowflake as a backend while indexing would make everything a lot faster and the budiness logic is done by 800+ line sql (stored procedure).
> 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.
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.
> My portfolio needs to be nothing more than the HTTP equivalent of a tri-fold brochure.
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.
Recently tried no framework, Jekyll, Next, Astro and finally SvelteKit. The only one I liked was SvelteKit.
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.
I'm glad this works for them. Personal websites and portfolios are a reflection of people on their journey. If it is built with React, maybe they are learning React. If it is vanilla JS, maybe they appreciate the flavor of vanilla.
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.
191 comments
[ 3.5 ms ] story [ 242 ms ] threadAlso I find the colour scheme hard to read but maybe it’s just me.
It’s a great way to templatize your code. Is it the only way? No. Do you even need to templatize your code? No.
React is not large, is of moderate complexity (most of the complexity of "a React app" lives well outside of React itself), and can be stripped down to a fully static templating language without much effort. As I've linked elsewhere, I turned React into an email templating engine once because I don't like Handlebars; rendering JSX as static, no-JS HTML is a one-liner when you throw it a React component.
Using React for a static website is totally fine.
So is not using it.
Being weird about it is not fine.
There's a lot of strange smugfacing about using fit-for-purpose tools that translates into the shitting on people by the old-at-heart and the underinformed. Like, stepping away from JavaScript for a second, you still see people getting mad about C++ on HN and defending the use of C outside of a micro because "just be a good programmer" even though maybe a few dozen such good programmers have ever existed. It's very weird and it's one of the things about this profession that bothers me a lot.
I am fortunate that I have reached a place in my career where I can simply refuse to have that sort of person on my team.
Instead of saying “you understand what they mean”, please give an example of how I mis-stepped. I don’t want to come off as antagonistic for no reason.
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.
I use JSX because it's a nicer templating system than EJS or similar. It allows me to write components to encapsulate reused fragments rather than text manipulation. And I like it, which counts for something.
Candidly, this is something that people who fulminate about React probably should know before they start talking.
[1] - https://github.com/eropple/rx-mailer
For example, I've been working on a character generator for the Inquisitor tabletop game. It's completely static because I just SFTP the build output to my webserver, but it uses React and JSX.
If you've ever had to build a static website from scratch, with the same navigation, footer etc. on each page, and without using frames, then you'll appreciate the amount of work that a templating engine saves you (whether JS-based or else).
Note they said "JSX as a templating language". Why worsen the experience using Python + Jinja when you're just building a static site.
A static site is necessarily not dynamic though, as soon as you need dynamic features you need to reach for one tool or another. "Static site generators" are just dynamic sites with a pre-compile step instead of JIT.
When I think of a static site, I am thinking HTML, CSS, some server side includes for header and footer. A bit of vanilla JS if you absolutely need it. Apache and nginx both have native template includes so you don't even need an extra language like py or php.
So if you wanted to say, pre-generate those pages with the header and footer already there, you would ... ?
I would not want to pre-generate those pages. Your static files on an S3 bucket are still served by a webserver.
Anyway, can you honestly say, hand over heart, that server side rendered JSX or React is a robust and simple solution comparable to SSI or I don't know, a bit of copy pasting? Of course not. Server side rendering is a complex toolchain that will rapidly and constantly deprecate. My blog has been sitting on the same "stack" for 13 years, takes me 5 seconds to set up a new post.
I have worked on countless JS projects, sometimes they don't even build just 6 months later without faffing about with packages and versions.
The thread is about pregenerating static content, "can you honestly say, hand over heart, that server side rendered ..." is way off base. Seems like"static site" means "assets can be plopped into any server that can serve static assets" to one set of people, and to others it's an invitation to balk?
I'm in the former camp, if that wasn't obvious. If you want to talk about serving static assets to host a blog, I'm down. If you want to compare server stacks, I'm out.
My TL;DR I guess, pregenerating/SSR, is a more complicated toolchain than is needed for a simple site (and what I interpreted the topic comment's point to be). How you serve it wasn't really the issue, that is the easy part. I might leave it at that, cheers for being gracious.
Every time i start making a static website, i end up needing to include a table (or some other structured display of data) and then just switch to JSX to render the data with a loop. Sometimes i then render it as html and deploy, and sometimes i deploy it as react. But that’s how i usually end up using React even when static.
I wouldn't go back to doing text manipulation to generate HTML, because I value not having to make sure I've escaped all my quotes.
For instance, CFML:
<ul> <cfoutput query="people"> <li>#firstName# #lastName# </cfouput> </ul>
You can also write classes that return data and custom tags that return rendered html.
<cf_PeopleList queryObject="#people#">
I'm not saying we need to go back to those languages necessarily, but I think there's a ton of misconception about how those languages can be used, and quite a bit of reinventing the wheel in the Javascript world.
But even, granting your correction: in the CF example you're writing representation and logic in two separate contexts. JSX does not do that. JSX is JavaScript and the constructs that JavaScript provides work without fail with the constructed trees (which need not be DOM trees, e.g. react-three-fiber) you're generating. It puts a lot of strain on the assertion that you must-repeat-must separate these concerns, which hasn't been materially true really at any point in my career all the way back to JSP or Velocity templates where (much like ColdFusion) you had worse tools for one context than you got for free with the other.
While JSX and something like CFML (or hell, Angular) look similar when you squint, this is a different thing. The closest equivalent is something like Scala or Visual Basic XML literals, which never took off; JSX is no-bullshit a step change in consistency and productivity and it's awesome.
I am unaware of a major PHP framework that is designed around similar, though it may exist.
If you mean rendered once for all, i.e. statically, there are some PHP wikis, frameworks, and caching plugins that can/do work that way.
I fail to understand why anybody would use JavaScript - a language so bad everybody uses a series of wrappers around it - for anything they didn’t absolutely have to (e.g. client code).
The entire point of the MVC architecture is to allow you to pick the best tools for the job.
EDIT: I’m not saying PHP is good, though it’s better than JS. And TypeScript is still JavaScript with extra steps.
TypeScript is an excellent language and I agree, no one should be using Javascript anymore.
edit: hm, she says it's a yaki imo / satsuma imo color theme. I love yaki imo.
https://www.bitecode.dev/p/hype-cycles
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.
I use a tool called CCA and it takes font size into consideration.
I use a high resolution screen and the text is rather small - hence why it's harder to read.
On mobile it's OK.
* 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.
More generally, forms. Forms always seems to morph into more than just simple inputs.
Why was it developed?
Proceeds with a distracting animated image of the old portfolio, thought that was funny.
> 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.
In this case I think I'd argue that the JS solution is the most simple to implement+maintain.
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.
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)
Give that "senior CSS developer" a day and figure out how to manage state, then what you get is a crap.
The proper way to do it is to do code reviews and teach newbies how to do things like this. Ideally they should have asked about it(or just googled) before the review.
I think "well just fix it later if needed" is asking for trouble and you're basically just writing legacy code.
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.
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.
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.
For example, I never really had to know how a compiler works or assembly, but I know it. I only needed my data structures and algorithms knowledge once. My knowledge of UML? Meh
And so on
The problem with _aiming_ only high enough to create technicians, though, is that you create a good chunk of _operators_, instead, who make do with both thin _and shallow_ slices of knowledge, making them poorly suited to any kind of generalization.
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!
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
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!)
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.
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 just think for some, bottoms up learning has quite some disadvantages and was an approach that I've used for a long time with okay results. It would get me to where I wanted to be...but it takes way too long sometimes.
Of course there are people like you mentioned though who only do top down learning but just never go into learning the fundamentals ever, which is another problem in its own right.
* Isolate highly specific techniques into drills.
* Then go directly to practicing live gameplay. Ignore intermediate exercises.
And the approach with programming can, in fact, do this, if presented properly: definitely, we know how to isolate things into short follow-along examples. What tends to be missing is the "live gameplay" element, because it's hard to set up sample projects that are complex enough to reveal the need for a particular technique.
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 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.
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.
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.
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?
It's exactly because of the waterfall. If I have to make 3 roundtrip fetches, and the latency of each is increased by 150ms, then eliminating 2 subsequent fetches will save me 300ms.
> 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.
I have used an uncountable number of websites that are extremely janky, slow to load, and overall unpleasant to use on mobile while traveling on trains and busses between cell towers. Some of that can be attributed to ads but the reality is you don't need SPA's to serve news. Remix is cool in that it lets you develop like an app but serve like a website.
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.
I worked on a team maintaining solutions in React, Vue, angular, Svelte, JQuery and more. It sucked. Basically every task I ever did there was my first time doing that thing with that framework.
I'm not arguing everyone needs to move to react. I'm saying the opposite. Stick to the tools you know. I once worked in a strict java-angular.js shop, and it was awesome. Everyone was familiar with the tech and the company saved energy otherwise wasted on tool-related decisions.
My point is this
> it is more of a flex in this SPA era to show you know how to make a website the old-fashioned way.
is not valuable to me at all. If I were giving advice to a new programmer, I'd tell them learn the basics first, like your html, js, css, and then familiarise yourself with one of the frameworks. Then if you want to build your portfolio, build it in whatever you like, but for people at that level, it can be a great chance to practice and show off their skills to employers. If you're shipping 2MB, who cares.
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.
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.
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.
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.
I don't have to use any of Hugo, Jelkyll,..., because i can cook my own SSG toolkit right inside React.
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.
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.
P. S. Needs to be even more garish. Remember the "space pigs" theme of FastTracker II? Man, those were the days.
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 guy asked what we will use in the front-end. I said react and he was like "amazing, good job, it will be great" and the talked about we should always use react. So yes, there are places where react is used without question.
Also, we will use snowflake as a backend while indexing would make everything a lot faster and the budiness logic is done by 800+ line sql (stored procedure).
I ranted about this in another thread a few months ago and I stand by what I wrote: https://news.ycombinator.com/item?id=34857513
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.
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.
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.