| ▲ | jbreckmckye 4 days ago |
| This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written. But people upvote it anyway. What is the cause of this? 1. Bad experiences with JavaScript apps that have aggregated complexity (be it essential or incidental complexity)? 2. Non-JS developers mystified and irritated at a bunch of practices they've never really internalised? 3. The undercurrent of "frontend is not real programming" prejudice that existed long before React etc al. and will continue to exist long after it? |
|
| ▲ | j0rd72 4 days ago | parent | next [-] |
| I find myself agreeing with the article (although I also agree that it assumes you've chosen an SPA when you shouldn't have). To add my own perspective: I work on an app, the front-end of which essentially consists of 6 nav tabs, 3 of which show an index of records with corresponding add/edit forms. We don't have any hyper-fancy interactive components that would require heavy JS libraries. And yet... we develop in React. Yesterday, I needed to add 1 new field (representing by a checkbox input) to both our app and a corresponding back-end application we have, which uses Rails views. I checked the git logs after to see how long each took. The Rails view took me literally 2 minutes to update (add field to model, add field to controller, add input to HAML with a class on the parent div). The React view took me 52 minutes, plus I later found out that I'd forgotten a damn type on some interface that's a shallow copy of our model. Is this a problem with React itself? Not really. But it's a problem in the way that it's used, and our 6 nav tabs and 3 forms don't need all the overhead of React. So for people in a similar situation, this article really rings true. |
| |
| ▲ | cnasc 4 days ago | parent | next [-] | | > We don't have any hyper-fancy interactive components that would require heavy JS libraries. And yet... we develop in React. Is React really a "heavy" library? https://bundlephobia.com/package/react@19.1.0 > The React view took me 52 minutes, plus I later found out that I'd forgotten a damn type on some interface that's a shallow copy of our model. This sounds like bad architecture, nothing about React would necessitate this. And if your typechecker isn't catching missing types, then it sounds like your types aren't adding much value. | | |
| ▲ | mosselman 3 days ago | parent [-] | | Whenever someone presents an anecdote like this, there is always someone who says “but then you are doing react wrong”. Ok, so why is it possible to do it so wrong so often then? That sounds like a downside of the tool. It is a sharp knife. That doesn’t mean there is no place for react, but it also doesn’t mean we have to wipe it under the rug and pretend like it is everybody else’s fault. I never read a story about it taking an hour to add a field to a form in Rails and it only taking 2 minutes in react. I’ve experienced the other way around for years though. So there is some truth to it. Let’s embrace the truth and look for what react brings us despite this. | | |
| ▲ | cnasc 3 days ago | parent [-] | | > “but then you are doing react wrong” My objection is not that they are doing React wrong, it’s that their complaint is incoherent because there is literally nothing about React that could make this task take an hour. React isn’t a form library. You write the markup for an html input element, if it’s a controlled input you have a trivial one-line change event handler, and you have a submit event handler. Any additional complexity here isn’t coming from React, and managing to overcomplicate such a basic thing and misidentify the source of the complexity absolutely speaks to a skill issue. This is especially funny in a thread where posters hold up Rails as a paragon of quality and efficiency. |
|
| |
| ▲ | dinfinity 4 days ago | parent | prev | next [-] | | > Is this a problem with React itself? React is far from the best tool for most jobs (if any), but it has a shitload of inertia. I can highly recommend looking into Lit (used to be Polymer):
https://lit.dev/docs/ IMHO it allows just the right amount of encapsulation and structure, whilst building on W3C web components and being highly interoperable with other javascript libraries/vanilla code. It's pretty much what web components should be out of the box. | |
| ▲ | wredcoll 4 days ago | parent | prev | next [-] | | People absolutely use technologies poorly and make things harder than they should be. At the same time, the part of the program that interfaces with the physical world (e.g., people) is always going to be far more complex and thus harder than the bits that get to live entirely inside the computer world. | |
| ▲ | sensanaty 4 days ago | parent | prev | next [-] | | I'm sorry but that just sounds like a tooling and skill issue? Adding a new form field takes me a grand total of 5 minutes in the Vue app I maintain at work, and I'm a mostly backend focused fullstacker. We have the form/input components, adding a new field to a type is trivial (and we generate those automatically based on our BE schema anyway), error handling is handled by our form/input components. Also, I'm not the biggest fan of React and think there are options that are a million times better like Vue & Svelte, but React is not heavy. Yes, JS frontends pull in a lot of libraries, but React (or any other framework except for probably Angular and Ember) is far from being the biggest or heaviest dependency in any project. In fact, especially React does this amazingly, React itself has 0 external dependencies. Usually people will also want react-dom, so for the simplest possible application, that's a grand total of 2 very lightweight dependencies, and for usecases like yours of a few forms, that's literally all you'd need. Sure, maybe your 3 forms don't need React, but it sounds like you're actively adding stuff to it (and even caught a type issue from the sound of it). The non React version of this work would've entailed targeting a querySelector's inner `.value` key, and then having to parse it if it's not a simple string and safe guard against the element not being there, or targeting a shifting ID or class or all the other numerous and tedious problems that arise. Or, you stick a `v-model` on it, send it as JSON and call it a day, I categorically refuse to pretend the old universe pre-SPA frameworks was in any way a good way of working. | |
| ▲ | thefreeman 4 days ago | parent | prev [-] | | Just because you are comfortable with one technology and inexperienced or unfamiliar with another does not make one better than the other. How much rails have you written in your career? How much react? |
|
|
| ▲ | benreesman 4 days ago | parent | prev | next [-] |
| I don't know that there's "real" programming, that seems like a hard fight to fight on either side, it's like arguing about whether animals are conscious or something. Are people? Who knows, pass the blunt. But there's been this really sharp over-correction to where now an obvious thing that is just common knowledge and that was never taboo is now considered impolite to even allude to. Frontend programming is among the easier kinds of software work as measured by the number of people who can do it? I bet if I tried really hard, I could probably be pretty kickass at pickleball, small court, not a lot moving around. But to be like, that's the same thing as the NFL. No, no it's not. I would never have been able to try out for the NFL, not if I live a thousand times. There's pickleball and pro football in programming too. |
| |
| ▲ | christophilus 4 days ago | parent | next [-] | | > as measured by the number of people who can do it That’s a poor measure. It proves only that there’s a demand for such programming. I have programmed in tens of languages professionally and many more for fun. Programming is programming. I haven’t found much difference in difficulty between any of the stacks I’ve worked with. Except, maybe C++, but that’s just C++ being garbage. I now happily use Zig as an alternative, and it’s no more difficult— easier in fact— than building a well-architected, complex UI application of any kind. | |
| ▲ | suzzer99 4 days ago | parent | prev | next [-] | | Front-end programming is easier in the sense that you can make little mistakes and your entire app doesn't fall down. As someone who's done decades of both, there's nothing conceptually easier about well-executed front-end programming over back-end. The stakes just aren't as high. | | |
| ▲ | gmadsen 4 days ago | parent [-] | | I think the argument might be that it takes less domain knowledge of hardware and all its abstractions, which does require a minimum threshold of reasoning and abstract thinking ability. I have high confidence someone who could built a database or kernel could also do front end work with a reasonable ramp up time. I don’t share that confidence for the inverse in the nominal case | | |
| ▲ | cjblomqvist 4 days ago | parent | next [-] | | I have seen many backend developers with this mindset and approach, and;
1) Tricky parts of frontend are afaict equally tricky as building a DB/kernel/whatever.
2) A typical mistake is that a lack of knowledge about the hard parts of frontend makes backend'ers assume frontend is easy, while in reality it's their ignorance (and arrogance) rather than the subject being the issue
3) As with backend, most developers don't deal with the harder parts. Most backend developers I've talked to do simple CRUDing + minor business logic from a DB. Similarly very few developers try to write their own drag and drop library from scratch. It's sad that so many seems to fall into the trap of 2). (I've done both types of development for 20+ years) | | |
| ▲ | benreesman 3 days ago | parent [-] | | I have no idea what backend developer means to this or that person. It seems to mean "not frontend", so like, directly interacting with a database and possibly using a compiled or even unmanaged language? But still often deploying through something that looks like: Haswell <- Borg Hypervisor <- Borg Pod <- KVM Hypervisor <- QEMU guest <- docker-compose <- docker <- golang ? I'm talking about hackers. I remember being like 24 and and a colleague of mine (legend) had never worked in JavaScript or really the web before was on our pod that got tasked with writing a browser for J2ME and BREW that implemented real web pages. He goes home that weekend, and he comes back on Monday with a stack machine written in JavaScript (ECMA-262, we ran it on Rhino back then because Spidermonkey was a whole thing) that executed a very cute subset of JavaScript, including lambda closure and therefore Church encoding / untyped System 1. I was like whoa, why in JS? "If I have to implement it in a month, I'm already two months late to start learning it." Is that guy a frontend developer? Backend? Full Stack? He had worked on DSPs and audio before, and on video codecs and embedded. My comment above about some of this stuff is harder isn't a diss to anyone, it doesn't make me a millimeter shorter that Carmack is so tall, walking around in some rarefied air of genius I can't even formulate a picture of: it inspires me to work harder, try more ambitious things, push every day a little past yesterday's limit, and it has for more than 30 years now. There's nothing wrong with programming be a job, it's a perfectly reasonable life choice and a very sensible one in light of life's other demands and opportunities. But some of us fucking love it, think about it all the time, live to be good at it. That's a different set of outcomes. And it does grate a bit to have everyone pushing this "it's all the same, we're all the same, it's one equivalent thing", that's my passion you're talking about, I take great pride in my life's singular ambition and pursuit. We're equal but we're not the same. |
| |
| ▲ | kylebyte 4 days ago | parent | prev | next [-] | | The backend has plenty of complexities, but frontend developers have to deal with something just as complex - the user. Given ramp up time, most backend engineers could build a bad frontend, or build a good one if they have a really good UX team that thought through everything and are just implementing their work. In the real world though where UX is understaffed and often focused on the wrong problems - I've had to rescue too many frontends built by backend focused teams to share your confidence. | |
| ▲ | suzzer99 4 days ago | parent | prev [-] | | It's also that you're at the top of the stack. If your stuff breaks, there's no layer above you whose stuff also breaks. Well except the end user, but depending on the app they can often be low-priority (internal apps, apps with captive audiences like online banking or airline websites, etc.). |
|
| |
| ▲ | 4 days ago | parent | prev | next [-] | | [deleted] | |
| ▲ | jbreckmckye 3 days ago | parent | prev | next [-] | | After looking over the author's blog I can see 1. Very high output 2. Lots of AI images 3. Weird writing and editing lapses in several posts I am moderately confident this post was written with an AI. It may not be totally AI produced, I think the author has probably edited the work, but I think we are mostly debating synthetic content. | |
| ▲ | bigbuppo 3 days ago | parent | prev [-] | | Most frontend development shouldn't be necessary as they're writing repetitive code that implements features that are missing from browsers. And it shouldn't be that hard to add those missing features to browsers. They're like half javascript at this point... |
|
|
| ▲ | wredcoll 4 days ago | parent | prev | next [-] |
| > Non-JS developers mystified and irritated at a bunch of practices they've never really internalised My current explanation goes something like this: "I'm a smart guy. Front end development looks simple. If I find it hard to do, that must be the fault of javascript somehow" |
| |
| ▲ | abustamam 4 days ago | parent | next [-] | | I started my career in FE and still consider myself a FE dev despite technically being a full stack dev. Sometimes I'd be working with my team on something and they'd be like "why is this needed?" and I'm like "because javascript" or "because react." While I agree with your sentiment that FE dev is certainly not simple, JS and front end architecture ad a whole does have its faults. That's why highly skilled FE devs who can build scalable, beautiful FE apps (whether using SPA or SSR) can be highly paid. | |
| ▲ | dataflow 4 days ago | parent | prev [-] | | Note those are not mutually exclusive. It's entirely coherent to believe you find a tool hard to use for reasons relating to the tool itself, and that the task you're trying to accomplish is also difficult independently of that. Analogy: imagine trying to give a good presentation with a horrible text-to-speech (or translation) system. Just because good presentations are hard that doesn't mean you don't get to complain about the program being terrible. | | |
| ▲ | wredcoll 4 days ago | parent [-] | | Yes, but now you're getting into "there are two types of languages, the ones people complain about and the ones nobody uses". There are obviously flaws and issues and annoyances in js world, but a lot of those come from having to solve much harder problems (compared to say, do a sql query and turn the results into json). | | |
| ▲ | vanviegen 4 days ago | parent [-] | | I'll bite. In essence a user interface just presents the data it got from the server in some nice looking shape, and sends any edits and button presses back. Should be simple, right? | | |
| ▲ | wredcoll 3 days ago | parent | next [-] | | The "Just" is doing a lot of heavy lifting there. Think about the presenting data part of it. Perhaps you have a table of data, prices of tickets or some such. You could literally just wrap each item in a <td> tag and each row in a <tr> tag and that would indeed be easy. But people generally want and expect more. How about color coding the rows to make them easier to scan left to right or sorting the table by each column or paginating through more data than can easily displayed on one screen or maybe you're doing "infinite scroll" instead. None of these things are impossible of course, and people have done them so many times and in so many different ways that there are dozens of libraries you can use and hundreds of tutorials, but even so, compare that to the "select from table turn to json" equivalent. The SQL can be more than a bit tricky, but aside from that, JSON is extremely well defined and specified, even without a library you can just read the specs and do it. Wrapping it in a HTTP response and returning it and so on is likewise very well specified and if you can read, you can follow the instructions on how to do it. Creating a UI that works the way a user wants to is the opposite of all that. Of course, one of the major differences here is that at any point you can just stop improving the UI. Maybe you stop after wrapping it in the table html. The UI will certainly work, for a very specific definition of work. JSON is considerably more boolean. It either is a valid JSON document or it isn't. You can ask a computer to check for you. You can't ask a computer to check if your users enjoy using your table. | | |
| ▲ | hasanhaja 3 days ago | parent [-] | | How does something like React help with any of the trickier UX problems you're describing? |
| |
| ▲ | 3 days ago | parent | prev [-] | | [deleted] |
|
|
|
|
|
| ▲ | reactordev 4 days ago | parent | prev | next [-] |
| I don’t know, I think reducing bundle sizes and bloated javascript in favor of built in support for view transitions warranted a blog post against one of the primary arguments for why SPA. I agree with the author. I love React. I shouldn’t need two dozen more dependencies. We ditched server side for client side in 2010 for speed. Now that we have 200x more compute power, more powerful CSS, more robust html (with web components), we can go back to server side rendering and only send what’s required for the user at the time of action. |
|
| ▲ | psychoslave 4 days ago | parent | prev | next [-] |
| That is considering that front end dev is necessarily implying js, which is exactly the erroneous premise one should try to dodge. |
|
| ▲ | hasanhaja 3 days ago | parent | prev | next [-] |
| Are we aligned with the claims in the article that a SPA architecture is not a suitable baseline architecture for content-focused sites with shallow sessions (low number of interactions)? |
|
| ▲ | 4 days ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | cleoxjefbjxis 4 days ago | parent | prev | next [-] |
| You miss the whole point and the author is correct about this: Modern CSS is powerful, and HTML is the way to deliver web content. Every web framework is _literally_ a hack to make the web something it isn’t. People who haven’t seen the evolution often pick up the bad habits as best practice. For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. And then once you realize that JavaScript sucks you’ll minimize it. |
| |
| ▲ | jbreckmckye 4 days ago | parent | next [-] | | Laravel is fine. It's not amazing. Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system). What I find interesting though is the assumption that web dev is done by "JavaScript people", that even the best "JavaScript people" have no technical breadth, and therefore fester in a cesspool of bad ideas, unlike your median backend dev who swims in the azure lakes of programming wisdom. Now, I've done plenty of SPAs, but I've also done plenty of other things (distributed systems, WebVR apps, metaprogramming tools, DSLs, CLIs, STB software, mobile apps, a smidgeon of embedded and hobbyist PSOne games). Which gives me the benefit of a generalist perspective. One thing I have observed is that in each silo, there are certain programmers who assume they are the only sane group in the industry. They aren't interested in what problems the other siloes are solving and they assume any solution "over there" they don't understand is bad / decadent / crazy. These groups all regard each other with contempt, even though they are largely addressing similar fundamental issues in different guises. It's a social dynamic as much as any technical one. | | |
| ▲ | Capricorn2481 4 days ago | parent | next [-] | | > One thing I have observed is that in each silo, there are certain programmers who assume they are the only sane group in the industry. They aren't interested in what problems the other siloes are solving and they assume any solution "over there" they don't understand is bad / decadent / crazy A lot of coders have realized there's social credit in trashing other programmers. I regularly see comments from people claiming to have a singular custodial spirit for their craft, unrivaled by their peers. There's obviously advantages to telling people that everyone else is holding it wrong. Then their advice is - Some niche trick that's completely irrelevant to most situations - Something that sounds obvious and uncontroversial, but is so broad and vague that it's not even worth arguing about. And I realize the irony of me making this comment. But I wish we'd get over this phase where everyone thinks they're an expert, and that every bad codebase or slow app was the result of someone who didn't care. I have yet to work with someone who didn't care about their code. | | |
| ▲ | girvo 4 days ago | parent [-] | | > But I wish we'd get over this phase where everyone thinks they're an expert, and that every bad codebase or slow app was the result of someone who didn't care. I can only speak to my own experience, but it’s been this way for the entire 18 years I’ve been doing this professionally and I can’t see it stopping anytime soon. I just ignore it and write off people who openly think that way. It shows a lack of experience and empathy. |
| |
| ▲ | PaulHoule 4 days ago | parent | prev | next [-] | | It’s connected with the questions around occupational licensing of programmers, unions, and similar structures which would not be so much about getting paid more but about getting quality up, squashing bullshit, and getting our quality of life up. Without a cohesive community, mutual respect, and recognition of a shared body of knowledge, we don’t have the solidarity to make it happen. As for Laravel, I’d say people were making complex applications (Ebay, Amazon, Yahoo) in 1999 —- Google Maps were better than Mapquest, which drew each image with a cgi-bin, but many SPA applications are form handling applications that could have been implemented with the IBM 360 and 3270 terminal. The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw. You need two handfuls of helper functions, for instance <? draw_select($options,$selected_options,$attributes) ?>
to make forms which can be populated based on what’s already in your database. People never wrote down “the 15 helper functions” because they were too busy writing frameworks like Laravel and Ruby-on-Rails that did 20x more than you really needed. So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built.As for performance, web sites today really are bloated, it’s not just the ads and trackers, it’s shocking how big the <head/> of documents get when you are including three copies of the metadata. If you are just drawing a form and nothing else, it’s amazing how fast you can redraw the whole page —- if you are able to delete the junk, old school apps can be as fast as desktop apps on the LAN and still be snappy over mobile. | | |
| ▲ | wredcoll 4 days ago | parent [-] | | > The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw Yes, I was there, I wrote and used these pages. It sucked. Things are better now. > So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built. Building a form with zero user affordances is not difficult. It just isn't good. We absolutely know how the pyramids were built. You get a whole bunch of humans to move a very large amount of stone and then stack it up in a big pile. The reason nobody builds pyramids today is because we have better alternatives. | | |
| ▲ | PaulHoule 4 days ago | parent [-] | | I've been in a happy place with React with some projects. I've worked on some where it was valid choice but boy the annoyances, like not being able to test your components because you're on an old version of React where your test framework can never know when the last render happened because you depend on a large number of components which don't believe they'd run on the current react but probably would if you could just vendorize 30 or so packages and patch their package.json files. Or depending on a test framework that refuses to look up components by class, id or selector because they want to force you to use aria, even when it doesn't make sense such as in three.js. Or depending on a routing framework that doesn't get maintained, instead they've been through 7 incompatible versions of it which leaves me thinking that they didn't ever believe in what they were doing. Or having to understand the internals of 5 CSS frameworks (including JS-heavy frameworks like Emotion) to handle all the components you've sucked in and still understand raw CSS through-and-through to fill the gaps. I worked on one system which was frankly experimental at a startup that was doing two week sprints building a tool called "Themis" for building ML training sets. The thing was that we were always having to add new tasks and between Docker and an overengineered back end and front end it took 20 minutes to go from source code to being able to interact with the thing, so it took a 20 person team and lots of coordination between FE and BE engineers to do the simplest things. I sketched out an alternative called "Nemesis" which grew into an HTMX-based system where it takes one programmer an hour to code a task and there is no build, and between Flask and the 15-or-so helpers it is easy. I've hacked it to be an RSS reader, an image sorter, and several other centaurs: https://mastodon.social/@UP8/114887102728039235 this feels like a desktop app when I am on the LAN and loads well under a second on a mobile hotspot the first time and every time. The key is that the tasks are nearly completely independent of each other, there are no builds and no dependencies, so writing a new task can't break old tasks. That system has plenty of screens that use d3.js for awesome visualizations and if I wanted to make a task that did something complicated which would really deserve React or Svelte or something I could do it, again, without breaking the the other tasks. | | |
| ▲ | wredcoll 4 days ago | parent [-] | | > I sketched out an alternative called "Nemesis" which grew into an HTMX-based system where it takes one programmer an hour to code a task and there is no build, and between Flask and the 15-or-so helpers it is easy My argument here is basically creating that is really, really hard, and there's no framework or library that will make it easy. React and friends are a mess because they're dealing with hard problems, kinda like systemd or kubernetes. Writing code that lives entirely inside the machine is a lot easier than having to interface with the messy real world. |
|
|
| |
| ▲ | esskay 4 days ago | parent | prev | next [-] | | > Laravel is fine. It's not amazing. Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system). As opposed to Javascript, the pinnacle of tight standards and high quality performative code... The same arguments that can be made against PHP/Laravel absolutely apply to Javascript equaly, if not more so due to the pretty well know shiny object syndrome issues that many JS devs get caught up in. | |
| ▲ | 4 days ago | parent | prev [-] | | [deleted] |
| |
| ▲ | weego 4 days ago | parent | prev | next [-] | | Every web framework is _literally_ a hack to make the web something it isn’t This sentence is doing an awful lot of heavy lifting that doesn't fit with reality | | |
| ▲ | cjonas 4 days ago | parent [-] | | Ya this is nonsense. The web is what it is. You could maybe say "every framework is a hack to workaround protocols primarily designed in the 90's before we really understood the full application of the web" | | |
| ▲ | goatlover 4 days ago | parent | next [-] | | The internet isn't the web, and there are plenty of applications who use those protocols just fine outside of the web browser. It's the html tech stack initially made for hypertext documents and resources that's been heavily upgraded to do web-based applications. | | | |
| ▲ | m_fayer 4 days ago | parent | prev [-] | | I would go as far as saying that the genius of the web is that it can grow, develop, be hacked, modified, expanded through technical and institutional means to be many things it wasn’t originally envisioned to be. Why is that a bad thing? Why is originalism a good thing? |
|
| |
| ▲ | graealex 4 days ago | parent | prev | next [-] | | Are you aware that nowadays you can write SPAs in dozens of languages? It's an entirely different concept. It's certainly not the right technology for a news site, but days ago in a different place, there was for example the discussion about how an SPA and minimalistic API services fit a lot better with your average embedded device. | |
| ▲ | tossandthrow 4 days ago | parent | prev | next [-] | | > Every web framework is _literally_ a hack to make the web something it isn't. Not this old grumpy person take again. Yes, the web is developing beyond delivering html content. | |
| ▲ | zwnow 4 days ago | parent | prev | next [-] | | Even with Laravel you will write lots of Javascript unless you go for blade templates or that other templating thing. Javascript is also great for making the web interactive. Maybe the sheer amount of SPAs out there shows us what we really want from the web. Most things ppl use in their day to day life cant be built with HTML and CSS only | | |
| ▲ | esskay 4 days ago | parent | next [-] | | What 'other' templating thing? I'm assuming you're likely talking about either Intertia or Livewire. Inertia's more geared towards SPAs than Livewire though. Most Laravel devs tend to use JS sparingly - not everything needs JS. Theres next to no reason why the vast majority of sites on the web would ever need to be heavily reliant on JS. Rendered HTML/CSS with JS being used sparingly for page functionality is a far better user experience. I'll never understand the obsession with JS for the sake of JS. | | | |
| ▲ | brigandish 4 days ago | parent | prev [-] | | > Maybe the sheer amount of SPAs out there shows us what we really want from the web. A distribution and installation system that works on almost any device? | | |
| ▲ | zwnow 3 days ago | parent [-] | | Interactivity and a way to build experiences and applications. Not just passing documents back and forth |
|
| |
| ▲ | motorest 4 days ago | parent | prev [-] | | > You miss the whole point and the author is correct about this: your comment is funny, because you are so wrong you aren't even aware how and why you are wrong. It's in "not even wrong" territory. I'll explain you why. > Modern CSS is powerful, and HTML is the way to deliver web content. Irrelevant. That's not why the world uses JavaScript frameworks. It seems you aren't even aware of the most basic reasons why the world migrated to SPAs. The most basic reasons are performance (and perceived performance), not only because the require less data to be moved around the internet but also every flow doesn't require full page reloads. Also, classic old timey server-side rendered WebApps end up being far more complex to develop and maintain as you mix everything together and you are unable to have separation of concerns regarding how your platform is deployed and ran and how your frontend works. SPAs even allow your frontend team to go to the extent of handing your backend as if it was a third-party service, and some SPAs are even just that. There are plenty of CMSs out there which eliminate the need for a backend by providing all content needs through their commercial APIs. This makes webapppp projects greatly cheaper and simpler to finance and support as you can simply bother about developing and maintaining your SPA. Lastly, those JavaScript frameworks you're trying to criticize also use CSS and HTML, by the way. So as you may understand your point is moot. > Every web framework is _literally_ a hack to make the web something it isn’t. You are clearly talking about things you have no understanding over. It matters nothing if you specify a DOM with a static file or procedurally. Updating only specific elements or branches of a DOM is a very basic usecases. In fact if you had any frontend experience at all you'd be aware that all mainstream GUI frameworks, including desktop, represent their UIs with a DOM. So here you are trying to argue that frontend development is not frontend development just because you have an irrational axe to grind regarding a specific class of web development technologies? > For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. If you hadn't already proven you are completely ignorant and detached from reality, this argument alone would leave no room for doubt. | | |
| ▲ | ahartmetz 4 days ago | parent | next [-] | | > all mainstream GUI frameworks, including desktop, represent their UIs with a DOM. If you call every hierarchy of visual items with some kind of layout manager(s) a DOM, then yes. Notably, the D doesn't really apply because GUIs aren't documents, and that's exactly why HTML is kind of awkward for GUI programming: it was initially designed for documents. Edit: Sibling comment makes the good point that the main difference is that GUIs have mutable state while documents don't. I would add that GUIs also have controls to change that mutable state, which is a more superficial difference, but well, web-based GUIs are still extremely varied in their interaction styles, which not necessarily good. | |
| ▲ | anonymars 4 days ago | parent | prev | next [-] | | Not the person you're replying to. I agree with a lot of what you are saying but: > The most basic reasons are performance (and perceived performance), not only because the require less data to be moved around the internet but also every flow doesn't require full page reloads. I can't keep a straight face at this one. If there's one thing the web isn't anymore, it's "fast." Presumably what you are getting at is server performance, because it's pushing all the work to the client. Anyway there's a good talk on this - https://veryinteractive.net/pdfs/ceglowski-thewebsiteobesity... > > Every web framework is _literally_ a hack to make the web something it isn’t. > You are clearly talking about things you have no understanding over. It matters nothing if you specify a DOM with a static file or procedural Don't be so dismissive. This is like the old anecdote about one fish saying to the other, "how's the water." The "something it isn't" is stateful. The web was not designed to be stateful, and every web framework is indeed a hack to work around that. | |
| ▲ | tucnak 4 days ago | parent | prev [-] | | Thanks for dissecting all this nonsense. Although in all honesty, we may as well be dealing with comedy here: green account, recommending PHP and Rails in 2025 as if that's supposed to solve anything... we're being trolled. |
|
|
|
| ▲ | mdavidn 4 days ago | parent | prev | next [-] |
| Some of us have been building web apps since before Node.js existed, and we remember the problem that CSS was invented to solve. |
|
| ▲ | TacticalCoder 4 days ago | parent | prev | next [-] |
| [dead] |
|
| ▲ | computerthings 4 days ago | parent | prev [-] |
| [dead] |
