13 ms·
I think i am getting old. These frameworks are so big and complex. For a simple web hello world you need a huge build and compile pipeline. And now its extended
by holoduke 3y ago
I think i am getting old. These frameworks are so big and complex. For a simple web hello world you need a huge build and compile pipeline.
And now its extended with serverside components.
I really wonder what the overhead is. How many of layers of frontend and backend framework code is executed to get the hello world example running.
I retreat back to my simple 10kb component framework in which i need only f5 to rebuild.
- knubie 3y ago> For a simple web hello world you need a huge build and compile pipeline. These frameworks were not created to solve “Simple hello world” apps.
- lelanthran 3y agoWell they don't look like they were created to manage complexity either, so exactly why are they used?
- csomar 3y agoThey simplify the on-boarding of 6 months boot-camped front-end developers. They can start working and delivering right away despite not being able to tell the difference between front/back ends and having no understanding of servers.
- bsenftner 3y agoExactly! These frameworks enable people with 6 months of "software developer" education to enter the industry and enshitificate our careers with their minimum wage level understanding of actual software engineering, dragging all of us down to their salary level.
- hnfong 3y agoIf your career can be significantly affected by devs fresh from bootcamp, you probably need to sort out your own issues than to complain here mate.
- Chris2048 3y agoThat would assume quality is valued by an employer, versus shitt apps.
- datavirtue 3y agoChecking boxes on a project plan seems to be the priority. Everything else is rather uninteresting to them.
- JohnBooty 3y agoIf your career can be significantly affected by devs fresh from bootcamp Well, there are certainly problems if that's the case. But it's not necessarily senior ICs that are the problem. I've experienced a few companies where "boot camp yahoos" wound up essentially running the show to ruinous effect. Why? They had numbers, essentially, and management was too hands-off to prevent it. To give a specific example: we had a product where our UX was basically: fill out this HTML form to apply for a financial product. Traditional dinosaur-style server side rendering was more than enough. The front end boot camp yahoos somehow wound up forcibly moving us to React. They got that pushed through and approved before anybody knew about it because they gave a bunch of BS stats to management who didn't care and also didn't have the technical chops to spot the BS. The end result was that simple changes to the UX (like adding a question to the form, or removing it) required 1,000+ lines of code across multiple repos. Hundreds of hours dealing with that mess for zero gain instead of actually doing things that made the company money or improved our process in meaningful ways. Senior ICs had no real chance to oppose this plan, and many of them were happy simply to get "React" onto their resumes. So yeah, problems aplenty, but it's possible to be an IC and have one's shit rocked by this kind of thing through no real fault of one's own. (I'm not crapping on React specifically here. It is powerful and there are use cases where it excels. I am also not crapping on junior or boot camp engineers. They are doing their best. It's a management problem.)
- shafyy 3y agoRelevant South Park: https://www.youtube.com/watch?v=APo2p4-WXsc https://www.youtube.com/watch?v=APo2p4-WXsc
- RHSeeger 3y ago> with their minimum wage level understanding Please don't do that; it's effectively turning "makes minimum wage" into an insult. There are plenty of people that earn minimum wage that are good people, doing their best, and (in many cases) doing a very good job. This is exactly the kind of wording that turned various minority terms into insults, as we shouldn't be doing it.
- bsenftner 3y agoI see your point, but in my case above the term usage is correct. By stating "minimum wage level understanding" I am equating the work they do to be equal to what a untrained minimum wage employee is expected to be able to accomplish. These "boot camp developers" are not engineers, and are barely developers at all. They are logical pattern repeaters, with an extremely short list of logical patterns they know how to use. Presented with the open ended work actual software developers are commonly tasked, they reach for an ungodly large number of supports and produce these modern code crap piles that are growing oversized data centers, duplicating all over the landscape. They're fantastic for selling more servers, and that is about all these boot camp developers are good for - we end up cleaning up their crap piles anyway.
- throw1234651234 3y agoI don't really buy this argument. Raw CSS/HTML is easier to understand. At the end of the day, all frameworks really do is remove `getElementById` and a couple helpers like `element.style.display`. This does make code MUCH cleaner, but the argument is that raw code isn't easier to understand. I have also had a couple of CSS wizards that wrote all the styles by hand - sounds great until someone has to fix it, even a senior designer. In short, a well-used framework that's understood is not necessarily easier, but it does lead to an agreed-on set of abstractions that make things easier to understand. Angular and React are very much there for a reason.
- wryanzimmerman 3y agoThat’s not totally true though. React, used correctly, lets you use and share a mental model where you have clearly defined the minimum complete information required to display any state of the app, and separately you have a set of simple functions which reliably convert pieces of that data to correct html. That’s insanely powerful and massively reduces complexity in highly interactive apps, because it means you no longer need to think about “user did this, update this here now, and here and here” chains, and can just do “user did this, update the state” and have that state update render potentially hundreds of changes across the app without needing to do additional implementation. But if you aren’t disciplined with maintaining, or don’t understand the difference between pure functions and side effects, and fall back to hacks to try to “make things render” or “stop wasting render cycles” you’ll end up with even more complexity than necessary. Using react as another version of `getElementById` leads to a horrible mess much worse than writing vanilla javascript, and most people who have that complaint are doing it to themselves by fighting react either unintentionally or on purpose to show how it can be bad when abused. Raw HTML and CSS is much easier to understand, and mandatory to understand because at the end of the day creating HTML and CSS is the only goal, but higher level abstractions can be super useful to manage complex projects, and the mental models and abstractions are the actual benefit.
- throw1234651234 3y agoThat's a good addition - I was being reductionist by saying it eliminates a couple of functions that identify and modify elements. With that said, I feel it's still pretty close to being "just that" - I understand the details of everything you listed, but at the end of the day it just keeps track of individual displayed items, if they are parts of objects and regardless of how they are passed in (params, state, context, etc).
- chezelenkoooo 3y agoAh yes, the "server side rendering is really simple to build" crowd has arrived. Let's reduce the nuance of the argument by insulting new Devs!
- SanderNL 3y agoTo be fair, we tend appreciate these kind of features when we are on the other side, buying, say, IKEA furniture. I respect, but don't particularly want to support professional carpenters if given the alternative. E.g. you can have cheap shit now or wildly expensive "proper" products later where the "proper" means something I do not and can not appreciate - to put it simply I know wood is made from trees and there ends my appreciation of the craft. Getting me "on-board" quickly with some basic furniture is quite helpful, although it requires IKEA-level infrastructure and investment to get these things in front of the buyers which is definitely not easy. Dare I sare ridiculously complex?
- fidotron 3y agoUser testing Ikea assembly must be an interesting challenge, partly because experience in the test group would make you better at later tests. I have worked on international teams where it was a running joke the individuals had ended up assembling the same Ikea furniture on three continents.
- couchand 3y agoWhen I was younger, in a new space, my priority was FILLING IT so I could go about my life. I appreciated how easy it was to fill a space with Ikea. Now that I'm older, in an old space, my priority is EMPTYING IT so I can go about my life. I now appreciate how permanent your space can be if you carefully deliberate each addition.
- csomar 3y agoI can’t edit comment now. Not sure why some readers perceived my tone as negative. This is a neutral view and am just explaining why React server side is getting adoption and how this is being driven by the business side of things.
- tcfhgj 3y agoI think Angular does pretty well in this
- rpbiwer2 3y agoAll of the modern frameworks do tbh, people just like to bitch about what they don't understand
- taurath 3y agoTo 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.
- FridgeSeal 3y ago> 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 cost of thrashing my CPU and ram. Crazy idea, but maybe, if instead of spending ages building “interactivity” we just built “applications that worked”, we might actually have less mess, and build better products.
- taurath 3y agoBroadly agree that simpler is better. 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.
- ozim 3y agoThey were created to manage complexity of building web applications. So something more like Excel than something like dummy photos gallery. One still can simply drop html file and sprinkle it with jQuery.
- wruza 3y agoIronically, “Web Excel” doesn’t use any of them. And if you asked someone who can create Excel to implement it in a webpage, they wouldn’t probably even think about these frameworks seriously. The real promise of these is web forms with a little interactivity. Anything more complex and you start to fight with it to drop back down to the level where it’s manageable.
- PurpleRamen 3y agoAccording to LibJS Detector, Excel Online is using react.
- golergka 3y agoThat's been a complete opposite of my experience. I'm now on my second full-fledged IDE that is built with React, and I'd take it over any other tech.
- yowzadave 3y agoNot sure which web-based spreadsheet app you're talking about, because there are many that do use these frameworks. Here's a PS/AI clone built with a Svelte frontend: https://graphite.rs https://graphite.rs
- wryanzimmerman 3y agoReact is a little bit painful and massive overkill for web forms actually (compared to other approaches). It’s the fighting with it that’s the issue; my experience is that a lot of devs go in to “force this stupid framework to work” mode and blow up tasks that should be 10 lines of code with no edge cases into 50 or 100 which “mostly works, good enough.” React is by far the most adopted framework for desktop-level or near-desktop-level web applications.
- bombolo 3y agoPeople needing to justify their job
- laputan_machine 3y agoAnd yet they are routinely used to solve "simple hello world" apps. Riddle me that.
- dartos 3y agoSome people like hitting the nail with the handle of a screwdriver instead of learning to use a hammer. Makes you feel clever. Idk what else to tell you.
- M4v3R 3y agoYou literally just run: > npx create-next-app@latest Press Enter a few times for default settings and voila, you have a hello world app up and ready to run.
- christophilus 3y agoJust because it’s a one liner to install something doesn’t mean you aren’t installing a big, complex, over-engineered thing.
- tail_exchange 3y agoSure, but if you want to use React to build a Hello World app, the framework is not the one I would blame for overengineering.
- uxp8u61q 3y agoLook at your computer. Are all its parts and pieces strictly necessary to display the text "Hello world" on your screen? No. Why don't you throw it away and buy something simpler, then?
- laputan_machine 3y ago[flagged]
- bentlegen 3y agoReact is a general purpose web framework, and is routinely used to do more than serving static documents. I would argue it was never even designed (originally) for that use case. And yet because it can, we have to have this tiring endless debate.
- uxp8u61q 3y ago> Because they are called "libraries" for a reason, it can do much more than "Hello, World", and they are routinely used for much more than that. There you go.
- CipherThrowaway 3y agoF5ing to refresh is a heavier workflow than the hot-reload/refresh you get with every modern web framework.
- phist_mcgee 3y agoFor sure. Ever had to debug a bug deep inside of a webpage's code that relied on 5-10 preconditions to get it to appear? Without HMR, you're spending a lot of time F5ing and navigating to reproduce/fix it.
- loloquwowndueo 3y agoIf only there was a way to programmatically reproduce the conditions under which the problem appears and then exercise the behaviour that triggers the bug. Then some code could verify whether the problem still appears. Once the problem is fixed this same “test” dark magic could help ensure the problem does not occur again. Pipe dreams, my friends. Pipe dreams.
- sodapopcan 3y ago“That’s just not, like, how my brain works, man. I have a different development ‘style’, ok?”
- peteradio 3y agoWhy tempt us with such far out propositions?
- phist_mcgee 3y ago`git bisect` with an integration test suite of the backend running in a test environment can get you pretty close.
- pc86 3y agoThat seems completely unrelated to "have a unit test" which is what they're saying.
- skippyboxedhero 3y agoI didn't like the idea of moving to frameworks but it does make things simple again. It is probably slightly simpler than the stuff before SPA (Django, RoR). There is overhead with working out where something, should be rendered but, in my experience, a lot of the issues are raised at compile-time and are quite transparent (the articles overstates the issues you have here, there is mental overhead but it isn't bad). The SPA period of React was awful for complexity (this was also when React had lifecycle methods, wasn't well-integrated into webpack...awful).
- yummypaint 3y agoWhat kills me is that many websites would be better in every way if they were just html and css. I have come to think of it as premature optimization for some fancy capability down the road. It's like telling people they have to hire engineers to take core samples and do seismic modeling before building a chicken coop.
- throwaway9980 3y agoIt usually takes government to tie people up in these sorts of knots. These people have enthusiastically done it to themselves. Resume driven development is a hell of a drug.
- presentation 3y agoAs evidenced by the large numbers of production html and css apps that are outcompeting their competitors who use modern web technologies with greater product quality, and the swathes of customers who state their preference for these experiences. But seriously I have no idea of a single remotely well-known application that satisfies the above. If the modern web is so bad where are the products that prove that it can be done better more simply? There’s billions to be made if that’s true in all industries, is nobody skilled capable of capitalizing on this gold mine of opportunity wherein the entire industry is self sabotaging? I’m left to conclude that these HN commenters with their hot takes about how the modern web sucks just generally either don’t understand what makes products successful or never have truly experienced the issues these frameworks solve for.
- fidotron 3y agoYou are using one. Craigslist is the canonical example. There are actual forums of normies and the most notorious meme factory on the internet is hardly a wonder of UX technology. We are not on some subreddit for a reason.
- donkeyd 3y ago> 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.
- renegade-otter 3y agoThis is precisely why you see this move from complexity. The younger devs are beginning to see it. Just like we dumped atrocities like SOAP and XML in favor of simpler and more ergonomic tech, this generation is learning - again - that complexity kills (and makes this job intolerable). Who knows, maybe software development is going to be fun again, even if for a few years before the new batch starts turning it into a mess.
- asynchronous 3y agoAfter kicking and screaming about learning yet another React framework I took the time to build an app fresh in NextJS and it really was a breath of fresh air, felt more like a mature, simpler form of React.
- throw1234651234 3y agoFeels like bloated garbage to me. "Hold on, let me make an MVC React framework with a Node API, so you can call your APIs from another API!". Thanks Next.js. Really wanted this. Honestly, might as well go back to Angular at that point - no redundant "API" there, at least. Also, automagic, automagic everywhere. "Let me just intercept your request and send it to a HANDLER, wow." "Let me just have a magical 'getServerSideProps' function that will do magic and generate component props, but it has to live in the page, so the page gets extremely bloated, oooo." I hate Next. And I realize "hate" is a strong word that takes some earning.
- cccybernetic 3y agoThe API isn't redundant, it's convenient. You don't have to use it. Just delete the /api folder and make your requests either from the client side or fetch the data inside the handler that you're complaining about. With the new app router, you can fetch it from the server component itself without the handler.
- throw1234651234 3y ago
- matthewmacleod 3y agoThis kind of take really annoys me; your pipeline can be as complex or simple as you need it to be for your specific use-case. If you want to build an application using static file, or a little Makefile that uses a single esbuild command, or a hulking Webpack configuration with 30 plugins – you can easily do any of these in line with the demands and complexity of what you are trying to build. Also, evaluating tooling based on how easy is is to create a "simple hello world" is only useful if your work involves creating "simple hello world" applications, which it doesn't.
- lifechoseme123 3y agoI agree. One can choose to limit complexity. Nothing is stopping a personal from building things with html, css, and vanilla js. Think of XHR -> Ajax -> Fetch API or others (Axios). No one is stopping you from writing out a 20 line XHR request. You can also write a 2 line Axios (or some other XHR-wrapper library) request. After I took the time study webpack (a day) or reactjs (a month) for example, I really appreciated the options webpack brought (code related plugins), and the structure reactjs brought to my project.
- swaggyBoatswain 3y agoThis blog post covered SSR better than most blog posts I've seen Anytime SSR or any of its derivatives comes into the conversation I always ask myself if things are becoming unnecessarily more complex. React server rendered components sounds like it's taking things too far - it goes against the natural developer experience DX order If your complexity on the app is doubled and it slows and confuses all the developers with increased coding footguns for only a measly gain in performance, is it worth it? Good old php sites and rails app with no SPAs have worked fine over the years
- fidotron 3y agoThis stuff appeals to a breed of management in the same way "full stack development" does, which is to say those in denial of the need or value of specialisation. The other benefit of such developers is they don't need teamwork. You just throw a feature request out at each dev and they do it end-to-end with you oblivious to the mess that is being created in the process.
- delfinom 3y agoHah, that breed of management predates the JS world of crap. My current manager sees no problem in the job postings ridiculously listing every single language/platform we have worked with, even 30 year old 8086 projects, even when any new hire will most likely be touching none of that and will be writing some mundane C for an ARM. "It doesn't hurt to list everything!" - Him "Why the fuck would someone want to apply to what looks like an absolute hell-hole?" - Me "But they should apply anyway if they know some of it!" - Him No shit the quality of applicants is sometimes not the greatest
- datavirtue 3y agoI'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.
- ttfkam 3y agoYou 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. You want substantially faster build times to reduce developer idle wait cycles? There are plenty of reasons to move to Go. (Note: I last coded a Java service last year in v17, and my first Java code was using v1.02. I'm no Java hater.)