461–470 of 540 posts
Does anyone know if CSS-in-JS and Context support is planned for RSC, or is there a technical limitation which means they’ll never be possible?
A better name for context is Client Context. On the server can you not just use a pojo?
Context is a really nice way to do this.
Earlier quoted context omitted.
To give some abstractions out of the box, mostly, so you don’t have to reinvent the wheel - the demands of a lot of websites and applications nowadays include interactivity on every level, very fast and smooth ui population, and pretty animations. Sometimes the tools are great for working in huge teams on the same codebase, sometimes it’s for giving a lot of features to a smaller team.
> the demands of a lot of websites and applications nowadays include interactivity on every level The demands of the PM maybe, most users just want something the works and gets out of their way. > very fast and smooth ui population Neither of which your average JS/SPA/behemoth is actually good at. > and pretty animations. I’ll give you this though, JS web apps certainly do rep some pretty animations, often at the cos…
Having seen systems be built up over time that do significant things (or run on many platforms, or have lots of abstractions) a lot of the time the tougher parts are.. well, complicated. Some of those tools are to make things better for a lot of programmers working on the same project. You have to have some amount of structure then. Sometimes it’s so business people can create content.
“Why doesn’t it work simply” is often a business decision.
Earlier quoted context omitted.
echo - command not found (maybe you're on Windows) browse - no browser installed edit - no editor found See, I can do the same thing. In any case you need a toolchain installed to actually program in the language you want to program, even if that toolchain is minimal. Complaining about a toolchain not being installed for the thing you want to do is not very useful.
There is always a text editor and browser available on any OS, yes even on Windows.
Yes, as I said.
Earlier quoted context omitted.
> We are not on some subreddit for a reason. This has other reasons though, like the fact that this site has better moderation and better users in general.
While that is true the current state of reddit UX allows them to succeed by virtue of critical mass gained before they went nuts. If you created a new site with that UX you would get nowhere. The simple truth is people are drawn to websites for what they get out of them.
Earlier quoted context omitted.
http://motherfuckingwebsite.com/ styling is sufficient for technical docs. I hate the scroll hijacking and other shenanigans on modern docs sites.
I think that's a really motherfucking bad piece of advice. Isn't there a version of that which is actually made by someone with some kind of ideas about readability and design? EDIT: http://bettermotherfuckingwebsite.com
Earlier quoted context omitted.
I'm thinking of joining Kroger to help with the Albertsons merger. They are looking for Java developers, cool, some sanity. Learned they have decided to build all new stuff in Go. Like WTSF people? I can find no justification for building mundane business systems in Go. Ugh...managers.
You want to use substantially less RAM and therefore reduce the number of instances/containers you need to serve requests, thereby non-trivially reducing infrastructure costs? Or you're on AWS moving toward a more event-driven or serverless architecture where Java doesn't really have the same flexibility (and you don't want to retool your builds for GraalVM)? Go lambdas are really fast and trivially easy to write. Yo…
They have banished AWS..."competitor." A company that can easily justify their own infrastructure (and save a ton of money) is plunging into the Microsoft Azure hot mess. I could go on and on about a lot of other issues brewing there. Very dysfunctional and panicy trying to look hip to investors in comparison to Wal-Mart and AWS. Basically dragged kicking and screaming into online ordering and pickup/delivery and trying to act like it was their idea (very much had/have a browse-in-store sell you more crap you don't need model).
I'm a life long customer of many of their stores and have been plugged into their tech issues via various contacts for about a decade.
Earlier quoted context omitted.
Unionize already. It's not just about wage, it's about assigning appropriate work to peoples level and having them progress through the most efficient steps to mastery while also completing billable hours
> ...it's about assigning appropriate work to peoples level and having them progress through the most efficient steps to mastery... that's the opposite of what a union does. A union rewards seniority and nothing else.
Earlier quoted context omitted.
Embedded? I would have used the term "infectious". Its complexity and ecosystem will be its Achilles Heel. There are no small number of examples of folks rewriting their React apps in weeks or even a weekend in something like Svelte. SolidJS is "close enough" in code patterns that folks will be very tempted to jump ship. Vue now has a JSX option. But here's the kicker: frameworks like Svelte don't need wrappers aroun…
That could've been said about Java too but it doesn't mean it doesn't stick around. Complexity is orthogonal to sticking power.
There are 1980s mainframes still running COBOL, especially in older, more conservative industries like banking. Those same banks have cycled their public web front ends literally dozens of times since the mid 1990s.
PHP still does A LOT of heavy lifting even if the front ends have bounced between scriptless HTML forms, PrototypeJS, Mootools, YUI, jQuery, Angular, React, etc.
It's not about programming language on the front end (unless that language is JavaScript, but that's a whole other conversation). It's the implementation of layers on top of JavaScript and the browser APIs, and those will remain rapidly shifting sand for quite some time.
Remember, jQuery had about a decade of prominence in the web dev community before the component-based frameworks were released and fairly abruptly drowned it out. That said, jQuery is still far and away the most popular JS library deployed today.
https://w3techs.com/technologies/overview/javascript_library
React isn't going away, but something else will always eventually take center stage and suck all the oxygen out of the room during new web dev planning.
Earlier quoted context omitted.
Evan You (creator of Vue) had a great quote on this: > The pain and suffering of hooks all roots from the mismatch between a dogmatic belief in the superiority of immutability and the harsh reality of the host language that is JavaScript (Feb 25, 2023) This fundamental misalignment with React and JavaScript is the billion dollar mistake.
Nah, I still think React made the right choice. I used to use functional languages so coming to the JS world and seeing that no lessons from that world were learned was disheartening. React, where UI = f(state), is an amazing model compared to the imperative jQuery model of before.
Try SolidJS. Similar ethos to React but far less boilerplate and performance-killing repaints.
Less code is better, functional or not.
Earlier quoted context omitted.
Well, React certainly has succeeded in increasing the client-side complexity, that's for sure. They seem to be making good inroads on increasing server-side complexity as well. Kudos to their contributions to excess CO2 emissions! I have yet to see a React project with more than five contributors fail to turn into a big ball of mud within 18-24 months, requiring either a periodic rewrite or resigned acceptance of tru…
> I have yet to see a React project with more than five contributors fail to turn into a big ball of mud within 18-24 months, requiring either a periodic rewrite or resigned acceptance of trudging through large volumes of mud to get anything done. Not my experience at all, and I've been working with React for years. I've seen companies successfully transition to functional components from class components, all while…
I am glad you are an experienced React developer. React needs more of you, because the vast majority aren't.
That said, I have little doubt your and your team's experience could implement with most other frameworks as well—frameworks with a shallower learning curve, just as much power, greater performance before reaching for useMemo(…) equivalents, and far far less boilerplate code.
But 100% correct: I dislike React.