React is amusing, as it makes it look like you have to have a complex JavaScript framework to have hot loading. But you don't. Never have. Will you need a fancy tool that knows JavaScript well? Yes. Do you need to be writing to that tool, or with it?
So, nobody would mock a carpenter for using power tools. They would question one that only worked with a 3d printer. Even though that would certainly let them iterate faster.
The primary reason to use React is that it's an easy API for working within the stateful component paradigm, and goes the extra mile in protecting you from state-related bugs. It still has value even if you drop the stateful part, it's not unheard of to build completely static or server-rendered websites with React without any client-side JavaScript.
There are performance penalties when it comes to the initial page load, you tend to win it back when it comes to subsequent user activities. Whether it's worth the trade-off is dependent on your use case. There are also downsides to progressive enhancement, an obvious one is that if your enhanced JS version changes appearance/layout in a noticeable way, you could end up making the website feel slower even though it's technically usable sooner. In addition, what happens to any existing interactions with the non-enhanced UI after the enhanced version suddenly appears?
The fact is, you just have to decide what's important. I do agree that not enough developers are giving real-world accessibility and performance enough consideration. But I'm less convinced that there's a way to approach these needs that is superior in all circumstances.
Granted, for some UI, this is hard to avoid. Those are much fewer and far between than given credit. Most state for a browser should be easily holdable in the address. If you find you can't do that, are you sure it is relevant state that your user cares about?
The idea that there’s a mythical user out there who absolutely demands serverside rendering is a bizarre figment of HNs collective imagination.
Then implement that. There are much more lightweight ways to achieve this than going full react. Especially with modern JS this can even be implemented from scratch.
Take HN as an example. Inline replying, voting etc. is undeniably convenient, but there is no way there shouldn't be a full page load when going through paginated results, or opening the comment thread to a post. That requires a couple lines javascript, no bloated js-framework-of-the-month. And the page stays completely usable without JS. A lot of stateful webapps out there aren't any more complex than this, structurally. Bonus: You get a fully working, predictable back button in your browser for free.
I recently used the best webapp I've ever used - LucidCharts. That was an app, and, as such, I didn't have the expectation that everything I did generated a new link, or that I could even link to certain things. BUT, they also struck the balance of providing web behaviors for things where I expected them.
And for the users on weak machines or connections, the reload version at least works, unlike the JS one.
The "users love AJAX" argument is both silly and honestly also a bait&switch. It's not really because of AJAX that people build their sites in JS frameworks.
Server side rendering HTML and serving it up works perfectly fast for pretty much every site which is read only content or forms. The of 3rd party scripts running on every page are the issue.
Also as a major negative against SPAs, once a script is loaded - it's going to be ever present on every page afterwards - enjoy explaining why payment details page needs 20 3rd part scripts running on it. Not possible to unload scripts.
If using that framework means that the developer can churn out something much faster, and therefore has time for more features, even if they aren't perfect or fast, is the user really worse off for it?
Continuing the carpenter analogy, it's the difference between using a nailgun and a dovetail joint.
Sure, the nailgun'd version probaly won't last as long, but if that means that the one carpenter was able to make 5 different shelving units that all looked exactly how the customer wanted them to look and was able to do it for cheap enough that they all happily bought it, is that really worse than only being able to get one expensive "better" version out and not being able to customize it per-customer because of time constraints?
And I know first-hand that those kinds of trade offs happen all the time. There are tons of times where "can we afford to add feature X" is a "yes" because we are using React in the app and spinning up a new component becomes extremely easy, but in applications which aren't using a framework that is often a "no" because we need to do so much more work to get it fully integrated and working.
I can only speak for one user, myself, but my answer is -- yes, the user really is worse off for it.
I get that there may be network effects that trap you, and you could be worse off because that means that by prioritising another feature they made one of your personal favorite features worse, but that really doesn't have to do with the technology used and more with what the developer is prioritising.
I can and I do, for as long as it's possible.
The problem is that JS-first fashion infects web shops, and one by one, websites are being rebuilt in "modern ways", rendering them less usable than they were before. Such sites would be easy to avoid if they were the exception, but you can't do that if everyone follows this trend.
It’s both amusing and sad to see modern web developers criticize Java for being “bloated” because they don’t understand the Abstract Factory-pattern (fairly light-weight, 2 levels), while themselves are using infinitely more complex and heavy frameworks to render what is more often than not is just static HTML.
Proof of that is that in languages where there are alternative patterns (like Python), people rarely create a factory, they use functions that return classes; they don't use singletons, they just use module static variables; they don't create observers, just just gather callbacks on a list; and so on.
There are many less formal patterns that do add a lot of value. And there are syntactic and type level patterns that are great, but typically OOP programs use those less than code in other paradigms. OOP has one common less formal pattern that is very useful and less used elsewhere - it's the abstract API, but this one people on the internet mostly recommend not using, because it requires inheritance.
Don't get too hung up on the implementation details in any particular language. A Python function that returns a class is just a factory by another name. The essential point is deferring the decision of which implementation class to instantiate until run time.
Inheritance is one way of handling abstract APIs, but not the only way (depending on language). And don't believe everything you read on the Internet. In some limited circumstances inheritance can be a great way to simply code and eliminate duplication, far outweighing any additional complexity it introduces.
Or just use interfaces. As in "design by contract".
And that's just common sense programming wise, not some OOP specific solution.
You can successfully apply OOP and OOP design-patterns to a lot of problems and come up with equally functional solutions as you would with FP.
And for certain domains, better.
1. It is designed to be testable. It makes testing the components much easier than testing jQuery soup. 2. It has an opinionated way for developing javascript applications 3. Will validate input types passed to controllers 4. Has nicer syntax than jQuery soup
I'm not sure if you're blaming the tool or not, but at least for 3rd parties, I want to clarify: jQuery doesn't mandate "soup" - In fact, devs learned over time that the best approach development with jQuery was the same as without - have application state tracked as variable(s), have routines to translate the current state into the the DOM. That's the unidirectional flow that React likes, and both vanilla JS and jQuery can run with it.
But jQuery makes it EASY to use your DOM as state storage, which works well at first and quickly grows nastily complex. Meanwhile, React makes it EASY to update the DOM from state without performing unnecessary re-renderings.
So jQuery doesn't mandate, or even encourage "soup", but there's nothing guiding you away from it. React, OTOH, makes the path of least resistance be towards this particular best practice.
To your points as to why people use React, I don't think those are bad points, but those aren't my primary points. React best practices mimic the best practices of coding in general: Small, single-purpose components with minimal coupling. This allows me to bring in experience from outside React, and allows me to apply React experience outside of React.
Model.
> have routines to translate the current state into the the DOM
Views. Triggered by #changed notifications.
> That's the unidirectional flow that React likes,
Aka MVC.
I really don't know what world that statement would be true in.
It is a full tool-chain, language, architecture, API spec, and testing framework. They are all closely tied to each other.
> React, Flux, JSX, GraphQL, Jest.
Opinionated implies there is "1 true way" to do things a la angular or ember.
react is most definitely not the embodiment of opinionated.
ref the multitude of libraries which were flavour of the month before something else came along.
> It is a full tool-chain, language, architecture, API spec, and testing framework.
Ok, now I know you're either trolling or have never used any technology but React to solve problems.
Just yesterday I was trying to use the Sendgrid support site. I was logged in. There was a "click here to login and send a support request" button (and no other way to create a ticket). clicking it just reloaded the page. There was a login link (even though I was logged in). It may as well have been a static image, you couldn't click it.
After a few minutes of trying the button finally worked. When writing my ticket the support system would scroll the page down on every single keypress so that the text field was aligned with the bottom of the browser and I was typing on the bottom few pixels of my browser and display. It was awful.
Unfortunately this "certain level of interactivity" is what I've come to expect from Javascript heavy websites. News sites where the content doesn't load. The re-rise of loading spinners, delays, errors, my CPU fans being exercised While. Displaying. Text.
> No one would denigrate a carpenter for using an electric screwdriver over a manual one.
No, but I'd complain if it took an hour to open my front door, took all my strength to do so, then when I finally got into the house it just fell into a pit and I had to start again.
I hate the rise of Javascript, and I resent that it has made the web a significantly worse place.
And copious security issues. This is why I block all Javascript by default.
It often takes longer for the initial JS-heavy page to load than it would for me to click & load 2 simple HTML pages. It's so bad that I just skip using certain websites when I'm on the slow internet.
I feel like a lot of devs do not even try testing their websites / progressive webapps in slow speed situations or on low end devices. If they tried they would understand why here if you want people to try your service you must build an app, put it in the store and keep network messages at minimum. Webapps are a good way to get a "Not interested, thanks anyway"
Honestly, I disagree with this. Iteration is great for developers, but not users. To use your tool analogy, users are attempting to use the toolbox you made to perform a task, but the content of the toolbox and how you use it changes every day. Users of the toolbox can never become expert users, because they can't ever rely on their past experience with these tools - the usage has probably changed in subtle ways.
Personally, I really hate having to re-learn how to use a screwdriver (or a blogging platform) every few days - and I'm a professional tool builder myself! It sucks even worse when I can't use your screwdriver if I only have 3G internet access.
Relevant: http://suckless.org/philosophy/
One of my first jobs was maintaining and extending an ASP.NET Web Forms application.
A dashboard style application has to do way more than open a dropdown. People keep the page loaded all day long - the fact that it takes 2 seconds to load the first time is irrelevant.
It's almost like for some the argument is more about some abstract concept of artisanal purity than true care for user experience. HN basically has a front page post decrying the state of the modern web every day...
Before anyone jumps down my throat about this I should add that browsing the web with JS disabled is a truly wonderful experience on sites that support it. It would be great if everything did. I don't see that happening though.
That's because developers are the only people who know what the fuck is going on, and who to blame. Regular users don't have a mental model to correctly identify the source of their annoyance. So they end up blaming "the computer". It often manifests in requests like "could you come over one day and clean my computer? I think it's full of viruses." No, it's not really full of viruses, just the websites you're using the most went through another redesign, and now consume 10x resources for zero added utility. But what can you do. I install adblock and sometimes buy them another RAM stick, so they can throw their laptop in a garbage bin a year later than they would without my help.
No, users do complain, you just have to know where to look (and actually talk to them).
As opposed to what, some abstract concept of ordinary users? What the sales department wants? The idea of craftsmanship isn't that abstract to me. Performance and cacheability aren't abstract at all, that a website can get reloaded many times even for just one reader, and usually shares memory and CPU and HD cache with many other tabs, is also a really obvious observation. Stuff that makes a noticeable difference even in isolation makes a giant difference multiplied with a triple trillion, I've done the math.
> HN basically has a front page post decrying the state of the modern web every day...
That doesn't mean there isn't a problem. There's also articles decrying environmental destruction every day, not on HN but in general - should that make one care less? Would you say that biologists and climatologists are more concerned than the "ordinary person" means the ordinary should be heeded? I'd be surprised to see scientists in a science forum talk like that.
Web development is an "art", maybe like architecture is art, and we are the artisans. If having any sort of ideals to strive towards is "abstract" to us, that says more about the people involved in web development and how much genuine excitement and care for detail was destroyed by money and marketing, but not much about web development as an art form as such.
Does a flood of crappy action movies say anything about the state of the art in movie making, at all? And yes, the "average audience" maybe likes them, but who cares? If they got something else instead, there's nothing they could do about it, and it would be better for them. I don't care if that's arrogant, but don't call it abstract :P
> I don't see that happening though.
That is like talking about sports or the weather, even if its true, it's pointless. The question is rather, what do we think should happen, and how can we make it happen.
No - users actually do want more features. They want more features than you can ever hope to deliver. Figuring out which features they will actually appreciate is the tough part. Your competitors are working very hard to build those features before you can. Your competitor's sales team is already cold calling your users.
Lightweight software is easy. As an engineer, I appreciate it, but it's not what the average user wants.
And for the vast majority of websites, the users don't actually want (let alone need) that degree of interactivity. A blog shouldn't depend on JS to be usable. A storefront shouldn't depend on JS to be usable. A restaurant page (even one with a reservation system!) shouldn't depend on JS to be usable. Even something like Twitter shouldn't depend on JS to be usable. Unless you're building something like Trello that's heavily dependent on drag-and-drop as a basic workflow, there is no good reason to make JavaScript a hard dependency on using your site.
If users are forced to allow arbitrary Turing-complete code to run on their machines because your site is inexplicably incapable of running without it, then you have utterly failed. That's harsh, but that's reality. Your users want oodles of JavaScript only in the sense that a penguin wants to swim through an oil slick.
I'll believe it when I see it. With notable exception of collaborative editing, most software on the web is essentially a subpar reimplementation of desktop software from 10 years ago, missing half of the features, but consuming 10x the resources.
True, but turnaround time is something that is primarily beneficial to developers, as it's all about reducing development costs.
I like that you speak in the name of "the users" who expect a certain level of interactivity, when that same level of interactivity on a page means many of these very same users won't ever see the page load fully, either because they can't be bothered to wait enough time on a slow connection, or because their browser/device simply won't do.
I see quite a clear contradiction here. And it kinda proves the point this post make about overly eagerly assuming users have a fast enough network and/or device.
Users don't expect interactivity, they tolerate it. Think of websites as obstacles or puzzles users have to solve to get to what they want. They would rather not interact with those puzzles or wait for them to load at all. If you understand that - you can't justify interactivity or most front end development for that matter by claiming this is what users want.
Large companies literally have entire teams dedicated to maintaining tooling. And don't even get me started on monorepos.
At a previous company, a co-worker that had been setting up tooling infrastructure for a project was astonished at my iteration speed when he saw that mine was written with just a micro-framework and ES5. Conversely, when I had to jump in to help get his project back on schedule, we could never figure why the hot reloading setup had a 2 second delay on my machine (among other things).
Having worked on two projects of very comparable scope (two documentation sites for different projects), one written with the "latest and greatest" Gatsby and friends, and the other with just a dirty script, I honestly can't see any reason to do the former: it takes longer to do anything, the final payload is bigger, and now the codebase is using a version one major out of date, meaning a migration looming in the horizon. On the upside... GraphQL; yay I guess?
With this point in mind, your carpenter analogy seems a bit off IMHO. Of course, consumers don't care if the carpenter uses an electric screwdriver, but they do care if a knob gets loose and falls off because it was held by a single rushedly-drilled screw. Also, the employer should presumably be worried if said carpenter keeps spending a significant portion of his time sanding his hammer handles and replacing his workbench legs, or needs another carpenter to do so on an ongoing basis.
I can't agree with this statement. It's 100% about how to benefit the company, which means satisfying the customer. And serving users up to the customers is the name of the game.
Most sites are heavy with trackers. You could argue that *one& might be in the user's interest, but can hardly make the same claim for the huge number of ad-related ones) and full of devious antipatterns. Just enough value for the user, one hopes, to get the page view.
I’m sorry, but pages that pull in several Mb of ads and tracking to show a couple of Kb of text the user actually wants are by no means constructed for the benefit of the user, any more than the line is baited for the benefit of the fish.
I actually don't work on any ad supported products. That improves my job satisfaction even more.
The majority of work that gets talked about here is technical work which is N levels below the business use case. Without the business use case you have no idea if it can be effectively built using server side rendering. Because of that I'm not sure anyone here is really able to make this statement.
If that were true, things like Amp would never have even been proposed.
Modern web browsers are absolute marvels, but shitty developers and business people are driving people like me into apps.
I'm far less optimistic about the web now than I was 20 years ago. I more bullish than ever on the internet in general, but the web is a mess.
I have to say, though, that if this is the case then far too many teams utterly fail. Quite a lot of (most, I think) web sites don't appear to be designed primarily to benefit users to me (user benefit generally seems to fall to third place, behind "make it pretty" and "use the sexy new tools"). And that problem has been getting worse over the last decade or so.
"No one would denigrate a carpenter for using an electric screwdriver over a manual one. No one would complain that the carpenter only cares about their "carpenter experience"."
I absolutely would if the result is that the carpenter's work is worse for it.
I don't know by what metric the work is, on average, worse for it.
I've been on the web since '91 and I've been more or less an obsessive user since then. I've seen the changes.
The web - again, on average - is better to use than it ever has been. Some websites suck. Some websites are awesome. The worst websites in '95 were unusable and had broken layouts/styles, but people act like every website in '95 was some perfect embodiment of minimalist engineering.
My opinion is very different. Fair enough -- we're different people.
"but people act like every website in '95 was some perfect embodiment of minimalist engineering."
I'm certainly not asserting any such thing at all.
No, it hasn't. It's still 100% about how to benefit users for most teams. That is quite literally the only thing that matters and everything else is a means to an end.
I'm not going to deny the fact that there are some shoddy websites out there. There are some sites that are using the latest and greatest JS stuff when really, they should just be using HTML and CSS. Fine.
The majority of the work that gets talked about here, by software and tech startups, will not be effectively built using HTML/CSS or server-side rendering. Since we're on the topic of users, users have come to expect a certain level of interactivity. They expect that if you right click on a row, you get a drop-down menu and you can delete it. They expect that you can do inline editing of an item without being redirected elsewhere. They expect that you can create a new thing on the page without reloading and redirecting.
Let's forget about that part, though. Most software features are, at the end of the day, experimental. We don't know exactly what is going to be a hit and what isn't. If new tools allow us to iterate at 2x or 5x or 10x the rate of old tools, this is a net positive for users.
No one would denigrate a carpenter for using an electric screwdriver over a manual one. No one would complain that the carpenter only cares about their "carpenter experience". At the end of the day, the "user" wants their cabinets finished.