More front-end JavaScript equals more expensive, less backward compatible and less cross-browser compatible.
Second-guessing the modern web (2020)
201–210 of 309 posts
Re: Second-guessing the modern web (2020)
#202"There are decent patterns in the form of GraphQL, but for a React component that loads data with fetch from an API, the solutions have only gotten weirder." Wonder how many people using "GraphQL" realise those decent patterns are from the 1970's, i.e., QBE. https://en.wikipedia.org/wiki/Query_by_Example
Huh? I’m not sure how the page you linked is related to GraphQL, except maybe that they are both querying paradigms. They seem largely orthogonal. Am I missing something?
[deleted]
Re: Second-guessing the modern web (2020)
#203One thing I've seen happen again and again in a lot of technologies is a "framework gravity". A lot of people see this as engineers just wanting to work on "hype" technology but I think what is actually happening is a reflection of global engineering time. React is great for SPAs. Most large companies are working on honest-to-god SPAs. By extension most engineers are working on SPAs. So most tooling is created for SP…
I see a big difference between Hadoop and React though: React pushes the costs on the client. This is something that's not often mentionned, but with a traditional SPA, a good part of your code runs on the client, which is server costs you don't have to pay. I don't know if it's something that people do consciously to reduce costs and just never talk about, or if it's an unintended consequence, but it's here. If your…
> If your React app is too slow/unoptimized, the client will pay the cost, not you
For the client the experience is worse and the cost is higher, so it's definitely a worse solution. SPAs really only make sense when you have a mostly offline application, which is just a very tiny bit of websites out there.
Re: Second-guessing the modern web (2020)
#204The amazing part to me is that SPAs are so much harder to do right compared to old-school server-side rendered HTML. One could be forgiven if they think a "simple" SPA is a good starter project, but they'd be very wrong. Async programming (Javascript Promises and/or async/await) is difficult, error-prone, and should be avoided whenever possible. On top of this, understanding how data flows through these SPAs is no sm…
I have to agree. I'm a OG Rails dev looking and constantly compare the productivity of old school SSR sites compared to current complex SPA frameworks. People how tie themselves in knots, the UI interactions are tricky to get right, more places to code, then second guess the frameworks, then try it again. SSR Rails apps just had 3, maybe 4 places to write code - controllers, models, view folders - you can flip back and forth in blinding pace, and get your app up and running really, really quickly. Yes agree there's some places SPA's are really applicable. But watching an app get built that you see no distinct advantage for either end user or dev team makes you wonder.
Re: Second-guessing the modern web (2020)
#205"There are decent patterns in the form of GraphQL, but for a React component that loads data with fetch from an API, the solutions have only gotten weirder." Wonder how many people using "GraphQL" realise those decent patterns are from the 1970's, i.e., QBE. https://en.wikipedia.org/wiki/Query_by_Example
Huh? I’m not sure how the page you linked is related to GraphQL, except maybe that they are both querying paradigms. They seem largely orthogonal. Am I missing something?
From the Wikipedia page:
"It is the first graphical query language, using visual tables where the user would enter commands, example elements and conditions. Many graphical front-ends for databases use the ideas from QBE today."
GraphQL seems to borrow the name. Graph [ical] Q [uery] L [anguage]
It could be a pure coincidence, but then, further down:
"GraphQL a QBE for JSON front-ends."
As evidenced by the reply, the parent seems to have predicted correctly that there are people who have no idea the two are related, i.e., one is descended from the other.
Re: Second-guessing the modern web (2020)
#206> "You can buy this Jekyll theme..."
Quite why I would spend money on a theme consisting of a white background and unimaginative black text beats me...
Re: Second-guessing the modern web (2020)
#207One thing I've seen happen again and again in a lot of technologies is a "framework gravity". A lot of people see this as engineers just wanting to work on "hype" technology but I think what is actually happening is a reflection of global engineering time. React is great for SPAs. Most large companies are working on honest-to-god SPAs. By extension most engineers are working on SPAs. So most tooling is created for SP…
> Most large companies are working on honest-to-god SPAs. Most devs don't work at large companies, at least not tech oriented large companies. I'm almost certain most projects don't come out from such companies either, statistically. In fact, most projects are not SPA, nor using any kind of AI, Big Data, or another buzzword. So I don't think that's it. I think that large companies are just the loudest, also creating/…
> Most devs don't work at large companies.
that would be very surprising. Companies like IBM, Microsoft, ATOS, CapGemini ... employ literally hundreds of thousands of devs each
Re: Second-guessing the modern web (2020)
#208I agree with a lot of these points, but differ slightly in two regards: 1. In my experience React DOES lure people into the "pit of success" in at least one important aspect -- modular and re-usable front-end code. React is certainly not the only way to get this, but it does help force you into some good patterns. 2. The "sweet spot" for React is pretty large. If your site is truly static (e.g. a blog, a product land…
How? It's the most painful, difficult, slow, frustrating, confusing programming experience I've ever had in my 25 years. It's made me want to leave the industry completely and I honestly think I will after this project. It has single handedly slaughtered and destroyed my quarter century love affair with programming. It's a wildly inflexible architecture that aggressively forces their users to conform to an orthodoxy…
That's why I am a happy backend developer. Quit frontend and move to the backend where development is straightforward.
Re: Second-guessing the modern web (2020)
#209Earlier quoted context omitted.
React is famously not a framework though. Next is the relevant example here, which actually does work to address a bunch of the complaint points, including doing full page reloads when you’ve deployed a new version of the app.
React famously claims not to be a framework. Many, myself included, would argue that it is very much a framework in every way that matters.
I would define a framework as something that offers a high level abstraction, promotes best practices and takes care of a bunch of boilerplate stuff for you.
React doesn't do that at all. Next, Blitz, Redwood etc, do.
Re: Second-guessing the modern web (2020)
#210Earlier quoted context omitted.
> Most large companies are working on honest-to-god SPAs. Most devs don't work at large companies, at least not tech oriented large companies. I'm almost certain most projects don't come out from such companies either, statistically. In fact, most projects are not SPA, nor using any kind of AI, Big Data, or another buzzword. So I don't think that's it. I think that large companies are just the loudest, also creating/…
> Most devs don't work at large companies. that would be very surprising. Companies like IBM, Microsoft, ATOS, CapGemini ... employ literally hundreds of thousands of devs each
Fixed it with "at least not large tech oriented" because banks, supermarkets, the media industry, the entertainment industry, etc. employ a ton of devs, but they won't likely use Kubernatis for most of their stack.