11 ms·
One 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 "hyp
by nemothekid 5y ago
One 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 SPAs. Now if you aren't building an SPA you look around and find almost every resource is around building an SPA. Even if you know you don't need an SPA, it's easier to hire, iterate, and even use other open source solutions if you are building an SPA, so you try to hamfist your project into an SPA.
It's a bit like having a bike commute in America. A bike might be the best thing for you to do - cheaper than a car, keeps you healthy and you don't need a garage. But you quickly find that everything is built for cars and it's easier to deal with the disadvantages of a car than try to commute with a bike.
I remember thinking the same thing about Hadoop 5-6 years ago. If you had "small data" you could get what you wanted with SQL and fast disks. But everything else assumed you were on Hadoop. Newgrads were trained in hadoop. New tools were Hadoop first. New research was all hadoop. If you hit a small issue with your DB, almost every solution would be "this is how it's solved in Hadoop". It was hard to even know if what you were trying to do what even possible without Hadoop.
The only optimism I have is that maybe in 5 years we will all collectively wake up and stop trying to shove React everywhere just like we stopped with Hadoop.
- zabzonk 5y agoSorry, what's a "SPA" - can't seem to find it by Googling.
- deleted 5y ago[deleted]
- grzm 5y agoSingle-page application https://en.wikipedia.org/wiki/Single-page_application https://en.wikipedia.org/wiki/Single-page_application
- felipellrocha 5y agoIt’s like when you’re stressed and need to relax, and you need a webpage done. So you meditate, then crank out code
- SCUSKU 5y agoSingle page application.
- zabzonk 5y agoBTW, I'm not a web developer and don't see why I should have known what "SPA" means.
- waiseristy 5y agoDownvotes on HN are not at all related to the quality of your question. It's fine
- 1vuio0pswjnm7 5y agofirefox "https://en.wikipedia.org/w/index.php?limit=500&profile=all&search=spa" At the top is the link to the Disambiguation. https://en.wikipedia.org/wiki/Spa_(disambiguation) https://en.wikipedia.org/wiki/Spa_(disambiguation) A more specific search, e.g., "single page", will not redirect. In some ways, for discovery, Wikipedia's search engine is better than Google's. For one, it is non-commercial and does serve ads based on past surveillance of the user's activity. Second, the user can retrieve larger numbers of results and page through them quickly without triggering a (false positive?) defensive measure than temporarily blocks her IP address from retrieving results for a defined period. Third, it is curated to remove commercial content rather than curated to further a business purpose in online advertising. No wonder Google steals Wikipedia content for "instant answers" or whatever they call it. Wikipedia search works quite well.
- arsome 5y agoThe link you used directly brings up the wikipedia article on Spas. Not sure that's what you were going for. :)
- 1vuio0pswjnm7 5y agoYou need to follow the Spa Disambiguation: https://en.wikipedia.org/wiki/Spa_(disambiguation) https://en.wikipedia.org/wiki/Spa_(disambiguation) In that sense Wikipedia is a bit like Google in that they try to guess what the user is searching for, perhaps what is most popular. Thus, a search for "SPA" automatically redirects to the article on Spa as in therapeutic water treatment. A link to the Disambiguation page, if it exists, will always be provided (cf. "Did you mean ...."). However, change the search string "spa" to something more specific and then see all the search results. For example: https://en.wikipedia.org/w/index.php?limit=500&profile=all&search=single+page https://en.wikipedia.org/w/index.php?limit=500&profile=all&s... Increase limit= to a number greater 500 if desired, or smaller if want to speed up the search.
- deleted 5y ago[deleted]
- Zababa 5y agoI 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 React app is too slow/unoptimized, the client will pay the cost, not you. If your Hadoop cluster is too big/not efficient enough/not useful, you're directly paying for it.
- zozbot234 5y agoThe "server cost" of traditional SSR is heavily overrated. It can be made small enough to be basically a rounding error compared to everything else your backend is doing. Even more so since retrofitting SSR onto a JS single-page application is quite inefficient, so you end up paying for that load many times over.
- scrollaway 5y agoThis is only sometimes true. Other times, cutting the server rendering makes things a million times easier because maybe you're not contacting your database, or you're offloading large per-user objects to the client instead of keeping them in ram for thousands of uniques per minute, or, or ... Some calculations are less heavy on the client side. It's not building the html itself once you know what you need that is heavy, it's that awful dropdown menu with dozens of nested filters that rely on user-input data which is awful to build serverside, but incredibly easy to build client side.
- h0l0cube 5y ago> because maybe you're not contacting your database Except you will anyway, to do all those API queries you need to fill the page. That involves multiple handshakes back the server, and yet more server-side resources tied up. > or you're offloading large per-user objects to the client This access happens either way, and will be discarded in short order by any cache, even using the most naive LRU policy.
- arsome 5y agoYep. We recently did an assessment of available UI libraries and pretty much concluded the best maintained libraries with a modern look and feel are all web-focused and we're likely to have to settle for building an electron app if we want to be able to take advantage of the best selection of 3rd party libraries without building as much ourselves. As much as I don't like the ecosystem or Javascript as a language, there's so much tooling around it and the libraries available seem to be miles ahead of other options. I'm hoping Redux and TypeScript can make it moderately bearable. Fingers crossed. Seriously, what is there? Microsoft doesn't even have a clear direction for desktop apps - their most recent stuff like VS Code and Teams are built on Electron.
- bhauer 5y agoRedux making something "bearable" is confusing.
- nahuel0x 5y agowas Flutter included in the comparison?
- arsome 5y agoI did look at Flutter but pretty much concluded that it was still fairly immature and didn't have great 3rd party libraries available for things like graphing and data tables (sort, filter, group, etc, with all the UI work done for you). This was a year or two ago so things may have improved since, but in React-land there's plenty of very capable and well maintained options in both the commercial and open source world.
- theteapot 5y agoRedux?! Bearable?! What is happening?!
- girvo 5y agoTbh if you're living in React-land and understand Redux, useReducer with useContext has subsumed the need for it in nearly all cases for myself and my team. For the parts it doesn't match, truly global stuff or tonnes of mutation, MobX is nicer out of the box than Redux. Redux can be just as nice and in some ways more powerful, but thats only after installing and configuring X amount of middlewares, with all the type confusion that can add :(
- Jakobeha 5y ago> "framework gravity" I see this a lot. Especially with languages - of course I would love to write a big app in Haskell, but the tooling for Java / JavaScript / C# is just so much better (before Swift / Kotlin it was so much worse). And what is happening with React is just like what happened with those languages: all of the big drawbacks are getting their workarounds. Bundle splitting and server-side rendering address large bundles and long load times, as the author mentions. Of course they have their own issues, but as time goes on I'm sure more workarounds will be created. I wouldn't be surprised if in the next 5 years, React's drawbacks don't fully go away, but they're a lot less. Although I'd rather like React gone too, personally I really don't like using it.
- austincheney 5y agoYes there is a framework gravity. More directly it is Invented Here Syndrome: https://en.m.wikipedia.org/wiki/Invented_here https://en.m.wikipedia.org/wiki/Invented_here Due to missing leadership and absent mentorship many developers are hoping tools provide the guidance they need.
- tshaddox 5y agoAnother big issue is the ability to seamless transition parts of your software between different programming models. We just don't have good solutions to this that I know of. The thing with SPAs is that you are probably worse off starting with a traditional server-rendered HTML web site and slowly introducing more and more interactivity, unless you know you won't eventually be better off with an SPA at the foundation (or unless you've planned and budgeted for that eventual rewrite). React is actually great at embedding individual interactive components on a static HTML page (like an interactive chart or table component, or even a fancy button). You can go a long way just having your Rails app render a navigation menu and application shell, and each page just loads a big React component in the main content section. Great! But then you need to update a little bit of that application shell in response to a visitor interaction or some newly-fetched data. Maybe one of your menu links needs a little red number next to it to indicate the number of unread messages. Still easy, with JQuery or whatever DOM manipulation library you're using. But then when the visitor clicks on one MessageRow component in your big MessageList React component and reads the message. The unread count didn't change! That's still easy to fix though. But pretty soon you're writing a lot of manual DOM manipulation code to sync every bit of data bidirectionally between every source of mutation and every UI element that depends on that bit of data. You'd be better off with an SPA, or at least with having React grow to own a little bit more of your application shell! Where this line gets drawn is tricky, and I don't think the conclusion is "always use an SPA framework from the beginning of every web site project." But I do think the options to conveniently and maintainably use SPA frameworks to render traditional HTML pages on the server are improving a lot more than the options to gradually introduce whole-page-level interactivity to traditional server-rendered HTML frameworks.
- wrnr 5y agoThe web components and the pending state protocol is one of the things I which more people would know about. Listen for change events bubbling up and push down changed values. This does not only apply to single data fields but the entire DOM tree.
- madelyn 5y agoReact can work really nicely with different parts of the DOM via Portals however!! Portals are awesome for use cases where you're sprinkling dynamic bits into an SSR'd shell. And for all parts of your app that don't need that level of interactivity, you've got plain old templates in your server side language of choice. There's some limits to this but it's a neat trick.
- 8n4vidtmkvmk 5y agoI've been happily using MySQL for over 10 years and have never seen a reason to switch. Happy to have avoided the NoSQL craze. There's been like 1 or 2 queries where SQL has been suboptimal but nothing insurmountable :-)
- yewenjie 5y agoThere is a name for this kind of phenomenon - Inadequate Equilibria - why civilizational scale failures can still occur even if every actor is doing things as efficiently as possible. Some of you might want to read the excellent book that introduced the concept - https://equilibriabook.com/ https://equilibriabook.com/
- BiteCode_dev 5y ago> 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/promoting popular FOSS projects, and they have great engineers that are on many social networkd, including HN, or write famous blogs. And so people have the impression that you need an SPA into a docker mix among other microservices each horizontally scaled in the cloud, monitored using an observability framework, using a big data pipeline for processing things they will store in their NoSQL sharded DB accessible through a GraphQL Api. Because Jack working at GAFAM for $500k has the time, env and will to sing about it, but Juan working in a Madrid bank is just spending his company time fixing the Tomcat server quietly.
- jcelerier 5y ago> 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
- pmontra 5y agoIt's not as if all of them are working on a SPA or the backend of a SPA. On the other side, the long tail of devs working in medium and small companies are probably working on both a frontend and a backend. This is especially true when there are one or two developers in all the company, when the company business is selling some service or physical product and software is a cost and not the source of income. And a medium company in the USA is a large one in many countries, a small one a medium one. So the sum of devs in the long tail can be much larger than the sum of the devs in the top companies.
- BiteCode_dev 5y agoFixed 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.
- gbrindisi 5y agoSame argument can be applied to kubernetes too
- hackerfromthefu 5y agoIn my opinion, it's that 'most not widely experienced but SPA focussed developers read about SPAs'. I think the issue is your search filters or other filters that have created a knowledge focus bubble in your life. The hadoop thing is so unusual, really strange. I'm fairly certain, to very certain, that Sql is the industry standard while hadoop is a small corner of the mindshare. Perhaps it's time to widen your sources, and e.g. cycle through different browsers to reduce search profiling.
- agumonkey 5y agoThis gravity is probably the fuel of society, it's hard to avoid its negative side effects, it's a natural positive feedback loop. Just like finding beer money by making a youtube channel on trendy topic.. the short term effort/reward is higher than doing quality stuff (or even finding a better job, which can be hell) and this web being the trend, everybody will be nice to you if you want to make a youtube channel..
- chrisweekly 5y agoI agree with your logic but not the premise; wrt React and SPAs in particular, thankfully NextJS has emerged as a robust React-based framework encompassing every kind of rendering mode (SSR, SSG, ISR, CSR/SPA, hybrid) and architecture.
- midrus 5y agoWhich is good as long as you're only building just a frontend. Or a landing page. The moment you need to integrate it with server side validations, authentication, add a database, migrations, background jobs, etc. it becomes a mess. In fact, a custom undocumented mess.
- chrisweekly 5y agoYMMV, but that doesn't match my experience with NextJS at all.
- pjmlp 5y agoAlan Kay puts it quite well, fashion driven industry.
- iKnowKungFoo 5y ago"Newgrads were trained in hadoop. New tools were Hadoop first. New research was all hadoop." Reminds me of a job about four years ago: New hire, right out of college, "I studied Java". Surprise! Your team is PHP! Now learn that without any help from your team leader or we're gonna fire you. And they did. Poor kid.