It's my personal philosophy in many things, but I like to insist that it's far from being the end-all be-all of good engineering in general. Perhap so I don't fall prey to the usual weaknesses of a hacker.
> If Wikipedia were started today, it’d be React. Maybe?
No, I'm building a hard fork of wikipedia and I'm using Go to render the pages on the server side and a vanilla JS for a user friendly the rich text editor.
I don't know why not more people use WebComponents as a light weight alternative to React/Vue/Angular. It was natural choice in my case because it grew out of the desire to keep the tech stack small. For now I haven't find a reason to regret it, two way databinding is nice to have, but when the js is reloaded with every page, the global state is easier to reason about and less of a problem.
Probably because "more people" are not trained to "use WebComponents as a light weight alternative to React/Vue/Angular", let alone lead a team in that direction (and assume responsibility for a thing that has no market value on their resume... it's the situation 80% of tech workers find themselves in).
Momentum is a b#%~~ I mean, momentum is hard to ignore.
The sad reality is that trendy will always be driving behaviors for as long as recruiters attach value to buzz-words and -names.
Meanwhile, I guess a few will take the risk to do good engineering and damn the name of techs used, hopefully to rise to decision-making positions. Hopefully. Oh who am I kidding.
Both, its 2020 wikipedia should have had a WYSIWYG editor a long time ago. They keep making excuses why this can't/should't be the case, so I want to migrate over the content to a new system.
Wikipedia has been taking some strides in this direction. For example, on the "mobile" site, if you follow a link from an expanded page section and then go back, the section is no longer expanded, and you lose your place. (Then it re-expands, but you're in a completely different place on the page now.)
This type of stuff is one of the reasons why I choose to support older browsers like Netscape, IE, and Lynx. I think that a website which would have been usable 25 years ago has a much better chance of being usable by some random person using an old device I've never heard of and a browser I've never tested with.
It turns out that aside from HTTPS, most older browsers can do quite well with HTML websites! If you do it right, all old browsers will be able to render it because it'll work in WorldWideWeb.app.
However, if you want universal html (no changing the html for individual browsers) and some half-decent web-app functionality and no-js compatibility and accessibility and for it to look pretty, be prepared to spend many hours tweaking it.
Here's a video of some testing I did recently. Here, I discover that IE doesn't play nice with being forwarded to a URL which has an anchor at the end.
HTML should never have grown into the mutated application runtime it is today. The presentational concerns for documents are different from application rendering. The javascript stack should have been something entirely separate.
I strongly feel we should create a lightweight HTML fork that is again document-centric and doesn't allow for all of this javascript nonsense. Something that doesn't allow for stupid custom UI or behavioural tracking. Just text, images, videos, and links. The painting algorithm would be dead simple, documents would load lightning fast, and we'd be confident there would be no ad malware.
Creating it is the easy part, IMO. The hard part is to get people to publish on it.
I fear that most authors (and most creators of images and links) are not knowledgeable enough to see the web's shortcomings and that it will be very hard to explain the shortcoming to them -- with the result that most authors will continue to consider their job to be done once they have put their writings (and images and links) on the web.
It already exists and it is called HTML. It is how JS is used to load page contents that can not be tolerated.
Follow progressive enhancement. No JS should be required to load the contents of a page. If JS is included it should be to replace what would otherwise require a full page reload.
If it is not possible to load the contents of a page without JS or the JS fails to complete, then the page should show its alternative contents. The page shall under no case be left blank. This is graceful degradation.
This is advice for a web site owner, and I don't see giving advice to web site owners to be an effective way to help internet users who are very annoyed with the web like I am. Web site owners are embedded in an ecosystem controlled by entities such as Google and Mozilla who either don't know or don't care about the dissatisfaction I and people like me have with the web. I have come to believe that the best way to help internet users who are sufficiently like me is not to try to improve or change the web, but rather to start a new internet service outside of the control of Google, Mozilla, etc. Great grandparent seems to have come to a similar conclusion.
Modern web browsers are designed to satisfy goals X, Y Z, U and W. You are pointing out that browsers can be used to do X. I (along with great grandparent IIUC) are replying, yes, it can, but a new service designed to do X alone will probably do it better with fewer bugs and glitches. And all the web site owners with goals Y, Z, U and W are really getting in our way when we pursue X; our moving to the new service would give us a way to separate ourselves a little from those site owners, saving us a lot of time and annoyance.
I strongly feel we should create a lightweight HTML fork that is again document-centric and doesn't allow for all of this javascript nonsense. Something that doesn't allow for stupid custom UI or behavioural tracking. Just text, images, videos, and links.
HTML already has such a mode. It's called "turn off JavaScript". Fortunately, there are still plenty of good sites in that style.
(You can still have ads with plain HTML; they just aren't as annoying nor intrusive.)
Where do you get your news and stuff without JavaScript? I think HackerNews is just about the only website I regularly use nowadays that works without JavaScript
I'm not so sure that the evolution of HTML could or should have been different. The second thing I ever did with images and text was link them to other pages and arrange them in the form of a menu. When I learned to use CGI, the first or second thing I did was write a script to generate pretty menus.
The web's UI is a document-as-app model... documents that use a small set of interactive elements to create a cohesive and useful experience. It beat many competitors that were applications for displaying documents. Document as app works really well. Users understand it. It costs less to develop than old UI guidelines defined desktop apps. And is portable to users on diverse systems... Web apps (and web pages) have succeeded where entire generations of cross-platform tech has failed... or succeeded mildly.
We already know what happens when that system is created, though. Because it’s what the web used to be. And the result was that people hacked around it: rendering entire page structures as static, unresponsive images.
What you want is for web authors to follow progressive enhancement. No JS should be required to load the contents of the page. If JS is included it should be to replace what would otherwise require a full page reload.
Either you omit some interactive elements on load, or you try really hard to make sure that the JavaScript loads faster than users will click, or you make some elements not require JavaScript to work - like making them normal links or forms. Or some combination of those.
I realise I'm in the minority, but I use JS whitelisting, which means that any SPAs I come across in my web searches (a disturbingly large number, and unfortunately increasing) will quickly make me go back since I can often find what I'm looking for somewhere else, on a site which doesn't require running arbitrary code just to render what usually turns out to be static content anyway.
The state of web development has always seemed a bit odd to me, largely driven by fashion and a desire for developers to "outdo" one another in complexity. There's a ton of churn and ADHD as people jump around from one trend to the next; instead of settling down and focusing on getting the most out of a platform, they're eternally in search of the next one. Reinventing/reimplementing in JS what basic HTML and CSS can do is just one example of this behaviour. The massive overuse of the "modern" adjective is another, and quite frankly all this really irritates me, as someone who just wants to use the Web as a hypertext document system to find some information.
> instead of settling down and focusing on getting the most out of a platform
How do you know when to settle? Should we have stopped at jQuery?
We are doing exactly what you are asking for, but not in the way you like. Web developers are getting the most of the web platform. The result is that new frameworks and libraries are keep popping up. Most will sink, a few will float and it's okay, this is how evolution should happen. I don't like all tech solutions that I encounter just because they are new. I simply just don't use them in my projects, simple as that.
I'm sorry, but the web not just a hypertext document system to find some information, it has outgrown this idea probably 20 years ago.
And most backend engineers don't go architecture astronaut Kafka, Cassandra, Kubernetes, et al into seemingly straightforward concepts?
The number of times I've seen Kubernetes as part of an on-prem install of enterprise software when there will only be one node was hilarious. That front-end devs get flak seems to largely be because their choices are visible, not because they are any different from the weird heaps people throw together behind them.
Oh no, that's terrible and idiotic behavior as well. A lot of dumb decisions are made on both the backend and the frontend at many companies; one does not preclude the other.
For the bulk of websites that are mostly static with a little sprinkle of fancy interactions here and there? Maybe.
There is a time and place for React. Shocking to some, that place is not actually everywhere on the web. The bulk of the web IS actually about finding information. Few sites are soundcloud style webapps.
For context, I like react a lot -- I love its clojurescript re-frame variant. It is what I reach for _when needed_. The rest of the time, give me boring forms, pages, and jQuery and let me get on with my day.
I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CSS, and vanilla JS where precisely needed. Nobody listens.
You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least for me, I have to fight against every client, employer, and coworker to execute this approach.
Maybe web developers as a whole just got bored. They don't want to make webpages like they did in 2002.
Make a folder with some .HTML, .CSS, .JS files. Then sync it to a linux box. Wow, you're on the internet, a modern marvel. I see younger devs who don't even know this basic stuff. As if, this were all way more complicated than it actually is. It's not.
How do we get web devs back on track? Makers need to thoroughly understand their tools and materials, inside and out, for any industry. I'm just not seeing that as much anymore. It seems like an education problem, or maybe it's just human nature to go for new and shiny instead of practical and reliable.
I'm agreeing with you that the "modern web" is too complex, but the "make a folder and sync it to a Linux box" solution doesn't work very well for real-world use. It's easier and a lot faster to sync your static site to something like S3 or Google Cloud Storage and serve it from there. Now you don't need to secure and update your Linux box or be responsible for its uptime.
>It's easier and a lot faster to sync your static site to something like S3 or Google Cloud Storage and serve it from there. Now you don't need to secure and update your Linux box or be responsible for its uptime.
I was pushing to *nix hosts I didn't have to manage in early 2000. Actually, one of them I recently remembered and had paid a small lifetime membership for limited static hosting (<$100) and simple shell access and guess what--the pages I put together 20 years ago and supplemental files I had hosted are still there. Not only that, they still render as intended.
I've done absolutely nothing for 20 years at this specific host and it's working today. Yes, the content is fairly static and very simple (its 20 years old) but it's all there. It's a simple shared system and no it wouldn't scale out to support more than probably 10k simultaneous requests but its served its purpose over the years. No, there's no SLA. I'm not saying services like S3 haven't been able to improve on that older infrastructure but it goes to show what very simple systems are capable of.
I've not spent a second of time in 20 years worrying about security, someone else did for a very nominal fee. This isn't a new concept, now we have better scaling available for sure.
I agree with the sentiment of what you're saying, but I don't agree with the premise that there are no use cases for single page apps. You can achieve a decent UX for some applications by using small amounts of vanilla JS, but it's simply not possible to avoid re-rendering the entire page without using XHR requests at some point. That is how the browser is designed, fundamentally. Because it wasn't designed as an application platform, it was designed as a document platform.
But some products are actually better as applications, not interconnected documents. For those applications, the browser fights you every step of the way, because that's not what it's designed for. You simply can't compare the UX of document-based web applications to native clients.
An SPA is just the web approximation of a native client. Your application truly runs in the client process continuously, so rendering transitions happen smoothly instead of blank pages and jumping transitions. Everyone would benefit from understanding more and using that to simplify all areas of the tech stack, but the experience that an SPA offers is simply not possible otherwise.
SPA is a poor approximation of a native client with a hugely bloated browser stuck in some level of the abstraction, bypassing native app libraries, design sensibilities, typography guidelines and accessibility by implementing some UI framework that was developed by people that are entirely unqualified for it. Have you looked it the guidelines for UI development, say for MacOS? Here you go: https://developer.apple.com/design/human-interface-guideline...
PWAs, browser apps - they bypass all this work from professionals and give it in the hands of an unequiped developer. Oh god.
A browser is a window, an area of the screen that is allowed to do whatever it wants in a sandbox mode. This is a terrible idea. It becomes complete wild-wild-west.
>it's simply not possible to avoid re-rendering the entire page without using XHR
Wrong on two separate levels.
First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever.
Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs.
The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity.
If you pay even a little attention to order of loading you can avoid FOUC entirely. If you pay a little attention to defining sizes of leading elements, you'll have constant layout of the top part of the page, and avoid flash of white background. If you use anchors here and there your user will be scrolled to the proper position.
Yes your page can easily look as if it got only updated with JS after doing a full load+render.
The technology is already in the browser; no need to approximate it with three layers of JS.
> First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever.
Thats complete BS, Iframes are just loading other HTML pages so you still need another tech to allow for static HTML to re-render itself. If your just talking about some kind iframe jacking then I don't see how thats remotely relevant.
Objects/Embeds? Sure you don't need javascript to make a page interactive if you have things like Flash/Silverlight/UnityWeb where your just executing through a completely foreign API usually via a plugin.
> Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs.
Maybe if your using something older than sandy bridge trying to use facebook I guess but outside of these kind of silly edge cases, ive rarely seen an iphone/macbook/desktop from the last 5 years spend more than half a second on any kind of heavy redrawing logic ever.
> The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity.
Then they can use another app website without JS that does all these features they want but with Iframes and flash.
You can’t compare the UI of a web page built in this way to an SPA or a native client. Re-rendering an entire page on every interaction is strategically never going to get you the same experience. I understand wanting to be a browser purist, but web applications have had pretty laughable UX compared to native apps of even 20 years ago.
I mean look at an iOS app designed by Apple. I always reference the AppStore app itself. You simply can’t build that app as a web app, certainly not by using iframes as a “solution.”
You don't need an SPA to use XHR, and your description of the SPA experience for the end user is a fantasy - there's a reason pretty progress bars are popular in SPAs, and it's not because of fast state changes, quite the reverse.
It's funny, your example actually shows the primary benefit of an SPA, and doesn't do anything to show any downsides. A progress bar is a perfect example. You can't show a progress bar with HTML. You would have clicked something, and a new page would be rendered entirely. In the time it took to create the new page on the backend, the user would be staring at either a white screen or the current page. If they're looking at the current page, they probably think the application is malfunctioning, as no user feedback was given to their action.
Whereas, with an SPA, you can _instantly_ show a progress bar, at least indicating that something is going on. And, the very fact that you're showing a progress bar means that the client side rendering isn't the slow action, it's retrieving something from the server. So, the UI was as interactive as possible.
This is an amazing feature you simply don't need on the majority of web apps, because a) the browser has a loading indicator and b) most web apps are fast enough to not need to tell the user about it, they just load new pages in milliseconds instead.
An in-page progress bar is in most cases a failure of UX, not a success.
Please write more about this because I feel the exact same.
Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static. Why do you want things moving around and reacting? People of the internet - imagine if the internet protocols were given to us, but no browser existed. Would we develop this non-sense we have today?
What should have happened is the following:
- Develop web-to-native-UI mapper, call that thing a browser.
- Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig.
- Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app.
The web went downhill the day `<input>` tag was allowed to be styled by CSS. We had a web-to-native-UI mapper!
I am forever a believer that democratically designed things generally suck unless there is a BDFL who can make shots. Dictatorship is a necessity of great products and services - Steve Jobs to Guido, democracy is good in politics, not in software development. Feature creep from the public will ruin whatever youre buidling. Designers will ravage through what worked well and replace it with "taste".
/Rant, I am getting old. Humans tried to make the web "pop", but instead it exploded with chaos.
Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static
Exactly. As a bonus, you automatically get the behaviour associated with a link that browsers already implement: people can bookmark a link for later use, open it in a new window, etc. All of which would need extra effort (and thus also easily break) if it was just a clickable element invoking some JS.
I've had some pretty annoying conversations with customer support and developers about things like this; almost always, the response is something like "we didn't think you would have a need to do that". They would not have needed to think about it at all, and it would work for me, if they had just used a regular link.
That said I'm not totally opposed to SPAs; highly interactive apps, e.g. realtime games and such, would definitely benefit as they wouldn't really make sense as a linked set of documents. But for everything else it feels like they not only reinvent the wheel, but make it square.
It's not even the ability to bookmark it. It's basic stuff like the ability to restart my computer (e.g. because Windows demands that for updates), and go back to the same exact spot I've been at. For desktop apps, this works. For web pages that are just web pages, it works. But with something like Facebook, if you close a tab in which you've been scrolling through the feed, that state is forever lost.
“Let the page refresh” translates to a terrible UX. It devalues the application. It’s equivalent to buying a physical product, say a car, but the car jerks up and down whenever you hit the gas, and you hit your head on the roof every time.
Yea, the web page _works_ but it’s ugly, and in poor taste. Users do not care about browser purity, they want an app that seems polished. You can’t get that experience by using semantic HTML at all.
I'm pretty sure blind people don't even notice this 'terrible UX' problem you describe, and that sighted folks aren't quite as jarred by it as you think.
This 'taste' issue probably matters more in some organizations than others. Hopefully they don't involve blind people in their business, because SPAs are notorious for being unusable to them. You can design an SPA with accessibility in mind (https://www.deque.com/blog/accessibility-tips-in-single-page...) but most devs either can't be bothered or aren't even aware of the issue.
Yes, people who don't have the ability to see won't care about flickering on the screen and the better user experience that a single page app affords to users who can see. Not even sure why you're making that point other than to try and imply that people who write single page apps automatically don't care about blind people, which is self-righteous and rude.
We have a single page app and we regularly run it through screen readers to see what the experience is like. Since an SPA is not some magical entity and it does produce a real DOM tree, we can achieve a great degree of accessibility (not perfect) by simply focusing on the markup that's produced. That doesn't help with things like loading screens, but again, since we actually check applications on screen readers, the experience for pages that take a long time to render is not much better with pure HTML either.
I read the link you posted and it's a good resource. The #1 takeaway I got from it is:
> Make sure that client-side view changes are known to screen reader users by announcing the change in page title, using ARIA live regions and/or focus management.
That's a good idea and one we'll incorporate into our application.
Some other comments in the article are not helpful, such as:
> Consider whether a single-page app is really necessary, and if you even need to use a JavaScript framework at all.
This is a moot point. Using a JavaScript framework to create an application is not only acceptable, but extremely popular. So instead of trying to politically smash the idea of building an application using JavaScript, we should be focusing on how to improve accessibility in that landscape. We can and should figure things out.
I'm glad there are people out there taking the accessibility issue seriously, what you said does make me more inclined to evaluate framework-based solutions. Nice to know at least parts of the most popular JS platforms are maturing enough for this to be easier for devs to implement.
Can't agree more. It's a very simple point but I am surprised that people couldn't realize it and even downvoted your view.
IMO, discussing this further will just yield a negative returns as I think there are some fundamental issues/gap between two parties in this thread.
No matter how much ppl kick and scream, the SPA is gonna make the web a much more user friendly place in general. When we fade away and the next generation of us come, they will take this as the new norm easily and happily.
They can, but it requires additional work on the part of the developers, which in my experience is almost never done. Also, that's kind of what the SPA acronym stands for, no?
> Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static.
To be completely honest, this is one of my least favorite things about HN. As I write this comment and click reply, if I wish to navigate “back” after I post this comment, the first back button click with take me to this still-filled comment form. (Will I fuck anything up by clicking “reply” once more? This is an easy trap for a user to fall into.) The second back will take me back to the post comments. Which is weird, because this is where I was taken after posting the comment. The third back will take me back to HN homepage. I expect to go back to the homepage on the first back click.
And this nav stack works as it does because HN uses plain HTML forms without any “overkill” JS. But the reality is that the default back behavior doesn’t really fit most user expectations, because most people don’t understand that clicking each of these buttons added more and more to the stack. Most people don’t know what a stack is! :) I think this is a great example of why the default document behavior of the web doesn’t really match most people’s user expectations, and the normal form behavior on the web makes it way to easy to do the wrong thing, like re-submit information.
> Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig.
> Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app.
I'm not sure if this was supposed to be a case of 'how it once was' or 'how it should be', but this was never a reality, at least after the 90s. Native apps have always tried to style themselves just so (my company has a C# B2B GUI that has a little bit of assembly somewhere calling a Windows interrupt directly because they couldn't figure out another way to change the color of some window element). Even the earliest web pages were often trying to look as different as possible.
Just chiming in to say this is an absolutely viable approach. I just built a project, over about six weeks, using mostly vanilla js and some jquery (the heaviest widget I have is tinymce, which is a necessity unfortunately), and started selling it about two weeks in. I'm up to $650 mrr and the sky's the limit (really, the market is huge and desperately underserved), and not one person has complained about it acting like an old style website. People are just happy it works. And mobile testing was a breeze.
If I tried to build this on a "modern" stack I cannot imagine any benefit, only drawbacks.
So unfortunately the live project has no public-facing component; without going into too much detail it helps certain corporations and larger nonprofits with a kind of compliance. But, I can tell you that I based it very closely on the layouts provided by the ultra lightweight css framework, PureCSS. (This is also my favorite framework!)
One other remark: people are happy when they learn about this. That is now my #1 predictor of success. Everyone I've demoed to has adopted the product within a day (usually during the demo), and tech wise it's no different from what was possible with the web 15 years ago.
As someone who uses React/Mithril and has just been hired to work mostly on jQuery, you obviously haven't had to build something more complicated than a wordpress blog.
Because Rails, Symphony, Django, Phoenix or whatever does the job in the preferred language of the developer/team and often has more batteries or better tooling included.
I bet those are not a Front end's preferred language and you end up need JavaScript anyway if you need some extra client form handling. Now you use two language to do one thing and made it more difficult to be maintained.
I've often said that web development has a big culture problem.
In any other field, 'modern' is the opposite of a selling point. People want tools that work, that are proven and have years of stability and momentum. But in web development, there is an obsession with the new and shiny. It's 100% about the developer's own experience in creating a program and 0% about the user's experience actually using the half baked and constantly changing web app.
On the backend, shiny technologies like Go have been exploding — Go modules only stabilized this year! Since React was released, we’ve gone through through at least two new ways of deploying a server — containers and serverless, replete with their own huge abstraction layers like Kubernetes — and we’ve moved from monoliths to microservices and back again. And in native land, the “Rewrite It in Rust” crew is doing their best to bring the new and shiny to systems programming.
I agree that frontend web developers are maybe a bit too enamored with new tools. But I don’t think that mindset is unique to them, at all; they just happen to be the most numerous and visible examples.
Is Go really "shiny"? I mean, it's probably the most conservative mainstream PL on the market today, rivaling Java in some respects. Many claim that this is in fact why it's so popular.
On the backend, shiny technologies like Go have been exploding — Go modules only stabilized this year!
This is only true in shops where webdevs dabble in back end, same as node.js. In most places you will find recent versions of things that may be decades old - Python, Postgres, Apache, even Linux itself.
Go and Rust are both older than react. And I 100% agree that backend people overengineer with stuff like kubernetes. I think that's less about the new and shiny and more an obsession with scalability - even though the site could easily be hosted on a single Linux box.
I have just recently been tasked on estimating how many people in our city would fit your standard job requirements if we applied them to Go... since the requirements are legally necessary, we had to ditch any plans of using the language.
I don't think "exploding" is the correct word, although it is growing.
I have adhd. in my experience, commodifying the use of ADHD as anything other than a mental disorder makes it easier for people to make claims like "everyone is a little bit adhd" etc.
An ADHD diagnosis is not purely based off of exhibiting behaviors typically associated with it. While everyone is forgetful/distracted sometimes, ADHDers have a physical/chemical difference in their brain which make such behaviors impossible to avoid.
> Suggesting the whole world stop doing this is silly
Just wanted to say that I don't think this is a silly pursuit, and I'm sure plenty of other people reading feel the same way. I think this is a serious issue because the language we use is related to how we act and treat each other, and talking about the issue has a real effect.
Reminds me of the quote attributed to Margaret Mead, whom I actually don't know anything about besides the quote:
"Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has."
Too corny? Idk. I like it
Yea maybe save it for when speech is actually a real issue and not over policing and treating it like it's your personal servant. Grow up and get over it
IMO React and it's ilk are amazing in some applications but the problem is trying to make 'everything' a React/Angular/Vue app without considering scaling or how it would benefit a user. I have been tasked with building complex UX'x which would've been far simpler and performant as a multi-page type app with some plain JS sugar.I agree with wrnr - I too am leaning more towards WebComponents where some dynamic functionality is required. It provides us the ability to not only keep the tech stack small and also avoid all the dependency and version pitfalls.
Dan Abramov put up a tweet thread agreeing with this piece, and talking about how the React team is now looking at trying to come up with some server integration capabilities to enable a hybrid model for the rest of the community:
"React is bad in your case, drop it." I know it's far out idea in tech, to flat out tell someone "you don't need this, you just save time and money and get a better result of you don't use what we made", but it shouldn't be.
React is fine per se, the problem is throwing these "simple, magic" solutions onto everything, without even caring what mountains of code end up running as a result. The minimum for a Discourse installation is 10 GB, for example, but PHP is the weird ecosystem, because reasons. I don't mean to pick on Discourse, but that's still crazy to me.
I personally liked how easy it was to install Discourse thanks to Dockerization, and don't care one whit about requiring 10GB of space (cheapest DigitalOcean droplet comes with 25GB).
Fine, but that kinda falls under "without even caring what mountains of code end up running as a result". You use 10 GB instead of a few MB, and get an easy installation vs. an easy installation.
It's like driving a huge truck everywhere, even to get the mail from our mailbox, because it starts up real fast and we don't have it far to the garage from our living rooms, and then later on because we haven't walked in so long, we don't even remember what it is. And especially with websites, people also tend to forget that their website isn't the only thing anyone ever runs on their machine, some have to share resources with dozens of tabs.
Discourse and software like it was not as easy to install. This was literally one-click. Installing wordpress and such in the past required installing PHP, MySQL, yada yada on your server to get everything running.
Every distribution in the early 90s/2000s came with a ready to go lamp stack. If you have to setup the whole environment for docker yourself it is basically the same work as setting up a lamp stack.
PHP is literally the reason I first used Kubernetes in anger because the sheer impossibility of getting sane deployment configuration without dockerization meant we had to get something that could manage them for us.
I've always felt like the vast majority of apps do not need to be on React. It's too low-level. Surely it makes more sense to just use a framework like Next or Ember, where you can focus on developing your product functionality (what sets you apart) rather than bikeshedding on routers, build configs, developer tooling, etc.
I think a lot of the problem is React's syntax and ecosystem is too complicated for the majority of sites out there. IMO using React to make static sites and regular CMS / document type sites is way overkill no matter how performance optimized it is.
I've been experimenting with Vue and I'm liking it more and more just for the simplicity.
Ract syntax is functions + jsx. Jsx has just a smal set of additional rules compared to ordinary html, so I would not call it complex. In Vue 2 you have directives and wierd object model where you store data, getteres, watchers, etc. Each library has its own set of things which needs to be learned, and for me both basic vue and react are easy.
Jsx is not complex but it adds additional cognitive load keeping in mind everything is still JS and the small differences between Html. Also the common libraries that people use in a React app tend to be overkill. Things like Flux/redux add way too much boilerplate for small-medium projects yet everyone uses it.
Hasn't this hybrid model used by many for a long time already? SSR react as most as you can(try to avoid client-side routing), then hydrate/enhance parts of the page and make it dynamic.
> There’s no category winner like React as an alternative
I'm really rooting for frameworks like Phoenix LiveView, Rails Turbolinks, Laravel Livewire to fill this void. SPA like interactivity by just rendering HTML templates and sending them to the client via Ajax or websockets sounds great to me.
I quite like Turbolinks too, but it can have some unintended interactions with other JS code. If you're looking to make your non-SPA site faster another way, you can try https://instant.page/ as well. It preloads pages as you hover over them, which makes links feel like they load instantaneously. It's a pretty cool trick! You can try it out on their project website or on https://www.snazz.xyz.
The Android turbolinks version 1 adapter is now deprecated but a version 2 is meant to be coming soon. I believe it's going to come out after Basecamp's new product named Hey is released shortly.
I've been freelancing whilst working on some of my own projects, and have helped a devent number of clients get their front end approach cleaned up enough to work for their end-user and use case.
So when I read an article like this (which I like by the way), I make comment/response style notes to make me think through it; its long but I've dropped it in here in case anyone cares:
The issue with bundle splitting for SPA's that he mentions is a real thorn in many peoples side. A not amazing, but workable solution is to structure the site as follows:
* Split your "entry" bundle down to nothing, so it is only the map of other things that can load and a bootstrapper that looks at the URL and loads the right one.
* On the server generate html files for all your main endpoints (or hot routes for dynamic paths), ideally these are Server Side Rendered, but at a minimum they must include a script tag for both the normal entry bundle and the correct primary bundle for that page (ie, you eliminate the round trip for requesting the bundle).
The issue of running an "out of date" app is a present one. I can often restructure it to gracefully cache the state and refresh at an appropriate time without the user noticing, but it is often a far cry from simplicity.
His attack on SSR is largely correct for the way people currently deploy it, but there is nothing stopping you doing it a lot better. It is perfectly possible to generate correct HTML that works without needing to have a hydration step - its just most people aren't willing to, or knowledgeable enough to, do the work to make only the parts that need rehydration be hydrated (or, allow everything to be rehydrated but with no effect to the majority of the page). To be clear, you don't need to hydrate links, buttons, or even basic forms.
Of course, anything that genuinely requires your app js to be around to do anything reasonable needs to be there; but if you aren't looking for a drag/drop stay on page interaction you can normally just add a traditional route to allow it as well (more work of course).
He is right about API's. Though I'd hardly count it as a web or an SPA problem. Software is all about abstractions and how they are very leaky (likely "unfixably" so).
I was surprised about the data fetching comment. I've taken a look at the React docs and done some searches around the web, and he's right. Unless you know what terms to search to get the useful patterns its just a mess of amateur/broken Medium posts.
SPA's are built on top of browsers that are trying to predict where we are going and react to where we were yesterday at the same time. I'm with the author that most things don't need react, and that the things that do are mostly SPA's that have to be SPA's. I have worked with other frameworks before, but my hammer is a nodeJS & React stack I've cobbled together; thankfully its very good at SSR generating static sites, so most people don't know I'm using such a big hammer.
And we finish with a wishy washy maybe its right maybe its wrong, do we need this, maybe we do, maybe we don't.
Here is something concrete. I'm writing a small web application for my sisters business that I'm going to be doing all the legwork to see if it can grow into something. It isn't a SPA, it has some highly complex interactions, and it only uses React as a static site templating language because of my exisiting well-tooled stack (hammers make things nails).
The only important question is whether this is a technology problem or a business problem. Fundamentally the problem is this:
Web developers don't know what they are doing and oversell their capabilities.
To be more clear though, this isn't a new problem, just that the symptoms of the problem have changed as the tools have evolved. I remember starting at Travelocity in 2007 and they sure as shit didn't know what they were doing either. All the JavaScript developers there, except for 1 (so about 6 of them) were spun off onto a special project that never made it to production. There was 1 guy left to write JavaScript for the rest of the site in a company who only real product was a website and employed 3500 people. All the other developers were Java people. Most of those guys were scared shitless of web technologies. There were a few Java developers who had a solid working knowledge of CSS and JavaScript but worked extraordinarily hard to keep that a secret.
That was a big WTF, but then I discovered it was also the same at both Expedia, Orbitz, and Southwest.
Now people really, and I am not being figurative, expect Angular and React to do their jobs for them from solving technical problems to telling them exact what products to build.
Worse still is when you point out the incompetence that so clear to everybody else the developers doing the work get angry. I mean hostile out to stab in you the back angry. The non-developers see the dysfunction and have absolutely no idea how to manage it or solve for it. Sometimes the dysfunction is so pronounced that it leads to inter-department warfare within the company, as was the case in one of those previously named travel companies (not Travelocity).
Here I am 13 years later working on the web that is now a 30 year old platform (20 years old if you count the modern standard web), and its still the same shit show. How have businesses allowed such cancer to prosper?
What you describe as "broken" is what I imagine to be the ideal situation.
I expect travel agencies and similar websites to have a rock-solid back-end, and I don't care at all for any Javascript fanciness. In fact I would expect their websites to work with JS disabled.
The fact they canned whatever special project the JS developers were working on might have been the right decision (and I just checked, Travelocity is still in business).
> I expect travel agencies and similar websites to have a rock-solid back-end
They had no such thing. Sometimes their shopping carts were so horribly incompetent it’s amazing we generated any revenue at all. Pretty bad since they had no idea just how broke it was until investing in something like Tealeaf.
This is an absolutely perfect take on what’s wrong with front-end web right now. I've been trying, and failing, to explain this at work for several years now. Indeed, swimming against the cultural tide is hard.
React is built on two fundamental ideas that are both extremely valuable. The first and most transformative is that the web is mostly made of _components_, and specifically that organizing the markup, javascript, and CSS makes many thing easier. The second idea is that _declarative programming_ is better than imperative.
The thing is, HTML and CSS are already declarative. So React is not inventing this, nor bringing it to the web, but rather providing a pretty solid idea for how to make Javascript (or more generally, complex interactivity in the browser) declarative as well.
Thus, as MacWright argues, there is a sweet spot for React (or similar libraries) where you have highly interactive, complex UI elements on the screen.
But the rest of the web really, really doesn't need it, and when you try to apply "React Everywhere" things get very bloated, slow, and complicated, very fast. This is _especially_ true if you didn't start from scratch with Next.js or create-react-app, but are incrementally converting an established application. It's just painful.
I think more and more people are realizing this, and the fact that Dan Abramov himself agrees is pretty indicative that the tide is going to turn. But the question is, what next?
One major problem that the author didn't go into is the special pain of bundling front-ends these days. The actual work of setting up and integrating a "modern" javascript asset pipeline with a server side framework is not trivial, and I've yet to see a framework nail this. In the ones I've used there's always some gotcha - if you don't roll your own web pack (and understand what every bit of it is doing), you will eventually run into some library you want to use that just won't play nice with the rest of your bundle, and then you have a problem. And on the JS side, even simplicity-focued tools like Parcel are SPA oriented, thus gluing them together with your server-rendered app is non-trivial.
I think that will remain an issue for a while. But it also means there's an opportunity for the "old school" frameworks to keep working at this and, if they really nail the bundling and server-rendered / reactive component handoff, to thrive in the next decade of web development.
The problem with not using a JS framework is that eventually, the investors/business person/design team/frontend enjoying devs wants this highly animated site with all sorts of little toggles, confirmation boxes, popup models, toasts, etc.
It is far nicer doing that in React where you can just casually npm in some online component that does that rather than in vanilla JS or jQuery. React is basically a compromise between nice interactive websites and keeping it as programming.
Nothing stays simple and when it stops being simple, you want React.
Developers like simple sites like Hacker News. Nobody else does.
>Developers like simple sites like Hacker News. Nobody else does.
I'm not entirely sure about that. Pretty sure most people just want some program to accomplish the function they're using it for so they can move on with their day, not chase around an overly complex and forever changing UI they have to keep up with, ontop of their actual work.
Well, when I am considered a developer AND a stakeholder I may be able to address that AND not be told that I'm going to implement the carousel because "market research" anyways.
I expect it, and I demand it. We're in 2020, I don't want to click around on hyperlinks - I'm sorry. I grew up in a world of interactivity and the iPhone.
My bar is very high for consumer services. Animations and smooth transitions are table-stakes.
Surely you also grew up in a world of web browsers and hyperlinks. They haven't gone anywhere. There's just more applications on the web now in addition to traditional websites and hybrids. When I use the browser on my phone, I'm usually touching hyperlinks to go to different sites and pages, and often those hyperlinks are shared on different apps.
The cases which should be simple, don't give anyone a chance to be impressive. This applies not only to the devs, but also to the managers (and designers, and etc).
I am impressed with simplicity, but most people aren't.
> Developers like simple sites like Hacker News. Nobody else does.
People like Google.
I'm convinced that users don't care for most "design" and "clever layout". Site owners do, but users don't. Which is understandable, you want your site to stand out so you make it special. Users usually don't want special, they don't want to think, they don't want to figure out where they need to hover for functionality to reveal itself etc. I do believe that users would be much happier if layout/design possibilities would be much more restricted, like they are on mobile, because there's no constant re-learning there.
The problem is that designers and developers need to get site owners on board, so they are selling to site owners.
>Developers like simple sites like Hacker News. Nobody else does.
StackExchange ( Which is not only about developers ) Serve their Server Rendered HTML page in less than 20ms at 98th projectile with little to no caching.
They didn't even bother caching their most popular section or page.
> But the cultural tides are strong. Building a company on Django in 2020 seems like the equivalent of driving a PT Cruiser and blasting Faith Hill’s “Breathe” on a CD while your friends are listening to The Weeknd in their Teslas. Swimming against this current isn’t easy, and not in a trendy contrarian way.
more like, your friends are listening to Weeknd on vinyl and gramophones because their friends do. The more i read about JS frameworks the more i want to start doing everything in Perl again, or C, because its the work that matters and not the tools.
> But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are optimizations to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.
I think this is at the root of it — most web devs today don't see that some plurality or small majority of web app use cases these days just don't require the tradeoffs of SPAs.
But there's a generation of devs who've come up exclusively on JS tooling (Node, Express, React/Redux or Angular) and the crowding effect has therefore made those the default choices, if only because the labor pool is big.
My honest belief is you can more quickly build most functionality needed for most businesses with a plain-old full stack framework like Rails or Django these days.
But the real value of those frameworks doesn't show in the initial speed to build (though it's there!) — it really shows up in how much common functionality (logins, file uploads, etc.) you get for free 6-12 months in, and how low your cost of change stays over time as a comparable SPA app becomes a pain in the butt to add new features to.
I agree with this. In my experience, adding React or friends doubles the size and complexity of your application and in a lot of cases, the benefits accrued are not worth it. You essentially end up having two applications to maintain and therefore two places to manage state and make sure they sync correctly.
I commented below that I hope frameworks like Phoenix LiveView will be the future. Seems like the best of both worlds, the simplicity of server side html rendering with SPAlike interactivity. Of course not perfectly. There are tradeoffs no matter what decisions you make.
Speaking as a young(ish) dev, I think the issue with SPAs is that it's that its use has been conflated with separation of concerns and agnostic backend dev.
What I mean by that is that the way we learned is that the old/wrong way (php style templates) mix front end and backend development, and data with formatting. It's better to have data available through rest APIs and then consume it from something. Which is mostly true if you plan on being available in a reasonable way from smartphone apps, etc. but of course that means that your website should also be a client capable of working as similarly as possible to a mobile app - there you go, SPAs.
We need to find a way to keep those benefits without the bulk of current SPAs. But SPAs appeared for a reason, and it would be wrong to ignore why it happened. Being able to have front and backend devs working in parallel is a benefit, being able to server your content to several frontends is a benefit, etc.
(And if you're thinking "these people don't need apps anyway", the reality is that clients demand to have them - even if it's only so they can bother users with push notifications or collect data, they do ask for them).
There's no thin line for this, CRUD-FORM can be really complex or really simple. A thoughtful design choice must be made here between server-side-rendered html with some JS and a SPA.
The first big project I had as a professional SWE was to rebuild a checkout page to use React. Seems like overkill for a single checkout page to be its own React app? It wasn’t. There was a lot of edge cases. It needed to handle different countries (some have states, some have zip codes, Brazil has a crazy tax scheme), different SKUs, different payment methods (including resellers), free trials, etc. The original template + jQuery rendered version was nearly impossible to work with. Any sort of change would take forever and would lead to bugs whose patch would only increase complexity.
React substantially simplified the page, and it actually looked and performed much better since there wasn’t any jankiness from HTML rendering before JS could correctly format the page. We were then able to experiment on the page to optimize the experience and drive conversions.
TL;DR, more often than you would expect, the tiny performance costs you face from using a SPA is more than made up for by being able to develop quickly and more confidently.
We should create a better division in web standards between the "document web" and the "application web." I think there are valid use cases to both, and we shouldn't rule out either. Wikipedia has to be the greatest realization of the initial spirit of the web: an endless interconnected network of articles of varying topics. That's a real use case, but it's not the use case of _every_ application.
Some applications really want to make use of a richer UX, one that doesn't need to re-render the entire page from scratch on every button click. Maybe Gmail is the best example of using the SPA experience to drive a rich UX. The web browser was not meant to build such applications, that's something we don't acknowledge enough. The web browser was designed, since day one, to render and link between text documents. We've been trying to play UX catch-up for 20 years at this point, and it's finally converged with lots of support for treating the web as an application platform as well (React, Angular, etc.)
So we've taken years to arrive at SPA's, but I think they're completely justified. They absolutely have tradeoffs, but they're not pointless tradeoffs. That doesn't mean that all applications should be SPA's, but I also think it's completely wrong to say that all applications should be simple documents too.
> Maybe Gmail is the best example of using the SPA experience to drive a rich UX.
My experience is quite the opposite. I still use Gmail's "Basic HTML" UI, and it takes less time for me to click a link and load a new page on that UI than any interaction on the default UI.
That’s ok. You should have the option to use that UX.
I can tell you that any non-programmer on the planet would ever choose that UX over the “app-like” feel. I think we forget that most users are not programmers way too often.
> We should create a better division in web standards between the "document web" and the "application web."
Why are those the only two options? By those terms do mean "document web" as HTML without any JavaScript and "application web" as HTML with any JavaScript, or something else?
"Why stop at two" is an excellent question, but the first cleave is the heaviest lift.
I think the first seam should be network requests. Unwind AJAX: produce the "content web" and the "interactive web." The content web should be HTML with JavaScript that can respond to events, but cannot fetch new code. This sterilizes the malware aspect of the web: JS can no longer track you (it can in crafty ways but ad blockers are a match for these).
The second seam should be aimed at the other direction: empowering the web. Factor out the "app web." This provides a native-level API which can dispense with the anti-fingerprinting, second-guessing nonsense. But the app web has higher barriers: revocable certs, user reviews, potentially frictive installs.
Eventually a document web might become interactive. For example you start with something basic, now you want to show some animations. For example in geometry visualization.
Sometimes you just need something dynamic. I need it in 99pc of my websites. Why would I start with plain js, and then move to react. Plus I already have a base in react that can be shared with all websites. Much easier to maintain all in react than a mix
> Maybe Gmail is the best example of using the SPA experience to drive a rich UX.
Gmail is is the perfect example of an app that loses more functionality than it gains by being an SPA. Middle click to open an email in a new window doesn't work, if it was a normal web page that would have come for free. This is more important functionality to me than saving a page refresh. Same goes for JIRA, middle click at least works but the the 30+ seconds to reload the SPA in it's own tab makes it unusable.
These are both document driven apps and the document viewer I'm using them in have some great features that they cripple.
> Middle click to open an email in a new window doesn't work, if it was a normal web page that would have come for free
The fact that things like middle click and right click can be overridden in javascript is pretty much one of the biggest failings of modern browsers in my opinion. It's developers giving the middle finger to standards, and browsers accomodating those whims without considering the end user whatsoever. If your grand design doesn't include basic functionality that browsers provide then great, feel free to create a native application that fits that design. Otherwise, please leave the functionality that I rely on every day, and works in 99% of other sites, alone.
Your conclusion is hard to disagree with. I don't think anyone's saying all apps should be SPA's or no apps should be SPA's
I think what a lot of us are saying here is that SPA's in general are overused in our industry when simpler solutions are more appropriate. And that's having a negative effect on productivity and developer happiness.
What I dislike the most about the modern web and the unnecessary use of SPA technologies is how unreliable and error-prone it has made sites that really need to be simple and reliable. For example, banking websites, utility websites, government websites (like DMV, unemployment, and others), anything where failure or mistakes have a high cost.
These sites should stick to reliable, tried and true, pre-SPA technologies. But now that's "boring" and "not-modern" so they rebuild using React (or whatever is the popular SPA framework this month) and the result is often a huge degradation in site quality.
Because of the cargo culting, you see all sorts of Fortune 500 companies using this for fairly critical end-user tasks and failing at it. Air Canada did a redesign a while ago and I still can't book a flight on there. You look at the console and it's barfing all sorts of client-side errors and 500's. I would rather have a static, slow, reloading app that is reliable.
There are good uses for SPA's like ticket sites that have virtual queues and office applications. I just don't see the advantage SPA's give me for a lot of critical things I need to do in my life.
I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.
It's true that they are largely more complex than O.G. web technologies, and it worries me that they create a sort of gatekeeping effect on the industry, but I think it's disingenuous to outright claim React & co. are bad from a development perspective. I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
I've done lots of native development on Desktop and Mobile and I can sort of see how you get there if that's your point of reference, but if you work on web apps daily it's clear why the popular technologies are popular, and it's not hype.
You are contradicting yourself by opening with a claim of time savings and ease of use followed by admitting that the solution is largely more complex. More complex work does not save time in aggregate and is not easier to use.
The solution is not more complex to the developer or user, it's more complex to the browser, which hardly ever complains when you make it work harder :-)
Users could complain when someone makes their browsers work harder. Looking around the net, they mostly don't. I don't know. The only time I developed a serious full SPA, I intended to use it myself on a $50 phone, so I actually kept complaining to myself until it started loading in reasonable time and working instantly after that.
But that's a one-time cost. Spring Boot is stupid complicated, too, but once you know it you know it, and getting your next project spun up is a lot faster.
I'd rather maintain a React app because it will be at least somewhat familiar than try to fight my way through someone's home-grown rendering framework that can't even be Googled.
It’s all about where the complexity lives. As long as your client code needs aren’t too complicated then you lose time by using React^. But once you cross a threshold you end up inventing some subset of React^^ and hope that it’s overall less effort to maintain than using React itself.
^ maybe not if your dev team is used to using React but nonetheless.
^^ React could be any of the popular frameworks. They all solve similar problems.
> You are contradicting yourself by opening with a claim of time savings and ease of use followed by admitting that the solution is largely more complex
It's not a contradiction. C# is "largely more complex" than C, that doesn't mean C is inherently more productive than C#.
I’ve written one or two web applications to put food on the table. I’ve found that unless additional complexity comes with an orders of magnitude benefit, it’s usually not worth it.
Seems like the author had a few well articulated and valid concerns, and probably likes the taste of food too.
I always wondered if we take shortcuts because we have to re-write everything every 14 months or if we have to re-write everything every 14 months because of all the shortcuts we take.
For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the solutions don’t work very well means they’re constantly being reinvented, which means if you do the work to keep up with it all you’re rewarded by being regarded as an expert, which is nice.
Lastly, I wouldn’t underestimate how this has built up slowly over time, and therefore how many people just don’t know any better.
Last year I assigned a feature to a junior dev which was quite simple. He spent two days hunting for and testing react libraries to try and build it. When he told me this I said, “Holy crap, that is overkill.” I tried to explain how easy this would be with just plain HTML and JavaScript and he didn’t understand, so we paired for about 90 minutes and the work was done.
At the end of that session this developer said to me, “wow, I didn’t realize you could actually do anything useful with just plain JavaScript in the browser. I thought it was like... assembly or something.”
This is a good, very productive, very fast-learning developer I’m talking about. He literally had never tried to use the DOM api, and didn’t realize it was, you know, useful.
I think there’s a lot of that in front end world today.
What a great anecdote. It aligns with my big worry here: we are raising a cohort of front-end developers who don't know how to use plain HTML and forms!
IMO, it's kinda hard not to end up learning those things even if you are in react all day.
At one point or another things don't work and it's because of simple HTML... and not react.
Maybe that's not the right path to learn it but we've reached a point where if you want a job, plain HTML and JavaScript isn't it.... plenty of folks who had the benefit of developing their skills from HTML + JS all the way up will bemoan this situation.... but if they're hiring people they're not hiring anyone who just knows HTML and JavaScript without any exposure to anything else.
I meant to constrain my comment to the web development sphere. Niche cases mean some scenarios where bandwidth limitations prevent the use of React or something.
Although you can use React for mobile (Native) and desktop (Electron)
> That's what the C devs said about all the people learning Java.
That's not a great argument here. Web development is much more of a continuous spectrum. Programming platforms are designed to hide the the layers beneath to a large degree. I'm not saying there aren't leaky abstractions!
We use the term "full stack" for web developers, but people visualize this with layers, but for me it's a really wide list of items and not a very tall stack.
> but for me it's a really wide list of items and not a very tall stack.
That is fair. You need a bit of many technologies to launch a website. I always interpreted full-stack to mean that you could launch a site on your own, from the database to the buttons and thus do not require a dedicated frontend, backend, or dba.
Coming back to C++ after a decade of Python I realised I had largely forgotten about how memory management works and that felt bad. I felt stupid, because not thinking about that wasn't necessarily a good thing.
And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.
It literally doesn't. You can build a fully normal HTML form in react. The only reason to do any of it yourself is because you need something regular forms can't provide and even then you can still use as little or as much custom parts yourself.
It literally does, unless you have the form POST or GET to an API directly + a redirect from the API.
You have to override the submit functionality which is built-in by the browser. You have to maintain state of what the user inputs, which the browser handles for you. You have to reset inputs, which the browser handles for you (button type=reset). And a ton of people forget to actually validate on the server because they validate on the client.
You do have to override the submit functionality if you don't want to load a new page, sure, but that was always the case with plain Javascript or jQuery or whatever.
You don't have to maintain the state of what the user inputs if you leave the inputs as uncontrolled (https://reactjs.org/docs/uncontrolled-components.html) and access their value via a ref. You could even give them IDs and access their value directly via that if you wanted to, just like you would pre-React. But there are clearly advantages to making the inputs controlled by React, otherwise there'd be no reason to bother doing so (not saying that there aren't probaly a lot of cases where you could keep it simpler but people have been led to believe they need to put their form data in Redux so use some elaborate solution which doesn't scale, or whatever).
Also if you are doing forms in React, check out formik, it's the nicest library I've found so far. Granted it's not as "easy" as a straight HTML form that POSTs to a new page, of course, but modern web experiences often demand richer functionality than "the old way" allows.
Also, per the form libraries question: Formik and React Final Form are the two standard packages I suggest folks look at. React Hook Form seems to be gaining some popularity. Also, I recently ran across https://github.com/wsmd/react-use-form-state and tried it in one of my own projects, and was pretty impressed with it as a lightweight option.
It's sad how convoluted something as simple as form submission has become with "modern" Javascript frameworks. I'm not sure if it is React's fault, or the way most people use it, but it does seem to degrade into a mess of over-complexity. (I've been working on web sites since CGI scripts were a thing.)
Its as simple or as complex as you make it, you can use react to render a perfectly plain html form or you can manage it totally in react. And honestly, once you have everything set up and some previous examples, managing and submitting forms in react is trivial as well.
> And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.
Show me the HTML standard that supports SPA submissions that don't reload the page.
It seems that your problem is about SPAs, not React.
That was a thing even before AJAX came along, eg via forms targetting an iframe.
A long time ago, I wrote a single-page chat application that continuously updated through chunked transfers, with submission via a plain old HTML form that received a 204 response.
I want to hear a war story of someone starting from a React bug report, reducing it to pure JS, fighting through the Chrome build process, isolating the v8 JIT bug, producing a patch, and going on to a successful compiler career.
Heh, I could almost tell that story. We had a bug in a React app that started when a new Chrome release came out. I boiled it down to a small piece of JS that V8 was clearly misinterpreting and which looked like it might be memory corruption in the JITed code. Yep, I got a Chrome build going and was tracing through to see what was going on ...
... but I'd also submitted the JS fragment to Chrome, of course. They ended up flagging it as a high security bug and, not surprisingly, beat me to a fix.
So I never got as far as making a patch, which I guess is why I still don't have a successful compiler career.
I did get a $1k security bounty from Google, though, so that was cool.
I remember when jQuery was the React of its day. Then browsers copied most of its stuff. And now we have moved in to Angular and React.
Frankly, web components can do most of the stuff React does - and even the JSX can be done with eval and concatenating some backticks to strings. As long as you are SURE the strings are coming from templates, they can be assigned at runtime similar to how React assigns at compile time. Not that you should do any of that crap!
Still, React and Angular are insane. React makes you use Babel for JSX and a bunch of esoteric rules that they then make workarounds for, such as “hooks”. And Angular is even more complex, with its digest cycles and mocks and bindings etc. It totally sucks you in.
If you want to use a framework that’s much more lightweight, use Vue. Or use the one that we built ;-) It treats CSS, HTML and JS — and the rest of the Web - exactly as it was meant to be, and doesn’t try to reinvent the well. Well, it does use Handlebars for templating, but can support any other one also.
to me, though, javascript development has always felt like a chaotic tangle of duct tape, until I started working in React. somehow React feels like _writing software_ - building things in small pieces with well-defined inputs and outputs.
And JSX feels like the programming style that I didn’t know I was I’ve been missing since the 1990s - like it’s the logical conclusion for working in HTML, when everything else was either doing sloppy string manipulation or really indirect object-graph walking.
I don’t love babel, but we have a hot-reload script that auto-compiles while I’m working and even swaps in components to my webpage without a reload! It’s actually _less_ friction than vanilla javascript. I cannot imagine going back.
I hope eventually some of these technologies get pushed into the browser, but honestly it doesn’t matter much - javascript is fast, we can afford to use it as a compile target
IMHO the framework makes way more sense than React in that it is a lot simpler to reason about, and it also treats HTML CSS and JS sensibly. React is a bit esoteric... but it has the backing of a large company so everyone uses it. It’s a bit like Wordpress is used by everyone despite its codebase being from 2004. Like it’s OK, I get it, you have to buy into the ecosystem. But I think one day it will be replaced by something cleaner.
This is what I meant by gatekeeping; there is common misconception that you have to go looking for a library to solve a problem. And it makes it seem like there's a higher barrier to entry than there is.
But the reality is that React is plain HTML and Javascript, in a less error-prone and maintainable package.
Everything you can do with vanilla JS you can do in React, but with React you benefit from being forced to separate the state of the DOM from manipulating it.
I don't buy the hipster-centric logic, for me it comes down to productivity. The bugs of yesteryear, tracking down which procedural code path led to modifying a variable, are mostly gone with React. And if you don't use it (or something like it), you end up implementing a subset of it anyway because it's a foundational part of coordinating UI with business logic. /shrug
As a sibling comment notes, and as I noted in a reply to the OP, I agree with you that working with components is a nice approach and very useful. Using React as you describe is perfectly fine. The SPA craze where everything has to be done via React components is where we've jumped the shark IMO.
Doing things with react is mutually exclusive with SPAs. You could even do a purely server-rendered website using react on the server if you wanted to, and all the benefits of functional component design can still be utilized.
You probably meant "orthogonal" (a smarter-sounding way of saying "perpendicular", in the sense of "linearly independent"). A framework made and used primarily for doing SPAs can't be "mutually exclusive" with doing SPAs.
That's fair. I have an app that is rendered server side (Node.js/Express) and the frontend is built with jQuery. Made sense at the time. But I ended up adding two very interactive modules and decided React was best for them and added it in piecemeal, and I was right. But now trying to integrate the new features with the older ones, I wish I started with React for everything. This happens more frequently than I'd like and it's why I'm skeptical of saying SPA's are bad. To me they make my life easier and are very flexible.
Currently the site I'm building is a pretty static site of about 30-50 pages that is just brochureware for a non-profit scientific organization, on one hand I feel sort of embarrassed because it feels like I'm back in 2004 and I have a hard time justifying my salary for something like this, on the other hand I'm really super embarrassed at making the wrong solution because a React SPA with a service worker has been ordained as the way to make this thing.
Gatsby (static-site generator powered by React) was a massive timesaver for me. Sure, you spend a bit longer setting up some basic components, but the trivial ability to share those components between pages more than makes up for it...
Yes of course I want Gatsby, but that is one of the things I'm not being allowed to do. I think I may have gotten overly sensitive these years to not getting my way on architecture.
But setting the wrong state is someting that happens far less and is much more traceable, because the encapsulation of state changes into a single place massively reduces the side effects (and global state) that were the cause of 90% of those bugs in the bad old days.
>If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most
I see this everywhere in programming, not just frontend. I think this silent peer pressure influences us all to some degree. Whether through not wanting to look outdated or foolish, to just being tired of the uphill battle involved constantly fighting against the unstoppable momentum of the cargo cult.
A lot things can be easier if you do things the "wrong way". App development can be faster if you don't use Typescript, liberally use the "any" type, or just avoid. Most of recent javascript tech like React, Redux, Typescript, et all, came to reign in the multi-paradigm language that is Javascript so that larger organizations can actually make maintainable error free code from a language and ecosystem that is very easy to shoot yourself in the foot in from junior developers.
Sure, you just do some javascript and HTML to get your thing working quickly, but that hasn't even been recommended since the days of Jquery (where it was recommended over just doing vanilla JS in order to maintain cross-browser compatibility).
It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable, and that's before even considering things like browser compatibility, accessibility concerns, localization/internationalization, etc. A simple app or product does not mean the internals are necessarily simple.
> A lot things can be easier if you do things the "wrong way".
> It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable...
I don't think you are responding to the point that the previous comment is making. The point is that there is a spectrum from let's say, traditional, to full-on SPA.
When presented with most spectrums of choice like this, it's expected that most people will weigh in requirements first and choose the solution based on the requirements (if they are an engineer, or pretending to be one.) In terms of expertise, they might love to write SPAs, but they realize that the other options on the spectrum exist for reasons other than being in, or out of fashion.
The problem is that some folks overemphasize what's in fashion. There are many reasons for this, and it's something that happens across other disciplines, not just programming. That said, we have a unique situation with programming in that someone can be quite an expert while only understanding one end of the spectrum. It's very easy for these folks to hold sway.
When it comes to the "wrong way", I agree with you, but I'd go further. If the requirements demand a SPA then you need to go all in and use the best modern tools. There are a lot of things created as we moved out of the full page render ages which don't result in good SPA development (for users or devs.) Embrace Typescript, React, etc because these solutions have evolved from that in-between stage.
Using "browser compatibility, accessibility concerns, localization/internationalization" isn't a great argument here. These are often orthogonal requirement. It's easy to argue that full page rendering, or static HTML meets all these more easily. These apps can't compete if you need particular interactive experiences.
I did address that it depends on your requirements. But my point is that it is highly unlikely that any requirements would be better served by vanilla JS + html than say writing your code with ES Next or React, unless you truly have some sort of limited use one-off thing.
Tools like webpack, babel, and react are also orthogonal to whether or not you're doing an SPA. These new tools aren't just to make your app a SPA, but are meant to decouple the maintainability of your code from the implementation details. React itself isn't even a framework but a paradigm which just happens to have a specific implementation that requires their runtime. The most recent shift is to turn your components into pure functions, and this is less about the framework and more about decoupling your app rendering logic from the react implementation. There's no objective argument that writing vanilla JS is better than writing modern ES next code. These language improvements are done to improve the failings of the javascript language after all.
You can totally use React to purely statically render your website. This is what most SSR implementations do, and the only reason JS is still activated is most modern apps require interactivity.
If you start doing vanilla JS and HTML you're doing a direct implementation. That's almost always the wrong way just because of browser differences between operating systems, mobile vs desktop, and all the other features that aren't really bells and whistles but more and more necessary as technology serves a bigger role. Perhaps in 1990 it's fine that a website can be made for a specific user for a specific purpose.
> Tools like webpack, babel [...] but are meant to decouple the maintainability of your code from the implementation details.
Let's be real, the only reason we really need WebPack and Babel at this point is for IE11 compatibility and JSX.
Currently >90% of the browsers (that depends on the country) are evergreen, and have support for most ES6 features, including ES6 modules. As soon as we're able to drop IE11 (when will Google remove IE11 support from Youtube?), the only reason to keep those tools will be JSX, which is frankly a minor convenience compared to the rest of React, and there are multiple alternatives to it that are not that terrible. [2]
Apart from that, WebPack and Babel are extremely hit-and-miss and terrible slow for anything but small-ish projects.
If you're doing SaaS or enterprise, chances are most of your customer-base is already 99.9% on Chrome or, in the worst case, in enterprise Windows-centric companies, Edge and that 0.01% is just waiting for something to tip them off.
I really can't wait to get rid of those two shitshows. Or maybe replace them with something actually useful, like Typescript compiled directly to modules.
Babel is there so you can write your code with the latest Javascript features and separate your written code from what is actually deployed. JSX and IE11 are a subset of problems that this type of abstraction can solve.
This is miles better than the previous alternative: manually importing shims or adding in css prefixes. Babel and webpack also enable macros and static code analysis tools so you can write code in "inefficient" ways that's more readable, and automatically generate more performant code automatically.
Browsers are still split, even if considering only desktop users. If you add in mobile users then all those iOS people are using Safari, not Chrome.
And because of this fragmentation you can't expect the latest ES features to be usable on day one. So you'll always want Babel so you can write the code the way you want, and have platform targeting be a separate concern.
It sounds like you believe that we should be writing very platform specific code for the web, which is a bad practice in general. Nobody should write platform specific code. Leave that to the compiler.
Nope. You're the one advocating targeting a specific platform, and it's called Babel.
What I'm advocating is targeting evergreen browsers whenever possible: Chrome, Safari, Firefox, Edge, and their forks. They already have most ES6 features. Even Safari has great ES6 support. iOS is known for being very up to date. Fragmentation in Javascript is a thing of the past, as long as you only use features available for +90% of the people on caniuse.com.
If you're targeting evergreen browsers you can already write the latest Javascript, and would only need Babel for something like JSX. All those browsers have async/await, ES6 modules (aka import), arrow functions, and destructuring.
To separate your written code from what is actually deployed is much more of a con than a pro. I'd rather not need a compilation step if possible. My time is valuable. Babel and Webpack are slow as a dog for non-toy projects.
Manually importing shims are a thing of the past when you're targeting evergreen browsers. You can use something like Polyfill.io for edge cases, and it will cover the small number of
CSS prefixes have nothing to do with Babel or Webpack, they're normally handled by tools like PostCSS. Nothing to do with Javascript. Static Analysis is normally handled by tools like ESLint that can use Babel but can be completely decoupled from the compilation step. Or Typescript, which actually brings a lot to the table compared to Babel.
Again, this might be hard: maybe you need to handle customers with IE11. But to not need Babel is something we should aim for.
I honestly can't wait for Babel to be 100% unnecessary and to die. It is valuable in a world where Internet Explorer exists, but there is zero advantage in using it when it's unnecessary.
I have been working with various SPA frameworks for about 5 years now, from the bad old days of AngularJS to mostly React nowadays.
Your comment about 1990 seriously rubs me the wrong way because it seems to imply React et al. actually does something to address the points you make. It does not, at all. You still need to test your code on every viewport you support. And now you have to deal with an insane build process that rivals some C++ projects while doing it.
And there is absolutely an objective argument that staying close to the web platform is preferable than 200 layers of leaky abstraction and a 10MB uncompressed bundle of transpiled JS. The language itself is pretty okay in 2020, certainly not worse than anything else from the TIOBE top 10. I would definitely say writing a bunch of plain JavaScript is all that’s needed for most applications out there. If you can’t manage that without a frontend framework, the problem is certainly not with the platform or language.
Yes you still have to test your app on different platforms and browsers, but the point of the build process is that they make them work on those various platforms, whereas before you would have to manually fix those failed tests and hack in fixes for obscure conditions. That's what frameworks and libraries are for. They've abstracted away things so you can focus on higher level things. Tests are always going to be required, even if your framework and libraries are perfect.
We don't need to stay close to the platform because abstractions allow for more advanced applications. That's why most web apps don't use C, and should never use C, because 99% of the coding work is higher level tasks that don't need the bare-metal performance optimizations.
> than say writing your code with ES Next or React
Say again? One is a framework, the other is an updated version of the language that can be transpiled to ES3 for (non-mathematically) provably identical results.
React isn't a framework. It's a library for writing functional components which can, at the moment, target native mobile components and HTML components so that you are not writing the components manually in a platform specific way.
WASM is entirely different from Svelte/React. WASM is a compilation target for native-code languages, and can't interact with the DOM except through JS shims.
> Also the fact that the solutions don’t work very well means they’re constantly being reinvented, which means if you do the work to keep up with it all you’re rewarded by being regarded as an expert, which is nice.
This is a huge assumption. For example, I don't think any web dev enjoys wrangling with CSS positioning or workarounds because they want to be "rewarded by keeping up".
> Last year I assigned a feature to a junior dev which was quite simple. He spent two days hunting for and testing React libraries to try and build it. When he told me this I said, “Holy crap, that is overkill.” I tried to explain how easy this would be with just plain HTML and JavaScript and he didn’t understand, so we paired for about 90 minutes and the work was done.
I don't know what your feature is. But any decent web dev today has to think of multiple angles that are not present in non-frontend development
- Responsiveness
- Browser support
- Accessibility
- Internationalization
That is in addition to testing, error logging, analytics, etc. We haven't even gone to the business logic yet.
Many people underestimate how much work a good web app entails
1) CSS works great, and while it continues to incrementally improve, has been fairly stable since its introduction. What I meant about "solutions" that don't work well are things like React state which has gone from "not a thing" to "redux" to "redux is an antipattern" to "redux is moot because now graphql" which oh BTW means you now need a whole new API? Ok. That framework churn is because those problems are actually difficult, and to date there's no "one true way" that is pretty straightforward and covers 90% of cases pretty well. By contrast, things like "how to set up a webserver that handles HTTP requests" are easier and already well-solved in every serious language, and thus not so subject to the same degree of churn.
2) All those concerns were present in the project I worked with said developer on, and were easy to handle with the basic tools of the browser.
The senior engineer could have just as easily wrote worse code.
Just some weird obscure Javascript floating around editing the DOM directly causing untraceable errors in the future.
React helps with lots of things;
- Testability
- Readability
- Less side effects
- Documentation
- Rendering
- Error Protection
I could rattle on forever, might be time to write a blog post, gets a bit tiring reading the HN users who think we've just made the frontend complex for fun.
Frontend development is HARD, factors include;
- Plethora of device models/sizes
- Latency / Async / Fetching (data)
- Rendering speeds based off how you coded it
- State Management / Cache Freshness / LocalStorage
- Server Side Rendering
- Code Bundling (js and css)
- Design / Transitions / UX / UI
etc
Now why is all this important? Because to be a competitive app, it simply has to be sexy and slick.
If I could do that with one style tag and one script tag, I would.
> If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most.
It sounds like you're reinforcing this divide by classifying people who have a different opinion to you as "hipsters."
They label your technology choice as outdated, and you label them as hipsters. You become the thing you fight.
The problem with using some shiny new library/software/app/technology is, that it might dissapear in a year. The developers will move on to new companies, and work with some new shiny tech, and all your codebase will be useless due to a unmaintained library and no new people (developers) who know how to use it.
I wanted to make an example that it was like starting work at a company, and seeing that they're still using phpBB (but with a 1 year old library)... but it seems phpBB is still being developed...
> I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting.
Yes. And its important to remember that React is heavily marketed to developers by Facebook, just as MS does with Typescript, and Google does with Angular. The point of this marketing is to create a feeling that these technologies are "safe" and "standard". Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising.
That said, there are a few major functionality gaps in native JS that leave the door open for front end libs. The biggest one is some kind of sane support for templating, and the second big one is that async is too complicated (people who actually understand callbacks and Promises often dont realize how many devs dont understand them). Facebook, via React, provides solutions to these problems, and leverages them to get users to buy into the React ecosystem.
If somebody could show how to make a component in JS that could be included in a page as an HTML tag, and could talk to other components on the page then the need for React would just evaporate.
> Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising.
Of course. Most devshops don't have the manpower that FB/Google/MS have. You don't really have months to tinker around and create some new framework and then another 2x months to fix bugs and add new features to cover some edge cases. So you pick whatever is backed by a lot of manpower as it has the highest chance of being usable even 3 years from now.
Having done some old Skool desktop dev recently I can't shake the feeling that modern web development is mostly just trying to reinvent wheels that have mostly been sorted for 20+ years.
I guess it's understandable though, the web was never really designed with its current use-case in mind.
People do so love forcing square pegs into round holes though.
>“wow, I didn’t realize you could actually do anything useful with just plain JavaScript in the browser. I thought it was like... assembly or something.”
Wow. These two sentences completely capture modern day Web Development, Javascript as assembly.
>I think there’s a lot of that in front end world today.
In modern Web development, ( and in possibly all area of software development ), instead of making things simpler ( not easier ), it seems we have been building premature abstraction after abstraction.
About your junior dev it might also be the way he was taught React.
I'm also a junior and the way I was introduced to React was by teaching me enough JS that I could theoretically write React (with a bunch of research).
One of the things I've noticed among other junior engineers (including myself) is tutorial driven development. Through a mixture of inexperience, laziness, and self doubt it can be easier to find someone else who's implemented something and just use theirs. Rather then thinking about a complex problem and naively coding up a solution finding someone else's hopefully battle tested code.
An example of this is how I used to make JS based games. I essentially used an array to toggle classes on a grid of divs divs in the style of an LCD screen. I hadn't heard of html's canvas element. My solution worked but I don't think anyone would think it's a particularly good one. If I had found someone's snake game and saw they used canvas I could have saved myself some headache.
At work, I've been forced to use angular. It's just awfully complicated, breaks subtly, changes (not improves) constantly and has sucked in hundreds of developer hours that could have been better utilized.
I was appalled at the state of things in front end development till I realized my current project uses kubernetes (implies docker, helm), spring for implementing REST endpoints and ansible for deployments on the back end.
I disagree. Do you remember the days when J2EE was the hot stuff? Popularity comes and goes and is not necessarily correlated with whether something is a good idea or not.
Over the last 15-20 years or so as a web development shop we've gone through Prototype, Jquery, Backbone, Angular, Vue and now React for JS frameworks. We've mostly settled on React lately. Our experience is however that it is wildly overused where it is not needed and adds significant time to development. Features that should take a week to build now suddenly have complex client side state management requirements (to name one issue) and take several weeks. We've seen this in several projects while working alongside experienced developers.
We do use React extensively and we find the sweet spot is in smaller components on a page, or highly interactive sections, things without lots of shared state, but it often seems like web developers have one hammer and it is not the right one.
> Features that should take a week to build now suddenly have complex client side state management requirements (to name one issue)
This sounds like bad system design rather than a problem of React.
In general, I find React hate massively overblown. The problem seems mostly to be that everyone is using it, and "everyone" in the case of frontend devs is all over the place in terms of how they got there, what they know to do, and what they know not to do. If you're not careful, all of the JS ecosystem can give you a lot of rope to hang yourself with. The relative accessibility of webdev is a blessing and a curse.
This sounds a lot like the days in web dev before Ruby on Rails came along.
When they (and django) took the web dev world by storm they were prescriptive and told developers how to do something, not just giving them a bunch of tools where you had to build your own app lifecycle, usually massively over-engineered. A whole load of mental overhead disappeared.
Just before Rails, etc. everyone was going on about Factories and the Gang of Four and people were building crazy startup patterns on their webapps using Singletons.
I really like Svelte because of what you are describing. It feels almost like writing normal JS/CSS/Html but you get access to some QoL features that make writing JS easier
I put food on the table, and I do more work in Django than I do in SPA's. In fact, one of the complaints I read about from management is that Django devs cost more than JS devs (don't know if that's true, just saying it's a management concern).
But I think the "React everywhere" error, is more or less the same as the "one language for everything" error, the "everything should be Windows" error, and many other cases of wanting to use only one technology and have it work for all cases.
I've been working in the tech industry for 20 years and from my experience rarely do "cheap developers" ever actually seem to work out costing less in anything other than the very short term.
The cheaper the developer, the shorter the period where they cost less.
> they're easier to work with and they save us time.
I have never seen evidence of this.
Its a lie developers frequently mention because it sounds so thrilling to say. Approximately how much time does it save you in estimated hours? Its like asking for a helicopter to take me to work, because supposedly its faster. I'm simply assuming its faster without looking at any numbers or finances.
I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more.
It's certainly faster to use jQuery to change a CSS attribute than it is to setup a React project but what's not considered in that calculation is maintaining the state of that attribute or making changes to the logic in the future. Especially on code you didn't write originally.
If all you have to do is validate a form, sure, use jQuery if that's your cup of tea. But I would still rather use something like React because I know I'm less likely to write buggy code or introduce a regression in the future. To each their own though.
> I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more.
Its a lie so long as the number sounds completely invented. I suspect the number comes from somewhere, maybe a vague memory, or a grossly unqualified estimation, but it isn't based on anything. It is something superficial that primarily serves as self reassurance.
When you have never had to bill people for your time, or you have never been to a board meeting, or never briefed senior executives this kind of fantasy is perfectly fine. The moment there is money on the table you are expected to do more than invent fictional numbers, or you will be replaced by somebody who can.
I have worked as a consultant for 5 years where I billed people for my time, and paid at least $200k to other contractors in that period for help on projects; it's not made up and it is based on my experience tracking my own time and productivity, and that of my subcontractors.
I do think it's more abstract and harder to justify properly when someone is a well paid salaried employee for a FAANG. But that's not me.
The same way anyone would come up with a time estimate if asked how long it would take to mow the lawn with a pair of scissors or lawnmower -- experience and extrapolation.
Fair enough on the experience and extrapolation. But I would argue your analogy is a bit off. It's undeniable that a lawnmower is faster than scissors. I don't think that's the case between React and no React.
A closer analogy would be a comparison between different models of lawnmower or between a lawnmower and a different kind of mechanical grass cutting device. In which case, it seems you would need to log time to see if you've saved time using one over the other.
I think the problem/frustration is simply this: there are a lot of web sites out there that are, well, web sites, not web applications. Looking back at the linked article, it goes out of its way to talk about many ways that React is "pretty great" and "for a particular scope of use cases it's the best tool you can find," but then goes on:
> There are a lot of problems for which I can't see any concrete benefit to using React. Those are things like blogs, shopping-cart websites, mostly-CRUD-and-forms websites.
And the thing is, this still comprises an awful lot of the web. If I can produce a web site with Lektor or Hugo or some other sophisticated static site builder, it's hard to see how React is going to bring anything to the table that either makes that web site easier for me to maintain or provides a better experience for that web site's users. If you introduce some dynamic elements to the web site -- well, just what are those elements? Ad banners? A simple image carousel?
And I think that's really the argument being made here -- use the right tool for the right job. If all you have is React, everything look likes like an SPA, but that doesn't mean that it is.
I suspect a little of both. Developers do like to play with cool new technologies, and product managers do like to see how spiffy they can make their products.
Having said that, though, I do not think it's a universal truth that all web sites must expand to fill all available functionality, which seems to be implicit in a lot of arguments here and in the highest-rated rebuttal to me.
For all the talk of "resume driven development" I think most developers - unless they are playing around with side projects and non-essential experimental stuff - prefer to do the simplest thing that will get the job done and keep the site maintainable, and the reason they resort to more complex and advanced frontend solutions is due to onerous requirements from stakeholders for more and more intricate and complex UI. It's another question entirely whether this more intricate and complex UI actually delivers business value or provides a better experience for the end users, but that question is above the developers' pay grade.
Your argument hinges on the assumption that the products have a final conclusion. I can start building a product in hugo, say - I’m just displaying information in charts and generating predefined reports. Time passes more users are added and now I need to identify each users reports. Now I need a server and at this stage I can get away with SSR. More time, more organizations, more complexity. All of this can still be handled by SSR. The real kicker happens when people start demanding the ability to generate their own reports by supplying their parameters. They want the ability to write their own queries. They want WYSIWYG building blocks. They want to define their own templates.
Very quickly we are in a territory well done with react than with Hugo.
Most products, especially if it’s a company, are like this. Products are constantly evolving. Whether products should be constantly evolving is a different discussion and tools are only a small part of that discussion.
I would say rather that my argument hinges on the assumption that the majority of web sites in the world are not the primary products of the companies that produce them. I would argue, in fact, that you're looking at web sites from a very particular lens. An absolutely valid lens, to be sure, but a particular one. nonetheless.
If you're an SaaS (or PaaS or whatever-aaS) company, then your web site is literally the core of your being. You're building an application that happens to run in the browser, so you want to build it like an applications! But a lot of companies aren't doing that. Hacker News, the web site we're on right now, doesn't need to be an SPA (and isn't). Does any CMS need to be designed like one? I'd never give a blanket "no," but I'd sure never give a blanket "yes." How about a company blog? A simple storefront? A customer-facing restaurant site?
Also, don't get hung up on my particular example of a static web site -- I wasn't arguing that all sites can be done with Hugo. :) But you could absolutely design a modern, maintainable CMS that lets internal customers generate their own reports, write their own queries, and define their own templates using Rails or Django or Laravel as the back end -- and that seemed to me to be what the original article was really trying to get at. We've gotten so hooked on "JavaScript is everything everywhere" that we may not always be considering whether a given project really fits that paradigm. "This project doesn't fit it now, but it might in the future" is nearly always a technically correct response -- but "what you're building couldn't possibly scale up to unicorn level" is nearly always a technically correct response, too.
> sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
I've been developing single page applications, mostly, for six years; and I generally don't enable JavaScript on a website unless it is otherwise broken and I actually care to use it. I'm developing a website right now that has some persistent elements (video call, interactive charts) that don't play well with server side rendering. For the elements that are fine without it I prefer to render them on the server when there are enough of them, but ultimately there are limits.
It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.
As a user and developer myself, that's the sort of selfish attitude that really really angers your users.
I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
I've worked on "complex"[1] websites in PHP, all static/server-side rendered; zero need of JS, near instant load times, ultra low bandwidth and server CPU utilisation, and don't even need to think about "browser support" because it'll be usable with anything from the past two decades.
[1] complexity in terms of features and usefulness, not in terms of how much code and resources it needs. Unfortunately a lot of developers seem to think complexity as in the latter is a good thing.
This (and related phenomenon with subscriptions) is arguably a big drive for the software becoming increasingly infantilized; shiny toys instead of useful tools.
And they do, even if it's not a conscious decision. Most large scale experiments see bounce rate increase and revenue decrease with page load time. More load time because "it's easier to develop this way and it saves developer time, which is expensive" means more bounces and less sales.
Of course, that only matters at scale. If your site never takes off, optimizing for user experience (instead of developer experience) wouldn't have paid off. On the other hand, maybe putting your users second lowers the chance of it being well received.
As others said, user != customer. A big chunk of software (perhaps the majority) is bought by someone other than the end-user. Think workplace, or all the OEM garbage that ships with your phone.
On top of that, on the mass market, customers don't have a meanigful choice. They can't signal desires in the entirety of concept space; they choose out of what's available on the market. Which means the choice really lies with the vendors.
XHR was invented because without it, Microsoft couldn't make a web-based email client that behaved the way users expected an email client to behave. 20 years ago. I'm not sure you can reasonably claim this stuff is not also strongly driven by the expectations of users and and the desire to meet those expectations.
I'd like to know which users desired a web-based e-mail client 20 years ago. It is my impression that this kind of software is very much push, not pull - i.e. the idea comes from the vendor, not from customers expressing a demand. Which is not a bad thing in itself (a big part of progress is speculative creation); I just don't like the unspoken assumption that companies do things because customers want them to, it's not always true (almost never in B2C).
Many of us only used it because it was free/available for everyone and we were students or stuck in another situation were it was the only option. If there was both a webmail interface and imap we chose imap.
Some of us still to this day prefer imap/jmap/exchange if the server support it in a meaningful way.
those crazy users, not wanting to install, configure and update software, download their emails and make sure their backups work, and just get on with actually reading their emails on whatever computer they wanted
Those crazy users who then cry, "what do you mean I've lost 10 years of e-mails forever, becuase my daugher commented with an emoji on a YouTube livestream, and Google decided to go nuclear everything associated with that account?".
Cloud services aren't more reliable than owning your data. They're just unreliable in a different way. You need backups anyway.
I'm of course referring to the Markiplier drama of last year, where a streamer asked people to vote on his stream by typing in red/green emojis. This resulted in hundreds of people losing their Google accounts due to an oversensitive spam filter. The matter fortunately got sorted out (somewhat, not all accounts were unbanned), but essentially only because it involved a fairly well-known youtuber.
And random automated bans (which happen on all big social networks) are only one fairly common failure mode of cloud services. Smaller services shut down or get acquired, taking your data with them, or they just shutter the products you depended on (and even if you can export data, there often isn't anything you can import that data back into). Governments may randomly make whole populations lose access to service (c.f. Adobe's Creative Suite and trade sanctions on Venezuela, earlier this year). And, of course, no Internet access = no access to service = no access to data.
In general, owning your data makes you vulnerable to physical world problems - floods, fires, etc. Using cloud services makes you vulnerable to relationships between you and third parties, as well as between these third parties themselves.
Server side email has the failure mode of the company going broke or banning you. Client side email has failure modes like destruction of device (house fire, flood, other accidents) or even just obsoleting of OS/app. Neither is inherently superior to the other.
In the particular case of the emoji ban, the problem is that the FTC should never have allowed one company to control search AND email AND school document sharing AND maps/reviews AND video AND mobile phones, etc. If you don't use Google for your email, there's no danger of Google banning you from it. :-) More seriously, Google (and Amazon and Facebook and Microsoft+Github) needs to be broken up to protect consumers from one company having a chokehold on their digital lives.
I don't agree. A classic PHP-as-it-was-used-15-years-ago site either loads or fails for every user request. That isn't good enough any more. An SPA either loads or fails for the first request, but then they do a lot of things that can mitigate a patchy internet connection - prefetching content, offline mode, bundling things to reduce the number requests, etc. A server-side rendered app doesn't take advantage of those optimisations, although things like rel="prefetch" are starting to get used more which helps a lot.
Like the article suggests, there's definitely some middle ground where enough of the site is loaded on the first request for it to work, and then more things can happen in the background to make subsequent interactions faster and more reliable. That isn't a pure SPA and it isn't a pure SSR site either.
Very few SPAs give proper user feedback. There could be any number of silent errors in the background.
It's even evident for relatively basic things such as infinite scroll. Users on sketchy connections won't even see all the items in a web store if their mobile connection is sketchy enough, and they will never even know it.
There are some real costs here. Had anyone seriously A/B tested these things they wouldn't be so widespread.
Very few SPAs give proper user feedback. There could be any number of silent errors in the background.
Badly built apps that ignore errors and don't work well for users are certainly not limited to SPAs, and blaming SPA tech for that seems a bit unreasonable.
For "classical" websites, it was not possible to screw it up. The feeback was always there - clear, unmistakable, universal across sites. Boom, "No Internet", site's gone. Press "back" to get the previous state and click again/resubmit later. And it was nice that you could actually do that - use the "back" button to revert to the last correct state even without an Internet connection. Can't do that with almost any SPA these days.
I suppose it just boils down to the fact that with more freedom comes more freedom to fuck things up. But when you see an industry systematically fucking things up, and being driven by economic incentives that encourage fucking things up, one has to wonder whether some of those freedoms should be taken away.
The feeback was always there - clear, unmistakable, universal across sites.
It wasn't clear for lots of users. There were common stories of people getting a connection error and refreshing a page only to find their order on an ecommerce site had been taken twice, or that a comment they'd made had been submitted a second time, or that a request to delete something had actually worked but the second request threw up an error because it couldn't be deleted again so it looked like it had failed. These aren't so much of an issue today because browsers warn about form resubmission, but let's not forget that server-side rendered websites in the past were absolutely riddled with UX problems and bugs.
That's not a defence of SPAs, far too many still get the basics wrong, but if you believe it was better when devs made "classical" sites I think there's some decidedly rose-tinted nostalgia going on.
Perhaps the SPA pattern, for all the justifications from developers (and yes, of course there are genuine cases where it's a good fit) is really an outcome of Conway's Law[1] in action. In a large enough organization, you corral your dev teams into isolated, specialist "backend" and "frontend" groups which end up communicating largely through decoupled APIs. As with microservices, it's not really about whether this is the most efficient and user-friendly approach to delivering useful apps to the end users, but how much this architecture mirrors your company's org chart.
I’ve never used React, but I spent years fighting with Angular, and it seemed like all downside with no upside - I kept expecting the upside to become apparent eventually, but it never materialized... it just made site development take longer, crash more mysteriously, and run slower. Is React really “better” than Angular? That is, does it actually do anything?
Angular's model is based on "two-way data binding", which was also the paradigm used by Backbone and other popular JS frameworks of a ~decade ago. This means that any user interaction with your app directly causes some JavaScript value to change, potentially triggering side-effects. But you can also cause the same value to change in your business logic code, in response to some other event or change. Components maintain a lot of data internally, so your job as a developer is largely about making sure that these components stay in sync with each other, and with whatever non-component-oriented data you have.
This gets messy very quickly. Where is your data? What things can cause your data to change? What happens if you want to change a data schema, or introduce new fields, new components? Angular tries to solve this problem with a fairly complex architecture[1] which promises that all of this can be OK if you follow the rules.
The problem is that this architecture is so complex that most people can't follow it well: there are modules, components, views, directives, services, dependency injection containers, service metadata, bindings, a router, and events. That's ten concepts, and you can't build very much in Angular without knowing what those concepts are and how they relate to each other (and if you can build it without knowing these things, then you didn't need Angular).
React is much simpler: there is state, and there are views. State can be global or component-local, and I would suggest ignoring component-local state unless you can't avoid it. Views render whatever state is passed to them. State can be updated by events. This is the same basic loop that is recognisable in desktop apps, games, in fact most interactive software. There's no "two-way binding" because views render based on state, but can't modify it directly. This is a lot easier to understand and to debug.
React might be less "batteries included" than Angular, but Angular requires such an enormous battery pack because it is trying to solve problems in an insanely complicated way.
> I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
Anyone who cares about privacy allows minimal JS etc. Especially if they're using Tor. And given Tor's high latency and low bandwidth, sites that require lots of client-server dialogue, and/or push lots of data, are a pain to use.
And yes, I've never built complex websites. Just static HTML. Because mostly they've been Tor onion sites, and that's what works best for them.
What about if you used a mature back end framework such a Rails, Django or Laravel for 95% of your app. And then vue or react for the 5% that rally needs it? Would this be more or less productive?
The author wasn't claiming that react and co are bad for development. Rather that they are great for particular use cases and inferior to other options for other use cases.
I think that's undeniably true.
You hinted at something that to me is a key point: A lot of web apps are built by teams at big organizations.
In that environment trends are compelling because they keep everyone on the same page. It's easier to onboard people, it's easier to hand things off, easier to maintain going forward.
That makes a strong case for using the latest frameworks even when they aren't the best solution for a particular problem but it doesn't make it right from an efficiency or user experience perspective. There are a lot of reasons why arbitrary complexity is expensive. One example: what happens when your page load times start to rise above the threshold where it starts hurting organic traffic? You probably don't scrap everything and start over, instead you hack solutions on top of what you already have. Now you've lost money in both free traffic, one time development costs and increased maintenance costs going forward.
Again it's not that react is bad, and either way people aren't going to stop using it for things it's not ideal for until another trend replaces or absorbs it. But I think there's value in seeing things for what they are, and having conversations about it.
I have been developing all sorts of native and Web applications for a couple of decades now, and SPAs is something I avoid as much as possible.
And yes, I also implemented interactive desktop like applications as Web applications.
Server side rendering frameworks, with support for components and just enough JavaScript go a very long way, and best of all, they are faster than SPAs in every kind of device that customers might have.
Server-side rendering + Turbolinks [1] + jQuery-or-equivalent gives you an SPA experience anyway, without the client-side bloat. With judicious use of markup, it can be massively more responsive.
for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time
The premise of the article is that they are not easier to work with and do not save time in most situations. I agree.
Most websites are fundamentally documents, even those that think of themselves as apps. You could even build gmail quite easily as a document based app with some limited use of fetch() or WebSockets to get the data you need, though it's one of the few applications where a less document based approach might help.
React and other js frameworks are a huge amount of overhead for very little gain if you see the web this way. Your about page is not improved by using react.
I gave an example of a prominent web app I don't think needs a js framework - most web apps don't IMO as the web correctly centres the experience on documents. Games would be the obvious exception where an immersive app experience is warranted and there are no documents as such, almost every other app works with data organised into stores of documents (i.e. in gmail every email is a document and deserves its own URL IMO).
> fortunately people don't use React for making About pages.
No, About pages are out of fashion and people don't do them in high numbers anymore. But they do use react to display news articles, web shops, and all kind of text.
This doesn't match my experience at all. I've seen many, many places where a bleeding-edge React stack was deployed to serve what was 100% static content.
> client-side technologies like React have a pretty clear advantage... they're easier to work with and they save us time.
> it worries me that they create a sort of gatekeeping effect on the industry
Aren't these two quotes contradicting one another? If frontend frameworks make frontend developers' job easier, then how can they be regarded as contributing to gatekeeping? If it had not been for them, frontend development job would have been harder and would have required more expertise.
For me the real subject would be "the death of templates in favor of decorator based objects", which could have been predicted by the GoF that recommended the decorator pattern for GUIs, and makes great sense for the tag-based language that HTML is.
Template languages often impose language limitations to make easier for HTML/CSS coders to work with, without breaking the backend code, isolating their codebase from the backend codebase.
These limitations make them less composable and reusable than functions or objects, and obviously show more drawbacks than advantages for one-man-development, and reuse across projects.
My wild guess is that if we replace templates by components on the server side, we will see less React & friends, for me they mainly demonstrate the clear win of component based patterns against template spagetti.
Seems we are going full circle: the Python ecosystem had component-based template languages such as ZPT (Zope Page Templates) and Genshi. The former I think is still used with the Pyramid framework, but mostly these approaches have been replaced by Django/Jinja2 text-based templates. So in Jinja2 or Django you would have something like:
If you squint hard enough this doesn't look a million miles different from React or Vue.
This approach largely fell out of favor, but I don't know whether that was just due to Django's popularity vs other Python frameworks or Django template language just being more flexible and approachable, especially for front-end developers (and you could use it for any kind of text based content, such as emails).
It was that the template engine got a Turing complete text declaration language, while the tag based one had to rely on hacks that didn't scale very well. Also, as you said, because the template engine were useful for any kind of data, while the tag one carries a lot of opinions about the resulting text.
More flexible and conceptually simpler tend to win over time, as people try to learn less things.
You would be shocked to learn how many roads and buildings are actually built like this. Except that in the case of roads and houses, people die sometimes as a consequence.
I wonder, when did this shift happen wrt the Web: we only care about how it is easy for the developers, not for the users. Despite all the talk about UX a lot of the momentum is still in the wrong direction.
I've been writing working with the web close to 25 years now. It is amusing to see it come the full circle. How hard it is to understand, that you don't need react for some blog, or anything which is not even remotely an app?
> when did this shift happen wrt the Web: we only care about how it is easy for the developers, not for the users
Are you talking about the same web that ditched XHTML because you had to validate your site before publishing? And had those "works better on Mozaic in a 420x340 resolution" warnings?
> for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.
Our salaries are expensive because, presumably, we're being paid to make something that serves the users. So anything that benefits us at the expense of the people we're serving should be rejected. How self-centered can we be?
> I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
I have a 20 year history of building websites, and a recent three year stint of building front-end applications professionally using mostly React, which I'm now proficient in. I also normally use a strict whitelisting policy for Javascript using NoScript. If it's not a tool that depends on it that I really want to use, or if I find no obvious reason for it to be using Javascript, websites don't get added to the whitelist.
Javascript, as far as I'm concerned, is a wide open vector for an ongoing large scale attack on my privacy. Not only that, but I also have to pay for it in battery life and memory. The occasional blog built in React without a static fallback will usually go unread on my end, and no one is losing sleep over it.
I also think that you are fundamentally missing the point of the article if you your experiences building native applications vs building web applications is supposed to offer a counterargument. It's a false dichotomy in this case; the blog was never a native desktop app. The marketing site was never a native desktop app. They're collections of documents and I have no idea how anyone could come to believe that arranging that using a framework designed to facilitate reactive web applications is easier than just delivering the documents using technology designed to do so.
I spent several months with JS off by default. I relented after one too many broken sites. Since then, I've suffered from sites with HTML popups, autoplaying videos, and not one, but two "subscribe to my newsletter" prompts which trigger when you move your mouse to the address bar.
Disabling JS by default severely reduces the ability of websites to pull user-hostile tricks (though it breaks web apps). No website (presenting static information to be consumed) should ever break with JS off, and any site that does is defective. I won't extend this to web apps (interactive dynamic functionality like Google Docs) though.
If you mean to equate wearing tinfoil hats with employing a blacklist-by-default Javascript policy I'd gladly hear your reasoning. I'm sure it would help others not confuse your point with vapid shitposting, as well.
Yes, that's what I'm equating it with. I think it's a fair analogy. Disabling Javascript isn't enough to 'protect your privacy', and even if it was, I haven't heard of any tangible impact that would have on anyone's life.
Okay, taking Facebook as an example. Let's say you visit a random website and get tracked by a Facebook Pixel (which happens to be an image, not JavaScript), what happens then? You see behaviourally-targeted advertisements on Facebook and partner destinations, instead of generically-targeted advertisements. I don't agree with the assertion that this has a materially negative impact on anyone's privacy or life as a whole.
I understand that this is an unpopular opinion, but it's what I believe.
> I don't agree with the assertion that this has a materially negative impact on anyone's privacy or life as a whole.
I haven't asserted that it has any negative impact. To say that it has no tangible impact (as you have) is decidedly wrong. Either the manipulation is working at a grand scale (which is scary in its own right), or people that invest that much money in targeted ads are idiots buying snake oil. Regardless, Facebook and Google now command huge social and political influence, and they're entirely in the business of using my private information to sell ads.
I guess wanting to be the constant target of increasingly direct attempts at manipulation is a matter of personal preference, but the fact that it has an obvious material impact on the world is not.
> I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
So, this is the kind of thing I make for my employer. But guess what? I can still do things the way I did them back when I learned Rails over a decade ago: HTML templates and a very small amount of JS to tell the server to re-render them when the user needs it.
What many of us really need is not fully dynamic SPA-type things, we just need some dynamic forms and some page elements that dynamically respond to user input. This is all stuff that you can also do without JS, if you design your site to handle that use case! Rails still makes it easy to make this kind of site with plain JS (or a lightweight framework like Stimulus, or jquery if you really want).
But all that's to say I fully realize why and how JS is useful... and that's actually why I disable most JS by default in uBlock Origin.
The problem isn't the existence of JS, it's the fact that massive tools like React become the hammer, and everything starts to look like a nail. There's no reason for the sites I am usually interested in visiting, which are either content hosting sites (no JS needed at all) or sites like my own (that could be enhanced with JS but still functional without it) to pull in so much code unrelated to the primary function of the site.
> client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.
As a developer that started off with client applications going on two decades, this is the attitude I despise most about the modern web, the frameworks that power it, and the developers building on it.
Developers serve the user. The user must always be the primary beneficiary. Forgetting that is why we have this bloat, terribly frustration UIs, inconsistent UX, poor accessibility, and everything else that plagues software development today.
It sounds like excuses companies make when they pollute the or exploit their employees. Solution for them to stop is to level the playing field by law. I think that one day the same will happen with software, and we'll all be sorry.
> I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
Does wondering that help you come to terms with the idea that you're creating things that range between "not the best user experience" to "thoroughly unpleasant to use"?
Personally I have been building websites (anything between sysadmin to backend and frontend) for 20 years, and my experience of the JS ecosystem is that it's utterly unpleasant to work with and in no-way better than other web technologies, but then maybe that's a delusion brought on by not eating enough.
> It outweighs all the end-user-facing cons by a lot
Well, I got so sick of crappy JS "websites" spinning my CPU fans that I installed the NoScript plugin, and now the web is a far nicer place to be. My browser is more stable and faster, uses less memory, and doesn't hog my CPU as much.
> But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites.
If "React" is used loosely here to mean a modern frontend framework, then at least one concrete benefit is the ease of splitting web pages into components, and the ease of co-locating CSS with these components.
I have tried Eleventy with nunjucks, but compared to the way React (Vue, Svelte, whatever) allow you to organize your code, it felt really awkward. Even Google dev rels, such as Jake Archibald, admit that they love the developer experience of something like Next.js [0]
This is pretty much it, tbh. Every time one of these types of threads pop up you get a bunch of people commenting about how broken the web is and how it sucks because front end devs aren't real devs or something, and it's immediately clear to me that none of them have done any serious work on a modern website.
The problem is a business/orgnanizational problem - it's not like developers are incapable of mimicking their own websites with pure html+css+js (especially with all the improvements to JS and the browser apis over the years), it's that doing that and then maintaining and growing it with a team of people is basically impossible at any useful scale.
Frameworks provide a common language for teams to build their site with. The fact that they also currently introduce a lot of extra complexity that require developers to handle previously "free" things (ex. performance, bundle splitting) isn't some fundamental flaw with the idea of frameworks, it's just a result of people still trying to figure out exactly how the hell you can provide a nice, interactive site with all the bells and whistles that'll make like 5 different groups of stake holders happy.
React is a great example of YAGNI and premature optimization. I'm sure Facebook benefits from it, but most websites don't need it. JSX is an abstraction encouraging deeply nested components, which makes state handling hard, necessitating the invention of React Hooks. "Controlling complexity is the essence of computer programming" -- Brian Kernighan. I see a celebration of complexity in modern website development and it makes me sad (I'm retired, I don't get that sad about it.)
I'm not a React expert, but I wonder how do you interpret this by Dan Abramov? This is where I got my information about hooks before trying them out:
React doesn’t offer a way to “attach” reusable behavior to a component (for example, connecting it to a store). If you’ve worked with React for a while, you may be familiar with patterns like render props and higher-order components that try to solve this. But these patterns require you to restructure your components when you use them, which can be cumbersome and make code harder to follow. If you look at a typical React application in React DevTools, you will likely find a “wrapper hell” of components surrounded by layers of providers, consumers, higher-order components, render props, and other abstractions. While we could filter them out in DevTools, this points to a deeper underlying problem: React needs a better primitive for sharing stateful logic.
Right, it's not that managing state was hard it's that sharing the logic to manage it was hard. Hooks are additive in that way -- it's offering you the ability to re-use your stateful React logic in the same way you can re-use your declarative JSX.
Use the right tool for the job. Why is this so controversial?
Yes SPA frameworks are overused but a lot of modern web "apps" are actually real applications and can't be built on a reload-the-world on a mouse click paradigm of the old web.
What constitutes a real application? There is some obsession with preserving client-side state as if the user could not live without it, and yet in almost every case where significant engineering has been put in to (essentially) reimplementing a web browser within a web browser, the result is either on a par or slower, and almost always vastly more cumbersome than just shipping a brand new page.
There are so many things the majority of applications never even try to get right, like progressive loading or history management, that have been solved problems for browsers since the dawn of time.
Separately, avoidance of client JS eliminates multiple classes of potential bugs, because eliminating (or minimizing) active behaviour on the client prunes vast chunks of the overall application state space.
I hire contractors quite regularly, and the amount of time I waste almost weekly having to explain "no Javascript, rip it back out, you're making a mess", because so few people seem to understand this. Our market is somewhat unique, in that most clients are high latency low bandwidth, but even if that were not true I expect my direction would still be the same.
"The page content is smaller as JSON" .. "you introduced a round-trip, game over"
"We only need 200KB of JS what's the problem" .. "the page didn't even start to render until the last byte of JS was loaded"
"We can implement mixed rendering and fix this on the server" .. "or you could just send HTML and rip out the JS, which is what we're doing"
This is an overly broad statement. In the last year, for example, I've built an in-browser SVG vector drawing tool and a very detailed dashboard with a lot of nested charts and data visualizations. Neither of these would have been possible without a heavy client-side JS component.
My current project is an e-commerce app that's almost entirely server rendered. I avoid JS where it's not needed but also avoid irrational biases against it when it is needed.
Joking aside, was thinking exactly the same while reading the article. This has been talk about for years, and today there is lots docs and resources for devs to be able to make a thoughtful decision of going SPA vs no-SPA.
It's controversial because it directly effects us. I wish I didn't have to develop in a JS framework but as a full stack developer almost every company I come across requires me to.
Honestly, I think it's controversial because a lot of frontend developers lack critical thinking. There isn't a nuanced technical assessment, they just go "Oh React is the industry standard let's use that", with no regard for whether or not it fits their use case.
I also see this a lot within the React community with things like Hooks, you have Dan Abramov giving one presentation and a lot of the immediate reaction is "this is a panacea, the future of web development, it's perfect".
You guys should give Svelte a try. It's a breath of fresh air for modern JavaScript. Your codebase becomes much simpler. It's much faster and lighter than React.
It doesn't give you absolute flexibility like React + JSX does, but it solves your most common problems much more pragmatically.
Obviously Svelte can't do nothing about the misuse of Svelte (which is one the major points of the article) but:
> The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too high for any company to include it as part of an SDK.
Svelte is just a simple way for you to write vanilla instructions. There is no runtime and practically no framework.
Other than React he is criticising problems which have better solutions than the ones he is proposing.
For example the bundle splitting problem can be solved by a smart browser refresh at the appropriate time.
The SSR problems he mentions are non existent with Svelte as the JS needed for an SSRd page is probably less than 5kB and since those are so small you can preload all JS files on the first user visit. He also mentions authentication problems which are non existent if your SSR app talks to the database and uses some KV cache for sessions. It's also certainly possible to cache the HTML, not only in the server but in the browser too using service workers.
As for his critique of APIs I don't agree. He also states that "GraphQL application will suffer under the N+1 query problem" which is true on the most simplistic implementations. Hasura, Fauna DB, and other GraphQL servers don't suffer from this problem at all.
> There is no runtime and practically no framework
As a fan of Svelte, I really wish people would stop repeating this. There _is_ a runtime in the form of repeating patterns of code, which are objectively less ideal than the not-so-revolutionary approach of just having a runtime. Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and having best-in-class perf. On the other hand, the question of how the Svelte repetition scales as an app grows is a constant worry that drives away would-be newcomers.
> There _is_ a runtime in the form of repeating patterns of code
Obviously there has to be some running code at the end, and technically you are right, but I think you're splitting hairs and for a brief introduction it makes more sense to say that there is no runtime.
Also I think I implied your point with "Svelte is just a simple way for you to write vanilla instructions".
> Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and having best-in-class perf
I'm not sure about this point.
I do agree Solid is currently faster than Svelte, at least on synthetic benchmarks.
OTOH compilers can optimize hand written code which a runtime cannot do. We see this in assembly written by C compilers for example which have been optimized for decades and will beat the vast majority of hand written assembly. Svelte is very young and, while I could be wrong, I believe we will see performance improvements over the years. I also think this would be completely unnecessary.
> On the other hand, the question of how the Svelte repetition scales as an app grows is a constant worry that drives away would-be newcomers.
If you're doing a SPA this can be solved with code splitting which is trivial to implement [1]. If not then Svelte will ship comparatively less JS than any other framework that needs a runtime[2].
BTW, big fan of Mithril here, are you still working on it?
I'm mostly worried about the _optics_ of saying there's no runtime, because if people think "hey Svelte looks cool BUT I'm scared my bundle size will be humongous", then they won't convert. And Svelte sure could use some more adoption to get the adoption snowball going. That's all that it boils down to.
Svelte is a compiler, and yeah you have to structure your code to fit certain patterns, but there is no framework in the end result as you would expect from React/etc.
Real World application written in Svelte requires a lots more libraries and code to supplement parts Svelte does not provide. So in the end you still have a big chunk of data.
Svelte does not make the problem dissapear. Svelte does not provide a solution. Svelte has exactly the same problem like React.
Not all of them. Without the overhead of rendering everything to a virtual DOM and then doing a diff, performance can get pretty close to native javascript--the sweet spot the author mentions gets bigger. Plus since the framework is mostly just a compiler, the bundle issue is less of a big deal.
Virtual DOM actually has some efficiency benefits. So it is not as easy as no Vdom = better. Also React, Angular or Ember does not add a lots of code to the project. I am 100% sure real world app written in each of major frameworks including Svelte has almost exactly the same size. Svelte has the same problems like React or any othe framework.
>Virtual DOM actually has some efficiency benefits.
Please explain these efficiency benefits. VDOM architecture can't be faster than native javascript updating the DOM because at the end of the day you still have to to use native javascript to update the DOM.
> Also React, Angular or Ember does not add a lots of code to the project.
They do to small apps. I tend to embed small svelte apps inside of a larger multi page apps to handle more complex UIs. In that use case the much smaller overhead helps tremendously.
You don't need a VDOM to use a buffer to batch changes. A VDOM is a buffer that comes with a huge amount of overhead vs an ordinary sequential buffer of DOM manipulation commands.
VDOM is an optimization that allowed react to be fast enough to work, it can never be faster than direct dom manipulation.
VDOM isn't useless. It's basically an optimized immutability helper. React wouldn't have been feasible without it.
But mutating the data directly is always going to be faster.
If you want to operate at a level of abstraction where you can ignore mutability and say rerender an entire huge ul every-time a single li changes, then using a VDOM to calculate the diff so you can only replace the single li is going to be faster than replacing the entire ul directly in the DOM. In many cases this is fast enough and so you get to program at a that higher level of abstraction.
However, if you have code that just directly replaces the innerHTML in the single li that changed, the VDOM can never be faster than that. Because it has to do that as well as calculate the diff to find which li it should change.
In essence Svelte just runs more of its abstraction optimization techniques at compile time instead of at runtime.
I see this sentiment a lot, and sympathize with it because I value accessibility and access to content by people with less powerful devices and connections.
But full time I'm employed to build web apps that I can't conceive of building without Vue or React or some other AJAX tool at least. For example, a node management system, displaying up to twenty disparate nodes at once. Client expectations are that any edited node is immediately persisted to the server. If I refresh the page, I've got to rerender each of those elements. If I'm not using tech that has things like v-for, I'm building out 20n wonk ass custom event handlers from scratch... I'd love to find ways to build this vanilla, I do that for my personal projects, but I don't see a path.
Reeks of obscurity engineering. Simple crud is being rewritten into react, things that could be done 300-400 lines are being written into 2 month long projects.
The vast majority of tooling, pages, functionality is so simple that I want to puke every time someone drops in node,react,Vue to replicate something that could be done in 100 lines of python or perl.
466 comments
[ 4.3 ms ] story [ 200 ms ] threadNo, I'm building a hard fork of wikipedia and I'm using Go to render the pages on the server side and a vanilla JS for a user friendly the rich text editor.
I don't know why not more people use WebComponents as a light weight alternative to React/Vue/Angular. It was natural choice in my case because it grew out of the desire to keep the tech stack small. For now I haven't find a reason to regret it, two way databinding is nice to have, but when the js is reloaded with every page, the global state is easier to reason about and less of a problem.
Momentum is a b#%~~ I mean, momentum is hard to ignore.
The sad reality is that trendy will always be driving behaviors for as long as recruiters attach value to buzz-words and -names.
Meanwhile, I guess a few will take the risk to do good engineering and damn the name of techs used, hopefully to rise to decision-making positions. Hopefully. Oh who am I kidding.
This type of stuff is one of the reasons why I choose to support older browsers like Netscape, IE, and Lynx. I think that a website which would have been usable 25 years ago has a much better chance of being usable by some random person using an old device I've never heard of and a browser I've never tested with.
However, if you want universal html (no changing the html for individual browsers) and some half-decent web-app functionality and no-js compatibility and accessibility and for it to look pretty, be prepared to spend many hours tweaking it.
Here's a video of some testing I did recently. Here, I discover that IE doesn't play nice with being forwarded to a URL which has an anchor at the end.
https://www.youtube.com/watch?v=M5tGkDgpq7w
I strongly feel we should create a lightweight HTML fork that is again document-centric and doesn't allow for all of this javascript nonsense. Something that doesn't allow for stupid custom UI or behavioural tracking. Just text, images, videos, and links. The painting algorithm would be dead simple, documents would load lightning fast, and we'd be confident there would be no ad malware.
I fear that most authors (and most creators of images and links) are not knowledgeable enough to see the web's shortcomings and that it will be very hard to explain the shortcoming to them -- with the result that most authors will continue to consider their job to be done once they have put their writings (and images and links) on the web.
Follow progressive enhancement. No JS should be required to load the contents of a page. If JS is included it should be to replace what would otherwise require a full page reload.
If it is not possible to load the contents of a page without JS or the JS fails to complete, then the page should show its alternative contents. The page shall under no case be left blank. This is graceful degradation.
This is advice for a web site owner, and I don't see giving advice to web site owners to be an effective way to help internet users who are very annoyed with the web like I am. Web site owners are embedded in an ecosystem controlled by entities such as Google and Mozilla who either don't know or don't care about the dissatisfaction I and people like me have with the web. I have come to believe that the best way to help internet users who are sufficiently like me is not to try to improve or change the web, but rather to start a new internet service outside of the control of Google, Mozilla, etc. Great grandparent seems to have come to a similar conclusion.
Modern web browsers are designed to satisfy goals X, Y Z, U and W. You are pointing out that browsers can be used to do X. I (along with great grandparent IIUC) are replying, yes, it can, but a new service designed to do X alone will probably do it better with fewer bugs and glitches. And all the web site owners with goals Y, Z, U and W are really getting in our way when we pursue X; our moving to the new service would give us a way to separate ourselves a little from those site owners, saving us a lot of time and annoyance.
HTML already has such a mode. It's called "turn off JavaScript". Fortunately, there are still plenty of good sites in that style.
(You can still have ads with plain HTML; they just aren't as annoying nor intrusive.)
The practice of website building on it is a great model for how to fix the web.
The web's UI is a document-as-app model... documents that use a small set of interactive elements to create a cohesive and useful experience. It beat many competitors that were applications for displaying documents. Document as app works really well. Users understand it. It costs less to develop than old UI guidelines defined desktop apps. And is portable to users on diverse systems... Web apps (and web pages) have succeeded where entire generations of cross-platform tech has failed... or succeeded mildly.
And that’s exactly what would happen again.
People (i.e. stakeholders) weren't used to responsive text and images yet. They wanted to tell the pixels on a web page precisely what to show.
I realise I'm in the minority, but I use JS whitelisting, which means that any SPAs I come across in my web searches (a disturbingly large number, and unfortunately increasing) will quickly make me go back since I can often find what I'm looking for somewhere else, on a site which doesn't require running arbitrary code just to render what usually turns out to be static content anyway.
The state of web development has always seemed a bit odd to me, largely driven by fashion and a desire for developers to "outdo" one another in complexity. There's a ton of churn and ADHD as people jump around from one trend to the next; instead of settling down and focusing on getting the most out of a platform, they're eternally in search of the next one. Reinventing/reimplementing in JS what basic HTML and CSS can do is just one example of this behaviour. The massive overuse of the "modern" adjective is another, and quite frankly all this really irritates me, as someone who just wants to use the Web as a hypertext document system to find some information.
How do you know when to settle? Should we have stopped at jQuery?
We are doing exactly what you are asking for, but not in the way you like. Web developers are getting the most of the web platform. The result is that new frameworks and libraries are keep popping up. Most will sink, a few will float and it's okay, this is how evolution should happen. I don't like all tech solutions that I encounter just because they are new. I simply just don't use them in my projects, simple as that.
I'm sorry, but the web not just a hypertext document system to find some information, it has outgrown this idea probably 20 years ago.
I disagree, as so many (perhaps most) web developers have no idea what to do with web technologies aside from building SPAs in their pet framework.
The number of times I've seen Kubernetes as part of an on-prem install of enterprise software when there will only be one node was hilarious. That front-end devs get flak seems to largely be because their choices are visible, not because they are any different from the weird heaps people throw together behind them.
For the bulk of websites that are mostly static with a little sprinkle of fancy interactions here and there? Maybe.
There is a time and place for React. Shocking to some, that place is not actually everywhere on the web. The bulk of the web IS actually about finding information. Few sites are soundcloud style webapps.
For context, I like react a lot -- I love its clojurescript re-frame variant. It is what I reach for _when needed_. The rest of the time, give me boring forms, pages, and jQuery and let me get on with my day.
You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least for me, I have to fight against every client, employer, and coworker to execute this approach.
Maybe web developers as a whole just got bored. They don't want to make webpages like they did in 2002.
Make a folder with some .HTML, .CSS, .JS files. Then sync it to a linux box. Wow, you're on the internet, a modern marvel. I see younger devs who don't even know this basic stuff. As if, this were all way more complicated than it actually is. It's not.
How do we get web devs back on track? Makers need to thoroughly understand their tools and materials, inside and out, for any industry. I'm just not seeing that as much anymore. It seems like an education problem, or maybe it's just human nature to go for new and shiny instead of practical and reliable.
I was pushing to *nix hosts I didn't have to manage in early 2000. Actually, one of them I recently remembered and had paid a small lifetime membership for limited static hosting (<$100) and simple shell access and guess what--the pages I put together 20 years ago and supplemental files I had hosted are still there. Not only that, they still render as intended.
I've done absolutely nothing for 20 years at this specific host and it's working today. Yes, the content is fairly static and very simple (its 20 years old) but it's all there. It's a simple shared system and no it wouldn't scale out to support more than probably 10k simultaneous requests but its served its purpose over the years. No, there's no SLA. I'm not saying services like S3 haven't been able to improve on that older infrastructure but it goes to show what very simple systems are capable of.
I've not spent a second of time in 20 years worrying about security, someone else did for a very nominal fee. This isn't a new concept, now we have better scaling available for sure.
But some products are actually better as applications, not interconnected documents. For those applications, the browser fights you every step of the way, because that's not what it's designed for. You simply can't compare the UX of document-based web applications to native clients.
An SPA is just the web approximation of a native client. Your application truly runs in the client process continuously, so rendering transitions happen smoothly instead of blank pages and jumping transitions. Everyone would benefit from understanding more and using that to simplify all areas of the tech stack, but the experience that an SPA offers is simply not possible otherwise.
PWAs, browser apps - they bypass all this work from professionals and give it in the hands of an unequiped developer. Oh god.
A browser is a window, an area of the screen that is allowed to do whatever it wants in a sandbox mode. This is a terrible idea. It becomes complete wild-wild-west.
Wrong on two separate levels.
First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever.
Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs.
The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity.
If you pay even a little attention to order of loading you can avoid FOUC entirely. If you pay a little attention to defining sizes of leading elements, you'll have constant layout of the top part of the page, and avoid flash of white background. If you use anchors here and there your user will be scrolled to the proper position.
Yes your page can easily look as if it got only updated with JS after doing a full load+render.
The technology is already in the browser; no need to approximate it with three layers of JS.
Thats complete BS, Iframes are just loading other HTML pages so you still need another tech to allow for static HTML to re-render itself. If your just talking about some kind iframe jacking then I don't see how thats remotely relevant.
Objects/Embeds? Sure you don't need javascript to make a page interactive if you have things like Flash/Silverlight/UnityWeb where your just executing through a completely foreign API usually via a plugin.
> Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs.
Maybe if your using something older than sandy bridge trying to use facebook I guess but outside of these kind of silly edge cases, ive rarely seen an iphone/macbook/desktop from the last 5 years spend more than half a second on any kind of heavy redrawing logic ever.
> The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity.
Then they can use another app website without JS that does all these features they want but with Iframes and flash.
I mean look at an iOS app designed by Apple. I always reference the AppStore app itself. You simply can’t build that app as a web app, certainly not by using iframes as a “solution.”
Whereas, with an SPA, you can _instantly_ show a progress bar, at least indicating that something is going on. And, the very fact that you're showing a progress bar means that the client side rendering isn't the slow action, it's retrieving something from the server. So, the UI was as interactive as possible.
An in-page progress bar is in most cases a failure of UX, not a success.
Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static. Why do you want things moving around and reacting? People of the internet - imagine if the internet protocols were given to us, but no browser existed. Would we develop this non-sense we have today?
What should have happened is the following:
- Develop web-to-native-UI mapper, call that thing a browser.
- Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig.
- Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app.
The web went downhill the day `<input>` tag was allowed to be styled by CSS. We had a web-to-native-UI mapper!
I am forever a believer that democratically designed things generally suck unless there is a BDFL who can make shots. Dictatorship is a necessity of great products and services - Steve Jobs to Guido, democracy is good in politics, not in software development. Feature creep from the public will ruin whatever youre buidling. Designers will ravage through what worked well and replace it with "taste".
/Rant, I am getting old. Humans tried to make the web "pop", but instead it exploded with chaos.
Exactly. As a bonus, you automatically get the behaviour associated with a link that browsers already implement: people can bookmark a link for later use, open it in a new window, etc. All of which would need extra effort (and thus also easily break) if it was just a clickable element invoking some JS.
I've had some pretty annoying conversations with customer support and developers about things like this; almost always, the response is something like "we didn't think you would have a need to do that". They would not have needed to think about it at all, and it would work for me, if they had just used a regular link.
That said I'm not totally opposed to SPAs; highly interactive apps, e.g. realtime games and such, would definitely benefit as they wouldn't really make sense as a linked set of documents. But for everything else it feels like they not only reinvent the wheel, but make it square.
Yea, the web page _works_ but it’s ugly, and in poor taste. Users do not care about browser purity, they want an app that seems polished. You can’t get that experience by using semantic HTML at all.
This 'taste' issue probably matters more in some organizations than others. Hopefully they don't involve blind people in their business, because SPAs are notorious for being unusable to them. You can design an SPA with accessibility in mind (https://www.deque.com/blog/accessibility-tips-in-single-page...) but most devs either can't be bothered or aren't even aware of the issue.
We have a single page app and we regularly run it through screen readers to see what the experience is like. Since an SPA is not some magical entity and it does produce a real DOM tree, we can achieve a great degree of accessibility (not perfect) by simply focusing on the markup that's produced. That doesn't help with things like loading screens, but again, since we actually check applications on screen readers, the experience for pages that take a long time to render is not much better with pure HTML either.
I read the link you posted and it's a good resource. The #1 takeaway I got from it is:
> Make sure that client-side view changes are known to screen reader users by announcing the change in page title, using ARIA live regions and/or focus management.
That's a good idea and one we'll incorporate into our application.
Some other comments in the article are not helpful, such as:
> Consider whether a single-page app is really necessary, and if you even need to use a JavaScript framework at all.
This is a moot point. Using a JavaScript framework to create an application is not only acceptable, but extremely popular. So instead of trying to politically smash the idea of building an application using JavaScript, we should be focusing on how to improve accessibility in that landscape. We can and should figure things out.
I'm glad there are people out there taking the accessibility issue seriously, what you said does make me more inclined to evaluate framework-based solutions. Nice to know at least parts of the most popular JS platforms are maturing enough for this to be easier for devs to implement.
IMO, discussing this further will just yield a negative returns as I think there are some fundamental issues/gap between two parties in this thread.
No matter how much ppl kick and scream, the SPA is gonna make the web a much more user friendly place in general. When we fade away and the next generation of us come, they will take this as the new norm easily and happily.
And SPA doesn’t mean you can’t use real links or pages.
Someone should make a job board called noSPAjobs.com
Designer hate it
To be completely honest, this is one of my least favorite things about HN. As I write this comment and click reply, if I wish to navigate “back” after I post this comment, the first back button click with take me to this still-filled comment form. (Will I fuck anything up by clicking “reply” once more? This is an easy trap for a user to fall into.) The second back will take me back to the post comments. Which is weird, because this is where I was taken after posting the comment. The third back will take me back to HN homepage. I expect to go back to the homepage on the first back click.
And this nav stack works as it does because HN uses plain HTML forms without any “overkill” JS. But the reality is that the default back behavior doesn’t really fit most user expectations, because most people don’t understand that clicking each of these buttons added more and more to the stack. Most people don’t know what a stack is! :) I think this is a great example of why the default document behavior of the web doesn’t really match most people’s user expectations, and the normal form behavior on the web makes it way to easy to do the wrong thing, like re-submit information.
Have you tried clicking "Reply" once more after going back? If not, do try.
> Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app.
I'm not sure if this was supposed to be a case of 'how it once was' or 'how it should be', but this was never a reality, at least after the 90s. Native apps have always tried to style themselves just so (my company has a C# B2B GUI that has a little bit of assembly somewhere calling a Windows interrupt directly because they couldn't figure out another way to change the color of some window element). Even the earliest web pages were often trying to look as different as possible.
If I tried to build this on a "modern" stack I cannot imagine any benefit, only drawbacks.
https://purecss.io
The layouts are here:
https://purecss.io/layouts/
One other remark: people are happy when they learn about this. That is now my #1 predictor of success. Everyone I've demoed to has adopted the product within a day (usually during the demo), and tech wise it's no different from what was possible with the web 15 years ago.
And takes less time to develop in the first place! These frameworks just seem like pure overhead to me.
Or you could use some template system to do that… but if you need to use template, why not use react(or something like that) anyway?
The alternatives are not react and templates vs writing html by hand.
You write your website in XML and the browser renders it using the template
KISS - Keep It Simple, Stupid - Never let me down.
In any other field, 'modern' is the opposite of a selling point. People want tools that work, that are proven and have years of stability and momentum. But in web development, there is an obsession with the new and shiny. It's 100% about the developer's own experience in creating a program and 0% about the user's experience actually using the half baked and constantly changing web app.
On the backend, shiny technologies like Go have been exploding — Go modules only stabilized this year! Since React was released, we’ve gone through through at least two new ways of deploying a server — containers and serverless, replete with their own huge abstraction layers like Kubernetes — and we’ve moved from monoliths to microservices and back again. And in native land, the “Rewrite It in Rust” crew is doing their best to bring the new and shiny to systems programming.
I agree that frontend web developers are maybe a bit too enamored with new tools. But I don’t think that mindset is unique to them, at all; they just happen to be the most numerous and visible examples.
This is only true in shops where webdevs dabble in back end, same as node.js. In most places you will find recent versions of things that may be decades old - Python, Postgres, Apache, even Linux itself.
I don't think "exploding" is the correct word, although it is growing.
https://adhdawarenessmonth.org/everyone-has-little-adhd/
An ADHD diagnosis is not purely based off of exhibiting behaviors typically associated with it. While everyone is forgetful/distracted sometimes, ADHDers have a physical/chemical difference in their brain which make such behaviors impossible to avoid.
> Suggesting the whole world stop doing this is silly
One person at a time
Reminds me of the quote attributed to Margaret Mead, whom I actually don't know anything about besides the quote: "Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has." Too corny? Idk. I like it
In my experience this industry is riddled with literal adhd fueled idiocy.
I dont think everyone is a little bit adhd but i also dont give a toss if someone wants to use a metaphor on the internet.
Button up buttercup.
https://twitter.com/dan_abramov/status/1259614150386425858
React is fine per se, the problem is throwing these "simple, magic" solutions onto everything, without even caring what mountains of code end up running as a result. The minimum for a Discourse installation is 10 GB, for example, but PHP is the weird ecosystem, because reasons. I don't mean to pick on Discourse, but that's still crazy to me.
It's like driving a huge truck everywhere, even to get the mail from our mailbox, because it starts up real fast and we don't have it far to the garage from our living rooms, and then later on because we haven't walked in so long, we don't even remember what it is. And especially with websites, people also tend to forget that their website isn't the only thing anyone ever runs on their machine, some have to share resources with dozens of tabs.
I've been experimenting with Vue and I'm liking it more and more just for the simplicity.
https://reactjs.org/docs/react-dom-server.html
I'm really rooting for frameworks like Phoenix LiveView, Rails Turbolinks, Laravel Livewire to fill this void. SPA like interactivity by just rendering HTML templates and sending them to the client via Ajax or websockets sounds great to me.
I wouldn't miss JavaScript one bit.
Sapper (the Svelte framework) does the same if I'm not mistaken.
Getting SPAness on web and mobile apps for free would be the holy grail. Basecamp claims it works great for their mobile app.
But yes, I really hope ( especially the new Phoenix 1.5 ) HTML wins back some mindshare in dev.
[1] https://github.com/hopsoft/stimulus_reflex
So when I read an article like this (which I like by the way), I make comment/response style notes to make me think through it; its long but I've dropped it in here in case anyone cares:
The issue with bundle splitting for SPA's that he mentions is a real thorn in many peoples side. A not amazing, but workable solution is to structure the site as follows:
* Split your "entry" bundle down to nothing, so it is only the map of other things that can load and a bootstrapper that looks at the URL and loads the right one.
* On the server generate html files for all your main endpoints (or hot routes for dynamic paths), ideally these are Server Side Rendered, but at a minimum they must include a script tag for both the normal entry bundle and the correct primary bundle for that page (ie, you eliminate the round trip for requesting the bundle).
The issue of running an "out of date" app is a present one. I can often restructure it to gracefully cache the state and refresh at an appropriate time without the user noticing, but it is often a far cry from simplicity.
His attack on SSR is largely correct for the way people currently deploy it, but there is nothing stopping you doing it a lot better. It is perfectly possible to generate correct HTML that works without needing to have a hydration step - its just most people aren't willing to, or knowledgeable enough to, do the work to make only the parts that need rehydration be hydrated (or, allow everything to be rehydrated but with no effect to the majority of the page). To be clear, you don't need to hydrate links, buttons, or even basic forms.
Of course, anything that genuinely requires your app js to be around to do anything reasonable needs to be there; but if you aren't looking for a drag/drop stay on page interaction you can normally just add a traditional route to allow it as well (more work of course).
He is right about API's. Though I'd hardly count it as a web or an SPA problem. Software is all about abstractions and how they are very leaky (likely "unfixably" so).
I was surprised about the data fetching comment. I've taken a look at the React docs and done some searches around the web, and he's right. Unless you know what terms to search to get the useful patterns its just a mess of amateur/broken Medium posts.
SPA's are built on top of browsers that are trying to predict where we are going and react to where we were yesterday at the same time. I'm with the author that most things don't need react, and that the things that do are mostly SPA's that have to be SPA's. I have worked with other frameworks before, but my hammer is a nodeJS & React stack I've cobbled together; thankfully its very good at SSR generating static sites, so most people don't know I'm using such a big hammer.
And we finish with a wishy washy maybe its right maybe its wrong, do we need this, maybe we do, maybe we don't.
Here is something concrete. I'm writing a small web application for my sisters business that I'm going to be doing all the legwork to see if it can grow into something. It isn't a SPA, it has some highly complex interactions, and it only uses React as a static site templating language because of my exisiting well-tooled stack (hammers make things nails).
Web developers don't know what they are doing and oversell their capabilities.
To be more clear though, this isn't a new problem, just that the symptoms of the problem have changed as the tools have evolved. I remember starting at Travelocity in 2007 and they sure as shit didn't know what they were doing either. All the JavaScript developers there, except for 1 (so about 6 of them) were spun off onto a special project that never made it to production. There was 1 guy left to write JavaScript for the rest of the site in a company who only real product was a website and employed 3500 people. All the other developers were Java people. Most of those guys were scared shitless of web technologies. There were a few Java developers who had a solid working knowledge of CSS and JavaScript but worked extraordinarily hard to keep that a secret.
That was a big WTF, but then I discovered it was also the same at both Expedia, Orbitz, and Southwest.
Now people really, and I am not being figurative, expect Angular and React to do their jobs for them from solving technical problems to telling them exact what products to build.
Worse still is when you point out the incompetence that so clear to everybody else the developers doing the work get angry. I mean hostile out to stab in you the back angry. The non-developers see the dysfunction and have absolutely no idea how to manage it or solve for it. Sometimes the dysfunction is so pronounced that it leads to inter-department warfare within the company, as was the case in one of those previously named travel companies (not Travelocity).
Here I am 13 years later working on the web that is now a 30 year old platform (20 years old if you count the modern standard web), and its still the same shit show. How have businesses allowed such cancer to prosper?
The fact they canned whatever special project the JS developers were working on might have been the right decision (and I just checked, Travelocity is still in business).
They had no such thing. Sometimes their shopping carts were so horribly incompetent it’s amazing we generated any revenue at all. Pretty bad since they had no idea just how broke it was until investing in something like Tealeaf.
React is built on two fundamental ideas that are both extremely valuable. The first and most transformative is that the web is mostly made of _components_, and specifically that organizing the markup, javascript, and CSS makes many thing easier. The second idea is that _declarative programming_ is better than imperative.
The thing is, HTML and CSS are already declarative. So React is not inventing this, nor bringing it to the web, but rather providing a pretty solid idea for how to make Javascript (or more generally, complex interactivity in the browser) declarative as well.
Thus, as MacWright argues, there is a sweet spot for React (or similar libraries) where you have highly interactive, complex UI elements on the screen.
But the rest of the web really, really doesn't need it, and when you try to apply "React Everywhere" things get very bloated, slow, and complicated, very fast. This is _especially_ true if you didn't start from scratch with Next.js or create-react-app, but are incrementally converting an established application. It's just painful.
I think more and more people are realizing this, and the fact that Dan Abramov himself agrees is pretty indicative that the tide is going to turn. But the question is, what next?
One major problem that the author didn't go into is the special pain of bundling front-ends these days. The actual work of setting up and integrating a "modern" javascript asset pipeline with a server side framework is not trivial, and I've yet to see a framework nail this. In the ones I've used there's always some gotcha - if you don't roll your own web pack (and understand what every bit of it is doing), you will eventually run into some library you want to use that just won't play nice with the rest of your bundle, and then you have a problem. And on the JS side, even simplicity-focued tools like Parcel are SPA oriented, thus gluing them together with your server-rendered app is non-trivial.
I think that will remain an issue for a while. But it also means there's an opportunity for the "old school" frameworks to keep working at this and, if they really nail the bundling and server-rendered / reactive component handoff, to thrive in the next decade of web development.
It is far nicer doing that in React where you can just casually npm in some online component that does that rather than in vanilla JS or jQuery. React is basically a compromise between nice interactive websites and keeping it as programming.
Nothing stays simple and when it stops being simple, you want React.
Developers like simple sites like Hacker News. Nobody else does.
I'm not entirely sure about that. Pretty sure most people just want some program to accomplish the function they're using it for so they can move on with their day, not chase around an overly complex and forever changing UI they have to keep up with, ontop of their actual work.
I expect it, and I demand it. We're in 2020, I don't want to click around on hyperlinks - I'm sorry. I grew up in a world of interactivity and the iPhone.
My bar is very high for consumer services. Animations and smooth transitions are table-stakes.
I am impressed with simplicity, but most people aren't.
One word : Craigslist.
(my intuition was probably based on the fact that it's not very popular in Australia, where I am)
People like Google.
I'm convinced that users don't care for most "design" and "clever layout". Site owners do, but users don't. Which is understandable, you want your site to stand out so you make it special. Users usually don't want special, they don't want to think, they don't want to figure out where they need to hover for functionality to reveal itself etc. I do believe that users would be much happier if layout/design possibilities would be much more restricted, like they are on mobile, because there's no constant re-learning there.
The problem is that designers and developers need to get site owners on board, so they are selling to site owners.
They didn't even bother caching their most popular section or page.
The only thing it's imo missing is a sync feature. Like pouchdb or sharedb for files & sqlite rows.
If it's of interest I wrote a feature request for a first step towards this: https://github.com/zeit/next.js/discussions/12374
more like, your friends are listening to Weeknd on vinyl and gramophones because their friends do. The more i read about JS frameworks the more i want to start doing everything in Perl again, or C, because its the work that matters and not the tools.
I think this is at the root of it — most web devs today don't see that some plurality or small majority of web app use cases these days just don't require the tradeoffs of SPAs.
But there's a generation of devs who've come up exclusively on JS tooling (Node, Express, React/Redux or Angular) and the crowding effect has therefore made those the default choices, if only because the labor pool is big.
My honest belief is you can more quickly build most functionality needed for most businesses with a plain-old full stack framework like Rails or Django these days.
But the real value of those frameworks doesn't show in the initial speed to build (though it's there!) — it really shows up in how much common functionality (logins, file uploads, etc.) you get for free 6-12 months in, and how low your cost of change stays over time as a comparable SPA app becomes a pain in the butt to add new features to.
I commented below that I hope frameworks like Phoenix LiveView will be the future. Seems like the best of both worlds, the simplicity of server side html rendering with SPAlike interactivity. Of course not perfectly. There are tradeoffs no matter what decisions you make.
What I mean by that is that the way we learned is that the old/wrong way (php style templates) mix front end and backend development, and data with formatting. It's better to have data available through rest APIs and then consume it from something. Which is mostly true if you plan on being available in a reasonable way from smartphone apps, etc. but of course that means that your website should also be a client capable of working as similarly as possible to a mobile app - there you go, SPAs.
We need to find a way to keep those benefits without the bulk of current SPAs. But SPAs appeared for a reason, and it would be wrong to ignore why it happened. Being able to have front and backend devs working in parallel is a benefit, being able to server your content to several frontends is a benefit, etc.
(And if you're thinking "these people don't need apps anyway", the reality is that clients demand to have them - even if it's only so they can bother users with push notifications or collect data, they do ask for them).
There's no thin line for this, CRUD-FORM can be really complex or really simple. A thoughtful design choice must be made here between server-side-rendered html with some JS and a SPA.
React substantially simplified the page, and it actually looked and performed much better since there wasn’t any jankiness from HTML rendering before JS could correctly format the page. We were then able to experiment on the page to optimize the experience and drive conversions.
TL;DR, more often than you would expect, the tiny performance costs you face from using a SPA is more than made up for by being able to develop quickly and more confidently.
Some applications really want to make use of a richer UX, one that doesn't need to re-render the entire page from scratch on every button click. Maybe Gmail is the best example of using the SPA experience to drive a rich UX. The web browser was not meant to build such applications, that's something we don't acknowledge enough. The web browser was designed, since day one, to render and link between text documents. We've been trying to play UX catch-up for 20 years at this point, and it's finally converged with lots of support for treating the web as an application platform as well (React, Angular, etc.)
So we've taken years to arrive at SPA's, but I think they're completely justified. They absolutely have tradeoffs, but they're not pointless tradeoffs. That doesn't mean that all applications should be SPA's, but I also think it's completely wrong to say that all applications should be simple documents too.
My experience is quite the opposite. I still use Gmail's "Basic HTML" UI, and it takes less time for me to click a link and load a new page on that UI than any interaction on the default UI.
I can tell you that any non-programmer on the planet would ever choose that UX over the “app-like” feel. I think we forget that most users are not programmers way too often.
Why are those the only two options? By those terms do mean "document web" as HTML without any JavaScript and "application web" as HTML with any JavaScript, or something else?
I think the first seam should be network requests. Unwind AJAX: produce the "content web" and the "interactive web." The content web should be HTML with JavaScript that can respond to events, but cannot fetch new code. This sterilizes the malware aspect of the web: JS can no longer track you (it can in crafty ways but ad blockers are a match for these).
The second seam should be aimed at the other direction: empowering the web. Factor out the "app web." This provides a native-level API which can dispense with the anti-fingerprinting, second-guessing nonsense. But the app web has higher barriers: revocable certs, user reviews, potentially frictive installs.
Sometimes you just need something dynamic. I need it in 99pc of my websites. Why would I start with plain js, and then move to react. Plus I already have a base in react that can be shared with all websites. Much easier to maintain all in react than a mix
Gmail is is the perfect example of an app that loses more functionality than it gains by being an SPA. Middle click to open an email in a new window doesn't work, if it was a normal web page that would have come for free. This is more important functionality to me than saving a page refresh. Same goes for JIRA, middle click at least works but the the 30+ seconds to reload the SPA in it's own tab makes it unusable.
These are both document driven apps and the document viewer I'm using them in have some great features that they cripple.
The fact that things like middle click and right click can be overridden in javascript is pretty much one of the biggest failings of modern browsers in my opinion. It's developers giving the middle finger to standards, and browsers accomodating those whims without considering the end user whatsoever. If your grand design doesn't include basic functionality that browsers provide then great, feel free to create a native application that fits that design. Otherwise, please leave the functionality that I rely on every day, and works in 99% of other sites, alone.
I think what a lot of us are saying here is that SPA's in general are overused in our industry when simpler solutions are more appropriate. And that's having a negative effect on productivity and developer happiness.
These sites should stick to reliable, tried and true, pre-SPA technologies. But now that's "boring" and "not-modern" so they rebuild using React (or whatever is the popular SPA framework this month) and the result is often a huge degradation in site quality.
There are good uses for SPA's like ticket sites that have virtual queues and office applications. I just don't see the advantage SPA's give me for a lot of critical things I need to do in my life.
It's true that they are largely more complex than O.G. web technologies, and it worries me that they create a sort of gatekeeping effect on the industry, but I think it's disingenuous to outright claim React & co. are bad from a development perspective. I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
I've done lots of native development on Desktop and Mobile and I can sort of see how you get there if that's your point of reference, but if you work on web apps daily it's clear why the popular technologies are popular, and it's not hype.
I'd rather maintain a React app because it will be at least somewhat familiar than try to fight my way through someone's home-grown rendering framework that can't even be Googled.
^ maybe not if your dev team is used to using React but nonetheless.
^^ React could be any of the popular frameworks. They all solve similar problems.
It's not a contradiction. C# is "largely more complex" than C, that doesn't mean C is inherently more productive than C#.
Seems like the author had a few well articulated and valid concerns, and probably likes the taste of food too.
Lastly, I wouldn’t underestimate how this has built up slowly over time, and therefore how many people just don’t know any better.
Last year I assigned a feature to a junior dev which was quite simple. He spent two days hunting for and testing react libraries to try and build it. When he told me this I said, “Holy crap, that is overkill.” I tried to explain how easy this would be with just plain HTML and JavaScript and he didn’t understand, so we paired for about 90 minutes and the work was done.
At the end of that session this developer said to me, “wow, I didn’t realize you could actually do anything useful with just plain JavaScript in the browser. I thought it was like... assembly or something.”
This is a good, very productive, very fast-learning developer I’m talking about. He literally had never tried to use the DOM api, and didn’t realize it was, you know, useful.
I think there’s a lot of that in front end world today.
At one point or another things don't work and it's because of simple HTML... and not react.
Maybe that's not the right path to learn it but we've reached a point where if you want a job, plain HTML and JavaScript isn't it.... plenty of folks who had the benefit of developing their skills from HTML + JS all the way up will bemoan this situation.... but if they're hiring people they're not hiring anyone who just knows HTML and JavaScript without any exposure to anything else.
"We are raising a cohort of developers who knows nothing about memory management."
Sure, there are things you do not know if all you know is React, but technological changes make it irrelevant in all but the most niche of cases.
Although you can use React for mobile (Native) and desktop (Electron)
That's not a great argument here. Web development is much more of a continuous spectrum. Programming platforms are designed to hide the the layers beneath to a large degree. I'm not saying there aren't leaky abstractions!
We use the term "full stack" for web developers, but people visualize this with layers, but for me it's a really wide list of items and not a very tall stack.
That is fair. You need a bit of many technologies to launch a website. I always interpreted full-stack to mean that you could launch a site on your own, from the database to the buttons and thus do not require a dedicated frontend, backend, or dba.
But yes, that makes developers wide and not deep.
Coming back to C++ after a decade of Python I realised I had largely forgotten about how memory management works and that felt bad. I felt stupid, because not thinking about that wasn't necessarily a good thing.
You have to override the submit functionality which is built-in by the browser. You have to maintain state of what the user inputs, which the browser handles for you. You have to reset inputs, which the browser handles for you (button type=reset). And a ton of people forget to actually validate on the server because they validate on the client.
You don't have to maintain the state of what the user inputs if you leave the inputs as uncontrolled (https://reactjs.org/docs/uncontrolled-components.html) and access their value via a ref. You could even give them IDs and access their value directly via that if you wanted to, just like you would pre-React. But there are clearly advantages to making the inputs controlled by React, otherwise there'd be no reason to bother doing so (not saying that there aren't probaly a lot of cases where you could keep it simpler but people have been led to believe they need to put their form data in Redux so use some elaborate solution which doesn't scale, or whatever).
Also if you are doing forms in React, check out formik, it's the nicest library I've found so far. Granted it's not as "easy" as a straight HTML form that POSTs to a new page, of course, but modern web experiences often demand richer functionality than "the old way" allows.
https://redux.js.org/faq/organizing-state#should-i-put-form-...
Also, per the form libraries question: Formik and React Final Form are the two standard packages I suggest folks look at. React Hook Form seems to be gaining some popularity. Also, I recently ran across https://github.com/wsmd/react-use-form-state and tried it in one of my own projects, and was pretty impressed with it as a lightweight option.
Show me the HTML standard that supports SPA submissions that don't reload the page.
It seems that your problem is about SPAs, not React.
Any HTML form that uses a standard button element rather than a submit button. Attach a JS event listener to it, read the form, post by AJAX.
That was a thing long before React came along.
It's not the recommended way because as soon as you want validation or dynamic fields you need state anyway.
And there're easy libraries like Formik that handle all the annoyances for you (although taking you away from raw HTML at the same time).
Do you miss punch-cards too?
There may be plenty of advantages to using React but it isn't necessary for "SPA submissions that don't reload the page."
A long time ago, I wrote a single-page chat application that continuously updated through chunked transfers, with submission via a plain old HTML form that received a 204 response.
... but I'd also submitted the JS fragment to Chrome, of course. They ended up flagging it as a high security bug and, not surprisingly, beat me to a fix.
So I never got as far as making a patch, which I guess is why I still don't have a successful compiler career.
I did get a $1k security bounty from Google, though, so that was cool.
Let me see if I can google the bug report. This is it: https://bugs.chromium.org/p/chromium/issues/detail?id=282736
Ah, report reminds me that at that point, the app was all knockout.js. We ported it to a knockout/React hybrid later.
I remember when jQuery was the React of its day. Then browsers copied most of its stuff. And now we have moved in to Angular and React.
Frankly, web components can do most of the stuff React does - and even the JSX can be done with eval and concatenating some backticks to strings. As long as you are SURE the strings are coming from templates, they can be assigned at runtime similar to how React assigns at compile time. Not that you should do any of that crap!
Still, React and Angular are insane. React makes you use Babel for JSX and a bunch of esoteric rules that they then make workarounds for, such as “hooks”. And Angular is even more complex, with its digest cycles and mocks and bindings etc. It totally sucks you in.
If you want to use a framework that’s much more lightweight, use Vue. Or use the one that we built ;-) It treats CSS, HTML and JS — and the rest of the Web - exactly as it was meant to be, and doesn’t try to reinvent the well. Well, it does use Handlebars for templating, but can support any other one also.
The React fad is like jQuery.
And JSX feels like the programming style that I didn’t know I was I’ve been missing since the 1990s - like it’s the logical conclusion for working in HTML, when everything else was either doing sloppy string manipulation or really indirect object-graph walking.
I don’t love babel, but we have a hot-reload script that auto-compiles while I’m working and even swaps in components to my webpage without a reload! It’s actually _less_ friction than vanilla javascript. I cannot imagine going back.
I hope eventually some of these technologies get pushed into the browser, but honestly it doesn’t matter much - javascript is fast, we can afford to use it as a compile target
https://calendly.com/qbix/meeting
IMHO the framework makes way more sense than React in that it is a lot simpler to reason about, and it also treats HTML CSS and JS sensibly. React is a bit esoteric... but it has the backing of a large company so everyone uses it. It’s a bit like Wordpress is used by everyone despite its codebase being from 2004. Like it’s OK, I get it, you have to buy into the ecosystem. But I think one day it will be replaced by something cleaner.
https://qbix.com/platform/guide/tools
But the reality is that React is plain HTML and Javascript, in a less error-prone and maintainable package.
Everything you can do with vanilla JS you can do in React, but with React you benefit from being forced to separate the state of the DOM from manipulating it.
I don't buy the hipster-centric logic, for me it comes down to productivity. The bugs of yesteryear, tracking down which procedural code path led to modifying a variable, are mostly gone with React. And if you don't use it (or something like it), you end up implementing a subset of it anyway because it's a foundational part of coordinating UI with business logic. /shrug
All react does is remove the need to modify the DOM directly when you want to modify things.
Which is wrong, React doesn't address that in any way, shape or form.
This is far form the reality. And the reality is, that more often than not you do not even need JavaScript, not to mention React.
I see this everywhere in programming, not just frontend. I think this silent peer pressure influences us all to some degree. Whether through not wanting to look outdated or foolish, to just being tired of the uphill battle involved constantly fighting against the unstoppable momentum of the cargo cult.
Sure, you just do some javascript and HTML to get your thing working quickly, but that hasn't even been recommended since the days of Jquery (where it was recommended over just doing vanilla JS in order to maintain cross-browser compatibility).
It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable, and that's before even considering things like browser compatibility, accessibility concerns, localization/internationalization, etc. A simple app or product does not mean the internals are necessarily simple.
> It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable...
I don't think you are responding to the point that the previous comment is making. The point is that there is a spectrum from let's say, traditional, to full-on SPA.
When presented with most spectrums of choice like this, it's expected that most people will weigh in requirements first and choose the solution based on the requirements (if they are an engineer, or pretending to be one.) In terms of expertise, they might love to write SPAs, but they realize that the other options on the spectrum exist for reasons other than being in, or out of fashion.
The problem is that some folks overemphasize what's in fashion. There are many reasons for this, and it's something that happens across other disciplines, not just programming. That said, we have a unique situation with programming in that someone can be quite an expert while only understanding one end of the spectrum. It's very easy for these folks to hold sway.
When it comes to the "wrong way", I agree with you, but I'd go further. If the requirements demand a SPA then you need to go all in and use the best modern tools. There are a lot of things created as we moved out of the full page render ages which don't result in good SPA development (for users or devs.) Embrace Typescript, React, etc because these solutions have evolved from that in-between stage.
Using "browser compatibility, accessibility concerns, localization/internationalization" isn't a great argument here. These are often orthogonal requirement. It's easy to argue that full page rendering, or static HTML meets all these more easily. These apps can't compete if you need particular interactive experiences.
Tools like webpack, babel, and react are also orthogonal to whether or not you're doing an SPA. These new tools aren't just to make your app a SPA, but are meant to decouple the maintainability of your code from the implementation details. React itself isn't even a framework but a paradigm which just happens to have a specific implementation that requires their runtime. The most recent shift is to turn your components into pure functions, and this is less about the framework and more about decoupling your app rendering logic from the react implementation. There's no objective argument that writing vanilla JS is better than writing modern ES next code. These language improvements are done to improve the failings of the javascript language after all.
You can totally use React to purely statically render your website. This is what most SSR implementations do, and the only reason JS is still activated is most modern apps require interactivity.
If you start doing vanilla JS and HTML you're doing a direct implementation. That's almost always the wrong way just because of browser differences between operating systems, mobile vs desktop, and all the other features that aren't really bells and whistles but more and more necessary as technology serves a bigger role. Perhaps in 1990 it's fine that a website can be made for a specific user for a specific purpose.
Let's be real, the only reason we really need WebPack and Babel at this point is for IE11 compatibility and JSX.
Currently >90% of the browsers (that depends on the country) are evergreen, and have support for most ES6 features, including ES6 modules. As soon as we're able to drop IE11 (when will Google remove IE11 support from Youtube?), the only reason to keep those tools will be JSX, which is frankly a minor convenience compared to the rest of React, and there are multiple alternatives to it that are not that terrible. [2]
Apart from that, WebPack and Babel are extremely hit-and-miss and terrible slow for anything but small-ish projects.
If you're doing SaaS or enterprise, chances are most of your customer-base is already 99.9% on Chrome or, in the worst case, in enterprise Windows-centric companies, Edge and that 0.01% is just waiting for something to tip them off.
I really can't wait to get rid of those two shitshows. Or maybe replace them with something actually useful, like Typescript compiled directly to modules.
-
[1] https://www.npmjs.com/package/domz / https://www.npmjs.com/package/htm / https://www.npmjs.com/package/react-hyperscript
This is miles better than the previous alternative: manually importing shims or adding in css prefixes. Babel and webpack also enable macros and static code analysis tools so you can write code in "inefficient" ways that's more readable, and automatically generate more performant code automatically.
Browsers are still split, even if considering only desktop users. If you add in mobile users then all those iOS people are using Safari, not Chrome.
And because of this fragmentation you can't expect the latest ES features to be usable on day one. So you'll always want Babel so you can write the code the way you want, and have platform targeting be a separate concern.
It sounds like you believe that we should be writing very platform specific code for the web, which is a bad practice in general. Nobody should write platform specific code. Leave that to the compiler.
What I'm advocating is targeting evergreen browsers whenever possible: Chrome, Safari, Firefox, Edge, and their forks. They already have most ES6 features. Even Safari has great ES6 support. iOS is known for being very up to date. Fragmentation in Javascript is a thing of the past, as long as you only use features available for +90% of the people on caniuse.com.
If you're targeting evergreen browsers you can already write the latest Javascript, and would only need Babel for something like JSX. All those browsers have async/await, ES6 modules (aka import), arrow functions, and destructuring.
To separate your written code from what is actually deployed is much more of a con than a pro. I'd rather not need a compilation step if possible. My time is valuable. Babel and Webpack are slow as a dog for non-toy projects.
Manually importing shims are a thing of the past when you're targeting evergreen browsers. You can use something like Polyfill.io for edge cases, and it will cover the small number of
CSS prefixes have nothing to do with Babel or Webpack, they're normally handled by tools like PostCSS. Nothing to do with Javascript. Static Analysis is normally handled by tools like ESLint that can use Babel but can be completely decoupled from the compilation step. Or Typescript, which actually brings a lot to the table compared to Babel.
Again, this might be hard: maybe you need to handle customers with IE11. But to not need Babel is something we should aim for.
I honestly can't wait for Babel to be 100% unnecessary and to die. It is valuable in a world where Internet Explorer exists, but there is zero advantage in using it when it's unnecessary.
Your comment about 1990 seriously rubs me the wrong way because it seems to imply React et al. actually does something to address the points you make. It does not, at all. You still need to test your code on every viewport you support. And now you have to deal with an insane build process that rivals some C++ projects while doing it.
And there is absolutely an objective argument that staying close to the web platform is preferable than 200 layers of leaky abstraction and a 10MB uncompressed bundle of transpiled JS. The language itself is pretty okay in 2020, certainly not worse than anything else from the TIOBE top 10. I would definitely say writing a bunch of plain JavaScript is all that’s needed for most applications out there. If you can’t manage that without a frontend framework, the problem is certainly not with the platform or language.
We don't need to stay close to the platform because abstractions allow for more advanced applications. That's why most web apps don't use C, and should never use C, because 99% of the coding work is higher level tasks that don't need the bare-metal performance optimizations.
Say again? One is a framework, the other is an updated version of the language that can be transpiled to ES3 for (non-mathematically) provably identical results.
Well, React isn't something very 'shiny' anymore, for shiny things you would look at things like svelte or wasm.
React is older than jQuery's age when React was first born now.
This is a huge assumption. For example, I don't think any web dev enjoys wrangling with CSS positioning or workarounds because they want to be "rewarded by keeping up".
> Last year I assigned a feature to a junior dev which was quite simple. He spent two days hunting for and testing React libraries to try and build it. When he told me this I said, “Holy crap, that is overkill.” I tried to explain how easy this would be with just plain HTML and JavaScript and he didn’t understand, so we paired for about 90 minutes and the work was done.
I don't know what your feature is. But any decent web dev today has to think of multiple angles that are not present in non-frontend development
- Responsiveness
- Browser support
- Accessibility
- Internationalization
That is in addition to testing, error logging, analytics, etc. We haven't even gone to the business logic yet.
Many people underestimate how much work a good web app entails
2) All those concerns were present in the project I worked with said developer on, and were easy to handle with the basic tools of the browser.
The senior engineer could have just as easily wrote worse code.
Just some weird obscure Javascript floating around editing the DOM directly causing untraceable errors in the future.
React helps with lots of things;
- Testability
- Readability
- Less side effects
- Documentation
- Rendering
- Error Protection
I could rattle on forever, might be time to write a blog post, gets a bit tiring reading the HN users who think we've just made the frontend complex for fun.
Frontend development is HARD, factors include;
- Plethora of device models/sizes
- Latency / Async / Fetching (data)
- Rendering speeds based off how you coded it
- State Management / Cache Freshness / LocalStorage
- Server Side Rendering
- Code Bundling (js and css)
- Design / Transitions / UX / UI
etc
Now why is all this important? Because to be a competitive app, it simply has to be sexy and slick.
If I could do that with one style tag and one script tag, I would.
It sounds like you're reinforcing this divide by classifying people who have a different opinion to you as "hipsters."
They label your technology choice as outdated, and you label them as hipsters. You become the thing you fight.
I wanted to make an example that it was like starting work at a company, and seeing that they're still using phpBB (but with a 1 year old library)... but it seems phpBB is still being developed...
Doesn't that underline your point though?
Yes. And its important to remember that React is heavily marketed to developers by Facebook, just as MS does with Typescript, and Google does with Angular. The point of this marketing is to create a feeling that these technologies are "safe" and "standard". Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising.
That said, there are a few major functionality gaps in native JS that leave the door open for front end libs. The biggest one is some kind of sane support for templating, and the second big one is that async is too complicated (people who actually understand callbacks and Promises often dont realize how many devs dont understand them). Facebook, via React, provides solutions to these problems, and leverages them to get users to buy into the React ecosystem.
If somebody could show how to make a component in JS that could be included in a page as an HTML tag, and could talk to other components on the page then the need for React would just evaporate.
Of course. Most devshops don't have the manpower that FB/Google/MS have. You don't really have months to tinker around and create some new framework and then another 2x months to fix bugs and add new features to cover some edge cases. So you pick whatever is backed by a lot of manpower as it has the highest chance of being usable even 3 years from now.
I guess it's understandable though, the web was never really designed with its current use-case in mind.
People do so love forcing square pegs into round holes though.
Wow. These two sentences completely capture modern day Web Development, Javascript as assembly.
>I think there’s a lot of that in front end world today.
In modern Web development, ( and in possibly all area of software development ), instead of making things simpler ( not easier ), it seems we have been building premature abstraction after abstraction.
Frameworks are not inherently premature abstractions, but can be used that way.
I'm also a junior and the way I was introduced to React was by teaching me enough JS that I could theoretically write React (with a bunch of research).
One of the things I've noticed among other junior engineers (including myself) is tutorial driven development. Through a mixture of inexperience, laziness, and self doubt it can be easier to find someone else who's implemented something and just use theirs. Rather then thinking about a complex problem and naively coding up a solution finding someone else's hopefully battle tested code.
An example of this is how I used to make JS based games. I essentially used an array to toggle classes on a grid of divs divs in the style of an LCD screen. I hadn't heard of html's canvas element. My solution worked but I don't think anyone would think it's a particularly good one. If I had found someone's snake game and saw they used canvas I could have saved myself some headache.
I was appalled at the state of things in front end development till I realized my current project uses kubernetes (implies docker, helm), spring for implementing REST endpoints and ansible for deployments on the back end.
Now things are really fucked.
On both ends.
Over the last 15-20 years or so as a web development shop we've gone through Prototype, Jquery, Backbone, Angular, Vue and now React for JS frameworks. We've mostly settled on React lately. Our experience is however that it is wildly overused where it is not needed and adds significant time to development. Features that should take a week to build now suddenly have complex client side state management requirements (to name one issue) and take several weeks. We've seen this in several projects while working alongside experienced developers.
We do use React extensively and we find the sweet spot is in smaller components on a page, or highly interactive sections, things without lots of shared state, but it often seems like web developers have one hammer and it is not the right one.
This sounds like bad system design rather than a problem of React.
In general, I find React hate massively overblown. The problem seems mostly to be that everyone is using it, and "everyone" in the case of frontend devs is all over the place in terms of how they got there, what they know to do, and what they know not to do. If you're not careful, all of the JS ecosystem can give you a lot of rope to hang yourself with. The relative accessibility of webdev is a blessing and a curse.
When they (and django) took the web dev world by storm they were prescriptive and told developers how to do something, not just giving them a bunch of tools where you had to build your own app lifecycle, usually massively over-engineered. A whole load of mental overhead disappeared.
Just before Rails, etc. everyone was going on about Factories and the Gang of Four and people were building crazy startup patterns on their webapps using Singletons.
Whenever everybody except me seems to love something and I just don’t get it, I remember CORBA...
(Edit: yeah, of course, that was DCOM not CORBA, but anyway, that's where I flashed back to. :-) )
But I think the "React everywhere" error, is more or less the same as the "one language for everything" error, the "everything should be Windows" error, and many other cases of wanting to use only one technology and have it work for all cases.
The cheaper the developer, the shorter the period where they cost less.
I have never seen evidence of this.
Its a lie developers frequently mention because it sounds so thrilling to say. Approximately how much time does it save you in estimated hours? Its like asking for a helicopter to take me to work, because supposedly its faster. I'm simply assuming its faster without looking at any numbers or finances.
It's certainly faster to use jQuery to change a CSS attribute than it is to setup a React project but what's not considered in that calculation is maintaining the state of that attribute or making changes to the logic in the future. Especially on code you didn't write originally.
If all you have to do is validate a form, sure, use jQuery if that's your cup of tea. But I would still rather use something like React because I know I'm less likely to write buggy code or introduce a regression in the future. To each their own though.
Its a lie so long as the number sounds completely invented. I suspect the number comes from somewhere, maybe a vague memory, or a grossly unqualified estimation, but it isn't based on anything. It is something superficial that primarily serves as self reassurance.
When you have never had to bill people for your time, or you have never been to a board meeting, or never briefed senior executives this kind of fantasy is perfectly fine. The moment there is money on the table you are expected to do more than invent fictional numbers, or you will be replaced by somebody who can.
I do think it's more abstract and harder to justify properly when someone is a well paid salaried employee for a FAANG. But that's not me.
How did you come up with that? You tracked the time it took to complete the project with and without React and diffed it?
A closer analogy would be a comparison between different models of lawnmower or between a lawnmower and a different kind of mechanical grass cutting device. In which case, it seems you would need to log time to see if you've saved time using one over the other.
> There are a lot of problems for which I can't see any concrete benefit to using React. Those are things like blogs, shopping-cart websites, mostly-CRUD-and-forms websites.
And the thing is, this still comprises an awful lot of the web. If I can produce a web site with Lektor or Hugo or some other sophisticated static site builder, it's hard to see how React is going to bring anything to the table that either makes that web site easier for me to maintain or provides a better experience for that web site's users. If you introduce some dynamic elements to the web site -- well, just what are those elements? Ad banners? A simple image carousel?
And I think that's really the argument being made here -- use the right tool for the right job. If all you have is React, everything look likes like an SPA, but that doesn't mean that it is.
Is this really a problem with web developers? Or is it with product managers who demand SPA like behavior?
Having said that, though, I do not think it's a universal truth that all web sites must expand to fill all available functionality, which seems to be implicit in a lot of arguments here and in the highest-rated rebuttal to me.
Very quickly we are in a territory well done with react than with Hugo.
Most products, especially if it’s a company, are like this. Products are constantly evolving. Whether products should be constantly evolving is a different discussion and tools are only a small part of that discussion.
If you're an SaaS (or PaaS or whatever-aaS) company, then your web site is literally the core of your being. You're building an application that happens to run in the browser, so you want to build it like an applications! But a lot of companies aren't doing that. Hacker News, the web site we're on right now, doesn't need to be an SPA (and isn't). Does any CMS need to be designed like one? I'd never give a blanket "no," but I'd sure never give a blanket "yes." How about a company blog? A simple storefront? A customer-facing restaurant site?
Also, don't get hung up on my particular example of a static web site -- I wasn't arguing that all sites can be done with Hugo. :) But you could absolutely design a modern, maintainable CMS that lets internal customers generate their own reports, write their own queries, and define their own templates using Rails or Django or Laravel as the back end -- and that seemed to me to be what the original article was really trying to get at. We've gotten so hooked on "JavaScript is everything everywhere" that we may not always be considering whether a given project really fits that paradigm. "This project doesn't fit it now, but it might in the future" is nearly always a technically correct response -- but "what you're building couldn't possibly scale up to unicorn level" is nearly always a technically correct response, too.
https://news.ycombinator.com/item?id=23137367
I've been developing single page applications, mostly, for six years; and I generally don't enable JavaScript on a website unless it is otherwise broken and I actually care to use it. I'm developing a website right now that has some persistent elements (video call, interactive charts) that don't play well with server side rendering. For the elements that are fine without it I prefer to render them on the server when there are enough of them, but ultimately there are limits.
As a user and developer myself, that's the sort of selfish attitude that really really angers your users.
I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.
I've worked on "complex"[1] websites in PHP, all static/server-side rendered; zero need of JS, near instant load times, ultra low bandwidth and server CPU utilisation, and don't even need to think about "browser support" because it'll be usable with anything from the past two decades.
[1] complexity in terms of features and usefulness, not in terms of how much code and resources it needs. Unfortunately a lot of developers seem to think complexity as in the latter is a good thing.
A user is only unhappy if they withhold some money over it.
Of course, that only matters at scale. If your site never takes off, optimizing for user experience (instead of developer experience) wouldn't have paid off. On the other hand, maybe putting your users second lowers the chance of it being well received.
Yes and no. If you are selling to the CFO on the golf course, then you get paid and all the actual users are unhappy. This is the entire ERP industry.
On top of that, on the mass market, customers don't have a meanigful choice. They can't signal desires in the entirety of concept space; they choose out of what's available on the market. Which means the choice really lies with the vendors.
XHR was invented because without it, Microsoft couldn't make a web-based email client that behaved the way users expected an email client to behave. 20 years ago. I'm not sure you can reasonably claim this stuff is not also strongly driven by the expectations of users and and the desire to meet those expectations.
Millions of them, by then.
https://en.wikipedia.org/wiki/Outlook.com#History
See also Rocketmail.
20 years ago, the market for web-based email was well-established, not some push experiment.
Some of us still to this day prefer imap/jmap/exchange if the server support it in a meaningful way.
Cloud services aren't more reliable than owning your data. They're just unreliable in a different way. You need backups anyway.
Which emoji did she use?
I'm of course referring to the Markiplier drama of last year, where a streamer asked people to vote on his stream by typing in red/green emojis. This resulted in hundreds of people losing their Google accounts due to an oversensitive spam filter. The matter fortunately got sorted out (somewhat, not all accounts were unbanned), but essentially only because it involved a fairly well-known youtuber.
https://www.engadget.com/2019-11-10-youtube-reinstates-banne...?
And random automated bans (which happen on all big social networks) are only one fairly common failure mode of cloud services. Smaller services shut down or get acquired, taking your data with them, or they just shutter the products you depended on (and even if you can export data, there often isn't anything you can import that data back into). Governments may randomly make whole populations lose access to service (c.f. Adobe's Creative Suite and trade sanctions on Venezuela, earlier this year). And, of course, no Internet access = no access to service = no access to data.
In general, owning your data makes you vulnerable to physical world problems - floods, fires, etc. Using cloud services makes you vulnerable to relationships between you and third parties, as well as between these third parties themselves.
In the particular case of the emoji ban, the problem is that the FTC should never have allowed one company to control search AND email AND school document sharing AND maps/reviews AND video AND mobile phones, etc. If you don't use Google for your email, there's no danger of Google banning you from it. :-) More seriously, Google (and Amazon and Facebook and Microsoft+Github) needs to be broken up to protect consumers from one company having a chokehold on their digital lives.
Not including a patchy or high latency internet connection though, right?
Like the article suggests, there's definitely some middle ground where enough of the site is loaded on the first request for it to work, and then more things can happen in the background to make subsequent interactions faster and more reliable. That isn't a pure SPA and it isn't a pure SSR site either.
It's even evident for relatively basic things such as infinite scroll. Users on sketchy connections won't even see all the items in a web store if their mobile connection is sketchy enough, and they will never even know it.
There are some real costs here. Had anyone seriously A/B tested these things they wouldn't be so widespread.
Badly built apps that ignore errors and don't work well for users are certainly not limited to SPAs, and blaming SPA tech for that seems a bit unreasonable.
I suppose it just boils down to the fact that with more freedom comes more freedom to fuck things up. But when you see an industry systematically fucking things up, and being driven by economic incentives that encourage fucking things up, one has to wonder whether some of those freedoms should be taken away.
It wasn't clear for lots of users. There were common stories of people getting a connection error and refreshing a page only to find their order on an ecommerce site had been taken twice, or that a comment they'd made had been submitted a second time, or that a request to delete something had actually worked but the second request threw up an error because it couldn't be deleted again so it looked like it had failed. These aren't so much of an issue today because browsers warn about form resubmission, but let's not forget that server-side rendered websites in the past were absolutely riddled with UX problems and bugs.
That's not a defence of SPAs, far too many still get the basics wrong, but if you believe it was better when devs made "classical" sites I think there's some decidedly rose-tinted nostalgia going on.
[1] https://en.wikipedia.org/wiki/Conway's_law
Angular's model is based on "two-way data binding", which was also the paradigm used by Backbone and other popular JS frameworks of a ~decade ago. This means that any user interaction with your app directly causes some JavaScript value to change, potentially triggering side-effects. But you can also cause the same value to change in your business logic code, in response to some other event or change. Components maintain a lot of data internally, so your job as a developer is largely about making sure that these components stay in sync with each other, and with whatever non-component-oriented data you have.
This gets messy very quickly. Where is your data? What things can cause your data to change? What happens if you want to change a data schema, or introduce new fields, new components? Angular tries to solve this problem with a fairly complex architecture[1] which promises that all of this can be OK if you follow the rules.
The problem is that this architecture is so complex that most people can't follow it well: there are modules, components, views, directives, services, dependency injection containers, service metadata, bindings, a router, and events. That's ten concepts, and you can't build very much in Angular without knowing what those concepts are and how they relate to each other (and if you can build it without knowing these things, then you didn't need Angular).
React is much simpler: there is state, and there are views. State can be global or component-local, and I would suggest ignoring component-local state unless you can't avoid it. Views render whatever state is passed to them. State can be updated by events. This is the same basic loop that is recognisable in desktop apps, games, in fact most interactive software. There's no "two-way binding" because views render based on state, but can't modify it directly. This is a lot easier to understand and to debug.
React might be less "batteries included" than Angular, but Angular requires such an enormous battery pack because it is trying to solve problems in an insanely complicated way.
[1] https://angular.io/guide/architecture
Anyone who cares about privacy allows minimal JS etc. Especially if they're using Tor. And given Tor's high latency and low bandwidth, sites that require lots of client-server dialogue, and/or push lots of data, are a pain to use.
And yes, I've never built complex websites. Just static HTML. Because mostly they've been Tor onion sites, and that's what works best for them.
And..
And youre afraid of a gatekeeping effect?
Did you even read the article or are you just here to make sure the gate's locked?
Gatekeeping refers to making it seem like it's too hard to get into and therefore not worth trying for beginners/non-technical folk.
What do you think makes it falsely seem harder to get into for beginners, when it isn't really?
Writing such "more complicated" blog posts makes one look more talented?
I don't know
What about if you used a mature back end framework such a Rails, Django or Laravel for 95% of your app. And then vue or react for the 5% that rally needs it? Would this be more or less productive?
I think that's undeniably true.
You hinted at something that to me is a key point: A lot of web apps are built by teams at big organizations.
In that environment trends are compelling because they keep everyone on the same page. It's easier to onboard people, it's easier to hand things off, easier to maintain going forward.
That makes a strong case for using the latest frameworks even when they aren't the best solution for a particular problem but it doesn't make it right from an efficiency or user experience perspective. There are a lot of reasons why arbitrary complexity is expensive. One example: what happens when your page load times start to rise above the threshold where it starts hurting organic traffic? You probably don't scrap everything and start over, instead you hack solutions on top of what you already have. Now you've lost money in both free traffic, one time development costs and increased maintenance costs going forward.
Again it's not that react is bad, and either way people aren't going to stop using it for things it's not ideal for until another trend replaces or absorbs it. But I think there's value in seeing things for what they are, and having conversations about it.
And yes, I also implemented interactive desktop like applications as Web applications.
Server side rendering frameworks, with support for components and just enough JavaScript go a very long way, and best of all, they are faster than SPAs in every kind of device that customers might have.
[1] - https://github.com/turbolinks/turbolinks
I think Laravel has something similar as well. These are the three big groups that are actively frighting the SPA trend.
[1] https://github.com/hopsoft/stimulus_reflex
https://unpoly.com/
https://intercoolerjs.org/
The premise of the article is that they are not easier to work with and do not save time in most situations. I agree.
Most websites are fundamentally documents, even those that think of themselves as apps. You could even build gmail quite easily as a document based app with some limited use of fetch() or WebSockets to get the data you need, though it's one of the few applications where a less document based approach might help.
React and other js frameworks are a huge amount of overhead for very little gain if you see the web this way. Your about page is not improved by using react.
Well...fortunately people don't use React for making About pages.
These examples of why not to use React in these comments are silly, people use them for web apps 95% of the time.
No, About pages are out of fashion and people don't do them in high numbers anymore. But they do use react to display news articles, web shops, and all kind of text.
> it worries me that they create a sort of gatekeeping effect on the industry
Aren't these two quotes contradicting one another? If frontend frameworks make frontend developers' job easier, then how can they be regarded as contributing to gatekeeping? If it had not been for them, frontend development job would have been harder and would have required more expertise.
Template languages often impose language limitations to make easier for HTML/CSS coders to work with, without breaking the backend code, isolating their codebase from the backend codebase.
These limitations make them less composable and reusable than functions or objects, and obviously show more drawbacks than advantages for one-man-development, and reuse across projects.
My wild guess is that if we replace templates by components on the server side, we will see less React & friends, for me they mainly demonstrate the clear win of component based patterns against template spagetti.
This approach largely fell out of favor, but I don't know whether that was just due to Django's popularity vs other Python frameworks or Django template language just being more flexible and approachable, especially for front-end developers (and you could use it for any kind of text based content, such as emails).
More flexible and conceptually simpler tend to win over time, as people try to learn less things.
Not exactly making a value judgement about this, but imagine for a moment any other engineering discipline saying this:
Yeah, I kinda made this road 20x less efficient that I could have, but I didn't want to bother with the nitty gritty details.
Yeah I'm using trash materials to make this building, but I just didn't want the headache of thinking too much about it.
I've been writing working with the web close to 25 years now. It is amusing to see it come the full circle. How hard it is to understand, that you don't need react for some blog, or anything which is not even remotely an app?
Are you talking about the same web that ditched XHTML because you had to validate your site before publishing? And had those "works better on Mozaic in a 420x340 resolution" warnings?
Our salaries are expensive because, presumably, we're being paid to make something that serves the users. So anything that benefits us at the expense of the people we're serving should be rejected. How self-centered can we be?
I have a 20 year history of building websites, and a recent three year stint of building front-end applications professionally using mostly React, which I'm now proficient in. I also normally use a strict whitelisting policy for Javascript using NoScript. If it's not a tool that depends on it that I really want to use, or if I find no obvious reason for it to be using Javascript, websites don't get added to the whitelist.
Javascript, as far as I'm concerned, is a wide open vector for an ongoing large scale attack on my privacy. Not only that, but I also have to pay for it in battery life and memory. The occasional blog built in React without a static fallback will usually go unread on my end, and no one is losing sleep over it.
I also think that you are fundamentally missing the point of the article if you your experiences building native applications vs building web applications is supposed to offer a counterargument. It's a false dichotomy in this case; the blog was never a native desktop app. The marketing site was never a native desktop app. They're collections of documents and I have no idea how anyone could come to believe that arranging that using a framework designed to facilitate reactive web applications is easier than just delivering the documents using technology designed to do so.
Disabling JS by default severely reduces the ability of websites to pull user-hostile tricks (though it breaks web apps). No website (presenting static information to be consumed) should ever break with JS off, and any site that does is defective. I won't extend this to web apps (interactive dynamic functionality like Google Docs) though.
That you think it's a fair analogy doesn't help me in the slightest to understand what your reasoning is.
> Disabling Javascript isn't enough to 'protect your privacy',
In the same sense as wearing a face shield while operating a chainsaw is not enough to save your life. It goes a long way.
> I haven't heard of any tangible impact that would have on anyone's life.
Have you heard of Facebook? Google?
I understand that this is an unpopular opinion, but it's what I believe.
I haven't asserted that it has any negative impact. To say that it has no tangible impact (as you have) is decidedly wrong. Either the manipulation is working at a grand scale (which is scary in its own right), or people that invest that much money in targeted ads are idiots buying snake oil. Regardless, Facebook and Google now command huge social and political influence, and they're entirely in the business of using my private information to sell ads.
I guess wanting to be the constant target of increasingly direct attempts at manipulation is a matter of personal preference, but the fact that it has an obvious material impact on the world is not.
I installed the NoScript plugin (alongside my existing adblockers that also block social media stuff).
I love it. My browser (Firefox) is now far more responsive and more stable, and my CPU fans turn on far less.
So, this is the kind of thing I make for my employer. But guess what? I can still do things the way I did them back when I learned Rails over a decade ago: HTML templates and a very small amount of JS to tell the server to re-render them when the user needs it.
What many of us really need is not fully dynamic SPA-type things, we just need some dynamic forms and some page elements that dynamically respond to user input. This is all stuff that you can also do without JS, if you design your site to handle that use case! Rails still makes it easy to make this kind of site with plain JS (or a lightweight framework like Stimulus, or jquery if you really want).
But all that's to say I fully realize why and how JS is useful... and that's actually why I disable most JS by default in uBlock Origin.
The problem isn't the existence of JS, it's the fact that massive tools like React become the hammer, and everything starts to look like a nail. There's no reason for the sites I am usually interested in visiting, which are either content hosting sites (no JS needed at all) or sites like my own (that could be enhanced with JS but still functional without it) to pull in so much code unrelated to the primary function of the site.
As a developer that started off with client applications going on two decades, this is the attitude I despise most about the modern web, the frameworks that power it, and the developers building on it.
Developers serve the user. The user must always be the primary beneficiary. Forgetting that is why we have this bloat, terribly frustration UIs, inconsistent UX, poor accessibility, and everything else that plagues software development today.
What a user-hostile attitude
Does wondering that help you come to terms with the idea that you're creating things that range between "not the best user experience" to "thoroughly unpleasant to use"?
Personally I have been building websites (anything between sysadmin to backend and frontend) for 20 years, and my experience of the JS ecosystem is that it's utterly unpleasant to work with and in no-way better than other web technologies, but then maybe that's a delusion brought on by not eating enough.
> It outweighs all the end-user-facing cons by a lot
Well, I got so sick of crappy JS "websites" spinning my CPU fans that I installed the NoScript plugin, and now the web is a far nicer place to be. My browser is more stable and faster, uses less memory, and doesn't hog my CPU as much.
If "React" is used loosely here to mean a modern frontend framework, then at least one concrete benefit is the ease of splitting web pages into components, and the ease of co-locating CSS with these components.
I have tried Eleventy with nunjucks, but compared to the way React (Vue, Svelte, whatever) allow you to organize your code, it felt really awkward. Even Google dev rels, such as Jake Archibald, admit that they love the developer experience of something like Next.js [0]
[0] https://developers.google.com/web/shows/http203/podcast/soci...
The problem is a business/orgnanizational problem - it's not like developers are incapable of mimicking their own websites with pure html+css+js (especially with all the improvements to JS and the browser apis over the years), it's that doing that and then maintaining and growing it with a team of people is basically impossible at any useful scale.
Frameworks provide a common language for teams to build their site with. The fact that they also currently introduce a lot of extra complexity that require developers to handle previously "free" things (ex. performance, bundle splitting) isn't some fundamental flaw with the idea of frameworks, it's just a result of people still trying to figure out exactly how the hell you can provide a nice, interactive site with all the bells and whistles that'll make like 5 different groups of stake holders happy.
React doesn’t offer a way to “attach” reusable behavior to a component (for example, connecting it to a store). If you’ve worked with React for a while, you may be familiar with patterns like render props and higher-order components that try to solve this. But these patterns require you to restructure your components when you use them, which can be cumbersome and make code harder to follow. If you look at a typical React application in React DevTools, you will likely find a “wrapper hell” of components surrounded by layers of providers, consumers, higher-order components, render props, and other abstractions. While we could filter them out in DevTools, this points to a deeper underlying problem: React needs a better primitive for sharing stateful logic.
https://reactjs.org/docs/hooks-intro.html
Yes SPA frameworks are overused but a lot of modern web "apps" are actually real applications and can't be built on a reload-the-world on a mouse click paradigm of the old web.
There are so many things the majority of applications never even try to get right, like progressive loading or history management, that have been solved problems for browsers since the dawn of time.
Separately, avoidance of client JS eliminates multiple classes of potential bugs, because eliminating (or minimizing) active behaviour on the client prunes vast chunks of the overall application state space.
I hire contractors quite regularly, and the amount of time I waste almost weekly having to explain "no Javascript, rip it back out, you're making a mess", because so few people seem to understand this. Our market is somewhat unique, in that most clients are high latency low bandwidth, but even if that were not true I expect my direction would still be the same.
"The page content is smaller as JSON" .. "you introduced a round-trip, game over"
"We only need 200KB of JS what's the problem" .. "the page didn't even start to render until the last byte of JS was loaded"
"We can implement mixed rendering and fix this on the server" .. "or you could just send HTML and rip out the JS, which is what we're doing"
My current project is an e-commerce app that's almost entirely server rendered. I avoid JS where it's not needed but also avoid irrational biases against it when it is needed.
Joking aside, was thinking exactly the same while reading the article. This has been talk about for years, and today there is lots docs and resources for devs to be able to make a thoughtful decision of going SPA vs no-SPA.
I also see this a lot within the React community with things like Hooks, you have Dan Abramov giving one presentation and a lot of the immediate reaction is "this is a panacea, the future of web development, it's perfect".
It doesn't give you absolute flexibility like React + JSX does, but it solves your most common problems much more pragmatically.
> The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too high for any company to include it as part of an SDK.
Svelte is just a simple way for you to write vanilla instructions. There is no runtime and practically no framework.
Other than React he is criticising problems which have better solutions than the ones he is proposing.
For example the bundle splitting problem can be solved by a smart browser refresh at the appropriate time.
The SSR problems he mentions are non existent with Svelte as the JS needed for an SSRd page is probably less than 5kB and since those are so small you can preload all JS files on the first user visit. He also mentions authentication problems which are non existent if your SSR app talks to the database and uses some KV cache for sessions. It's also certainly possible to cache the HTML, not only in the server but in the browser too using service workers.
As for his critique of APIs I don't agree. He also states that "GraphQL application will suffer under the N+1 query problem" which is true on the most simplistic implementations. Hasura, Fauna DB, and other GraphQL servers don't suffer from this problem at all.
As a fan of Svelte, I really wish people would stop repeating this. There _is_ a runtime in the form of repeating patterns of code, which are objectively less ideal than the not-so-revolutionary approach of just having a runtime. Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and having best-in-class perf. On the other hand, the question of how the Svelte repetition scales as an app grows is a constant worry that drives away would-be newcomers.
Obviously there has to be some running code at the end, and technically you are right, but I think you're splitting hairs and for a brief introduction it makes more sense to say that there is no runtime.
Also I think I implied your point with "Svelte is just a simple way for you to write vanilla instructions".
> Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and having best-in-class perf
I'm not sure about this point.
I do agree Solid is currently faster than Svelte, at least on synthetic benchmarks.
OTOH compilers can optimize hand written code which a runtime cannot do. We see this in assembly written by C compilers for example which have been optimized for decades and will beat the vast majority of hand written assembly. Svelte is very young and, while I could be wrong, I believe we will see performance improvements over the years. I also think this would be completely unnecessary.
> On the other hand, the question of how the Svelte repetition scales as an app grows is a constant worry that drives away would-be newcomers.
If you're doing a SPA this can be solved with code splitting which is trivial to implement [1]. If not then Svelte will ship comparatively less JS than any other framework that needs a runtime[2].
BTW, big fan of Mithril here, are you still working on it?
[1] https://github.com/PierBover/svelte-rollup-code-splitting-ex...
[2] https://krausest.github.io/js-framework-benchmark/current.ht...
BTW adoption is growing nicely:
https://npm-stat.com/charts.html?package=svelte&from=2016-05...
2020 is close to the downloads of 2019 and it's only May.
Why is this a good thing? Surely most developers want a framework?
Svelte does not make the problem dissapear. Svelte does not provide a solution. Svelte has exactly the same problem like React.
Please explain these efficiency benefits. VDOM architecture can't be faster than native javascript updating the DOM because at the end of the day you still have to to use native javascript to update the DOM.
> Also React, Angular or Ember does not add a lots of code to the project.
They do to small apps. I tend to embed small svelte apps inside of a larger multi page apps to handle more complex UIs. In that use case the much smaller overhead helps tremendously.
VDOM is an optimization that allowed react to be fast enough to work, it can never be faster than direct dom manipulation.
But mutating the data directly is always going to be faster.
If you want to operate at a level of abstraction where you can ignore mutability and say rerender an entire huge ul every-time a single li changes, then using a VDOM to calculate the diff so you can only replace the single li is going to be faster than replacing the entire ul directly in the DOM. In many cases this is fast enough and so you get to program at a that higher level of abstraction.
However, if you have code that just directly replaces the innerHTML in the single li that changed, the VDOM can never be faster than that. Because it has to do that as well as calculate the diff to find which li it should change.
In essence Svelte just runs more of its abstraction optimization techniques at compile time instead of at runtime.
See this for example: https://stackoverflow.com/questions/60934557/how-to-bind-eve...
But full time I'm employed to build web apps that I can't conceive of building without Vue or React or some other AJAX tool at least. For example, a node management system, displaying up to twenty disparate nodes at once. Client expectations are that any edited node is immediately persisted to the server. If I refresh the page, I've got to rerender each of those elements. If I'm not using tech that has things like v-for, I'm building out 20n wonk ass custom event handlers from scratch... I'd love to find ways to build this vanilla, I do that for my personal projects, but I don't see a path.
The vast majority of tooling, pages, functionality is so simple that I want to puke every time someone drops in node,react,Vue to replicate something that could be done in 100 lines of python or perl.