391–400 of 756 posts
Earlier quoted context omitted.
Yes because loading 500 different css and js files is not a problem for performance.
They literally just said "unless the frontend is doing something profoundly stupid".
Earlier quoted context omitted.
"People who disagree with me on the topic of """best language/framework""" are ignorant and lack experience to see how {my_favorite_language} is actually the bestest"
I literally said the exact opposite. I don't care what language you use as long as it's type-safe. Any language that lacks type-safety is completely inappropriate for large-scale projects. There's no seasoned developer on the planet who disagrees with that sentiment. None. Zilch. If some guy claims to be #1) decades experienced and #2) doesn't like type-safe languages, then he's lying about either #1 or #2 or both.
Earlier quoted context omitted.
> The hooks API is just awful Hard disagree. Hooks are 100% what is best about React these days and custom hooks make organizing or encapsulating and sharing behaviors between components a total breeze.
This is something that I just don’t get, in the olden days, when you wanted to encapsulate logic and state and share it between instances you would just use a singleton service. But now when classes are “bad” for some reason (when the whole point of a class is encapsulation of state and logic) you get weird stateful functions that makes everything hard to track with complicated API.
For example, `api.fetchInfo()` would want to feed Loading | Success(T) | Error(E) back into the React component call-site when they change.
EventEmitters come to mind but aren't without their own issues like subscription leaks. And you have to track component arguments in order to know when to call the service again when they change which is a classic source of complexity.
Hooks provide a solution for this since they themselves are just nested React lifecycle constructs (like useState + useEffect).
The fundamental magic of react is that it lets you write code that renders O(n) UI states in a functional manner (i.e. by returning the HTML you want) rather than O(n^2) UI state transitions in a mutable manner (by mutating the page via nested callbacks), and somehow makes it kind of fast-ish People love complaining about React, but I don't know if they remember the pre-React world where you had to write the code to…
Earlier quoted context omitted.
> It's easier to build a bad website in React than it is to build a bad website with just plain HTML/CSS. I think many people would argue that it is easier to build a good web app in React than plain HTML/CSS/JS.
Sure, but most people think they’re building a webapp when they’re really building a website.
Earlier quoted context omitted.
"People who disagree with me on the topic of """best language/framework""" are ignorant and lack experience to see how {my_favorite_language} is actually the bestest"
I literally said the exact opposite. I don't care what language you use as long as it's type-safe. Any language that lacks type-safety is completely inappropriate for large-scale projects. There's no seasoned developer on the planet who disagrees with that sentiment. None. Zilch. If some guy claims to be #1) decades experienced and #2) doesn't like type-safe languages, then he's lying about either #1 or #2 or both.
I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…
> React will be unseated like jQuery got unseated when someone makes something that looks nicer. The solution is WebAssembly. Make your code look as nice as you want, as readable as you want, in whatever language you want. No more JavaScript limitations.
But you accept a whole host of other limitations with WASM. It's a trade-off. You still need to access the DOM, which can't be done directly from WASM. Maybe someday it will happen? Okay, so use canvas instead and do all UI inside WASM? That seems like reinventing the wheel that is Javascript + DOM. WASM has plenty of uses, but replacing Javascript probably isn't where it shines. Javascript is still great for front-end tasks, WASM is good for lots of other things that aren't user-interface related, like running ffmpeg inside the browser. I'm doing this on a project and the front-end was easy to create a drag-and-drop file upload in javascript (React) and handle all user interface stuff like progress bars, etc. ffmpeg runs as WASM code doing whatever the Javascript tells it to do. I can't imagine also writing a front-end in Rust or something else that's supposed to run inside a web browser in WASM just because of vague "JavaScript limitations", when Javascript is really a good solution for front-end UI inside a web browser.
I'll continue using vanilla React, for the same reason I use Java: it's reached the coveted "boring technology" status where it's mature, stable, fast enough, and has a huge community, resources, and ecosystem. I won't let go of that easily. However, this is a pretty epic rant nonetheless.
Maybe it’s time I learn it… Last time I looked at react was 2016 or so and every tutorial was referencing some different mutually incompatible version of some component (router, redux, flux, some other alphabet soup) and everyone had their own list of essential ingredients in a basic hello world app. I came away from the whole experience thinking here’s an ecosystem that needs to mature another 10 years or so before…
Routing: react router (not very good imo but widely accepted and good enough)
state: No libraries. Just use “useState” and if necessary “useReducer”
Builds: vite
Then pick a query caching library so you don’t need to treat fetched data like its application state… ReactQuery is widely accepted and very good. Apollo if you’re using graphql
I never liked React. I'm primarily a backend developer, and preferred server generated HTML with a sprinkling of Javascript. It may sound ridiculous to some, but I miss the JQuery days. For newer projects I'm looking at Elixir / Phoenix / LiveView and HTMX.
No need to miss jquery days. If you want jquery you can use it now. I know at least some companies use it even for greenfield projects.
* x-platform (that was a big thing in jQuery in the beginning): solved in JS
* DOM selection (not as elegant w/o some aliassing, but still): solved in JS
* making XHR: solved in JS
* building plugins: solved in JS
* method().chaining().style().of().programming(): not in JS
That's mostly I think.
Earlier quoted context omitted.
> React will be unseated like jQuery got unseated when someone makes something that looks nicer. The solution is WebAssembly. Make your code look as nice as you want, as readable as you want, in whatever language you want. No more JavaScript limitations.
>No more JavaScript limitations. But you accept a whole host of other limitations with WASM. It's a trade-off. You still need to access the DOM, which can't be done directly from WASM. Maybe someday it will happen? Okay, so use canvas instead and do all UI inside WASM? That seems like reinventing the wheel that is Javascript + DOM. WASM has plenty of uses, but replacing Javascript probably isn't where it shines. Java…
You can access the DOM through JavaScript glue. These Rust WASM frameworks do that:
- Leptos: https://www.leptos.dev/
- Sycamore: https://sycamore.dev/
- Yew: https://yew.rs/
- Dioxus: https://dioxuslabs.com/
Eventually you won't need the glue.
> Okay, so use canvas instead and do all UI inside WASM?
You can do that too. That's what this VB6 clone written in C# and compiled to WebAssembly does:
- https://bandysc.github.io/AvaloniaVisualBasic6/
- https://github.com/BAndysc/AvaloniaVisualBasic6
> vague "JavaScript limitations"
It's not vague. Despite 28 years of effort optimizing JavaScript, WebAssembly outperforms it:
- https://nuenki.app/blog/bloom_filters_optimisation
- https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...
- https://www.amazon.science/blog/how-prime-video-updates-its-...
- https://web.dev/case-studies/google-sheets-wasmgc
That's a kick to the groin that's tough to walk off.