1) Prevent reloading of the page every time the user clicks a link, reducing the overhead of fetching common content between pages multiple times (headers, menus, etc) and providing a more seamless experience to the user.
2) Better emulate the feel of mobile applications, for users who spend most of their time on their phones and don't often or have never interacted with a computer. Yes, those exist.
3) Improved network performance (by sacrificing initial load time). Once the browser downloads and caches the bundle on initial load, the user can revisit the page on regardless of their connection stability or speed.
This isn't to say SPAs are a perfect choice in all cases (they also have just as clear drawbacks), but saying "it's what everyone does" is the only reason they exist is downright false.
> Prevent reloading of the page every time the user clicks a link,
You don't need a SPA for that. And page load/render times are much shorter when html is delivered straight to browser fr most applications
> Better emulate the feel of mobile applications,
That's pretty weak defense.
> Once the browser downloads and caches the bundle on initial load, the user can revisit the page
Giving we're now in the world of Continuous Deployment, I doubt the cache lasts long.
All 3 of those reasons sound very reaching to me.
And here's the kicker - doing a SPA well enough to be seamless and performant is hard enough that most sites suck if they're delivering a SPA.
Also, if, for example, you do your payments or other sensitive pages in a SPA, you're still running 3rd party scripts on those pages for no reason. Let me know when unloading scripts(&their in mem code) is doable.
Few things annoy me more in this world than when someone "responds" to arguments by quoting half of them to construct and attack a strawman instead of the argument they're supposedly discussing.
Please don't dilude conversations like this, it doesn't do anyone any favors.
> Also, if, for example, you do your payments or other sensitive pages in a SPA, you're still running 3rd party scripts on those pages for no reason. Let me know when unloading scripts(&their in mem code) is doable.
Are you legitimately worried about unloading third party libraries into memory on the browser??
The way in which we consume and deliver via internet has moved on from the early days of the web. It's no longer just text, images and links. There's much more to it now, and SPAs are a reasonable step forward to providing richer experiences online with more functionality.
Not sure you could ever call them an anti-pattern.
I'd say a big part of the web is gaming, chatting, interacting. A lot of that content updates every few seconds. Without JS, websockets, ajax requests etc, do you suggest users load the entire page again whenever they want to see an updated view?!
Or is your opinion that it should only be possible to do those things in native, purpose-built apps? Because in that case, how do you justify using an operating system? Perhaps we should exclusively use purpose-built assembly code that you flash to some writable media every time you want to run a particular program!
Threading could be clearer. Less data would need to be loaded on each page load. I can imagine that a lightweight SPA to handle the a few standard views (e.g. listItems, itemDetails, profile, changePassword, submit) would cut down data transfer by a significant margin (20-30%, maybe more). The UI could also be much better on mobile, and we could give users the option to cache certain pieces of content offline.
What you’re suggesting is heresy on HN. It’s true, a little bit of interactivity, fonts/padding/spacing would improve HN. To this day my thumb covers both the upvote and down vote button.
Yes, the UX on mobile leaves a lot to be desired in my opinion. The two things that are going for HN in its current form is the fact that it's lightweight and fast.
A lot of people think that moving to an SPA would mean killing both those aspects. But the truth is, you CAN have an SPA that is both lightweight and fast - the developer just needs to know what they're doing.
I don't think printing is a viable solution for most users. I'm guessing most would want to download the comment threads to their phone so they could read them later in situations where connectivity is patchy (eg train/plane etc).
Right. You can do this now by loading the page in a background tab, leaving the tab open and then going offline. Works great.
Or you could reimplement newsgroups (but with less interoperability) as an SPA, which in theory would work great (once you work out the kinks) but in practice would suffer from all kinds of little issues in the from-scratch reimplementation of everything. For example, printing would probably forever be a wishlist item in the backlog.
I also love when i visit a website with a simple markup and minimal js. Not everything should be a react/graphql isomorphic SPA, but have you checked NotionHQ[0]? The whole thing is a single page react app. People use it to build wikis, manage projects and even create blogs and job postings. All that using client-side rendering. It doesn't load as fast as hackernews but most people seem to love it either way.
* That is the design pattern dictated by your large framework.
* Maintaining state is absurdly simple, but it requires original code if not using a big framework.
* The browser provides a simple standard API for interacting with HTML, but your framework provides abstractions you didn’t know you could live without.
That’s it. Developers twist themselves in knots trying to qualify their opinions as anything more valid than what sounds like incompetence, but with any level of informed discussion it’s clearly about competence (or insecurity).
Another big reason is that developers want to deliver a specific user experience that is simply not possible with the default page loading functionality of most browsers.
You mean the specific experience when back buttons aren't working? Or when urls don't make sense? Or when you can't just share the content by copying the url because it no longer identifies the conten? Or when you can't say if something is loading, missing, or broken?
This is my user experience with SPAs regarding navigation.
PHP wasn't good, fine maybe, though I understand it's better now.
it was kind of slow, and all the functions were inconsistent, and had a lot of foot-guns. It was easier to write more robust code and model-view-controller code in other languages. (not that it was impossible in php)
It’s hard to make the claim that PHP is a bad language and also claim that very similar complaints don’t also apply to Javascript. They’re both languages defined by their popularity in spite of how poor the language actually is.
That’s arguably the best reason to develop an SPA. But I don’t think the linked article is arguing against that as much as arguing against using “SPA think” in places where the user experience really doesn’t require it. There are web sites which are basically magazines/blogs whose reading functionality relies on JavaScript. Building a web site like it’s an app may give some advantages to the developers, but it’s almost always a slower, and sometimes more fragile, experience compared to just delivering HTML.
I'll offer up another reason, which I feel is a little more accurate:
* Your web app requires heavily interactive bits, such as smart forms, smart tables, previews, content editing, etc. To deliver such functionality in a maintainable way, you use a framework. (As a side note, yes it is possible to deliver this functionality in vanilla JS, but to make it maintainable one must essentially build an ad hoc framework.) Because most frameworks push users towards a SPA, you end up following the path of least resistance and developing a SPA.
I would argue most websites never require any of those. When any of those are required they don’t need a giant framework to achieve maintainability. All that’s needed to achieve maintainability is a competent developer who values both simplicity and written documentation.
This sentiment frustrates me. The majority of web developers today are application developers. I've spent the past 5 years delivering business applications via the web as a platform. The web has a lot of advantage as a platform: no install, cross platform, networked by default. But the web was not designed as an application platform, so making it into one is complex. Business applications have inherent complexity as well, and managing all that complexity is a non trivial task.
Posts like this frustrate me because you seem to be suggesting complexity in the web domain is largely incidental.
I would qualify this:
The web is simple when one uses it as intended. (hyperlinked documents that may or may not have interactivity beyond the hyperlinking and embedded media or animations etc.)
The web is complex when one attempts to do "GUI by RPC".
If one is OK with page reloads, this asynch remote folder browser hypercard thingy is fine.
If one seeks to replicate the event-loop desktop "window"-based application one will have the use-case for large frameworks as one will literally be re-inventing all the wheels, which they tend to do, as this is not the default behavior of the application we call a web browser.
Complexity in web products is largely the result of developers who don’t care because they need to ship a product only if that product is written in an extremely familiar way. That’s a product of people who don’t know what they are doing opposed to inherent technological impediments.
I form this opinion as a professional web developer with 20 years experience.
I respect your experience, but that does not match up with what I've seen, and what I've seen by proxy networking with other developers in my area. I do personally think simplicity is a virtue. I always try to collaborate with our business team to deliver only what is needed, in the most straightforward way. But if the customer needs a 20 field form, with logical dependencies and validation between fields, as well as an interface for searching/filtering/editing entries, there is only so much that can be simplified. And yes I know all of that can be done with vanilla JS, but I've done it both ways and I prefer the framework.
Just to chime in here. To be clear, I think dropping a vdom implementation into a page is a good middle ground between full blown “framework” and “roll your own js”. I’m not familiar with vue, but I’ve used React (a library!) to great effect on pages that require that extra bump of behavior.
It’s such a shame that many of these tools are pushed as large SPA solutions when they can just as easily be included ad-hoc over a CDN when necessary.
* And I agree that it’s just madness to wire up your own components once the use case becomes anything more than the most trivial behaviors.
I always enjoy a good faith discussion, but if you aren't going to respond to what I actually wrote there's no need to continue this. I _know_ the functionality I mentioned can be shipped without a framework. I _have_ shipped web apps without a framework. I've personally found the overhead of designing and enforcing an ad hoc framework to be not worth the effort.
...almost... i'll accept "an SPA on one server-side route for that one complicated page that's full of bells and whistles."
and then I'm still going to say "yeah, i'm roughly equally verbose and spaghetti-like in even the best most prescient framework from the gods themselves" and merely wish for the means of modularization: breaking my server- rendered page that my javascript "unfolds from" into further little bits that can each have their own smaller less-spaghetti like world without having to try to dynamically load and include javascript on the client.
Break it up. Divide et impera...
> Browsers change. Relying on browser-specific behavior means you’re relying on that one browser at that one point in time. Code to the standard, and test everywhere.
I wish this was listed at the top of the list, in the middle, and at the end. It’s super annoying when a site or application isn’t “supported” because it wasn’t tested in a separate browser (i.e. non-Chrome browsers).
I know it’s not always easy with a fair amount of nuance which the Chrome Compatibility post[0] touches on, but developing the web platform should be done openly, with the browser vendors working together to be compatible with each other and not introduce developer or user inconvenience. Otherwise you end up with web ownership and a fragmented platform.
Safari on iOs is a bit special. Some features are missing compared to the Mac version. You also need quite a few safari ios specific code if you want to build a web app. But this is a bit broken since Apple wants you to publish to the appstore and not release web apps anymore.
You also need a Mac to debug safari on iOs. I hate Safari.
Special is right. It's full of non-standard behavior I've had the pain of fixing because you need to target iOS, e.g. needing Safari-specific attributes to capture scrolling in a modal.
You don't need a mac to debug safari on iOS. There is remotedebug-ios-webkit-adapter. You need a Mac to debug Safari on Mac. Maybe that's the reason why some people only support Safari on iOS.
Yes but a number of features are disabled or buggy on third party browsers that use WKWebView or UIWebView (i.e. basically all of them). A particularly nasty one I ran into once was navigator.sendBeacon being completely broken with HTTPS urls: https://stackoverflow.com/questions/51844586/navigator-sendb...
At work we're forced to use a service for exchanging files where uploading a file is only possible in Chrome, but downloading a file is sometimes only possible in Firefox. Pinnacle of UX.
It's so sad that it became "acceptable" to not test in Firefox (as estimated by the number of sites I randomly encounter that don't work in FF but do in Chrome) right around the time that Firefox Quantum happened and Firefox became good again :(
Double-check that your initial privacy excitement during setup isn't the culprit. The couple of times that happened to me (Paypal being one) lowering my "Browser Privacy" setting from "strict" or "custom" back to "standard" fixed the issue. I would be curious to see examples of broken sites if you have em.
I feel like I’m using IE in 1995 hearing this comment, but it’s valid. I feel like time is repeating itself. This is one of those tips that never really stop being relevant.
The modern equivalent is tuning uBlock Origin, uMatrix, Privacy Badger, or similar products, on top of correctly configuring your browser itself.
Agreed -- but FWIW a fair number of times I've encountered problems using Chrome which disappeared in FF. As a veteran of the original browser wars (circa 1998-2000) I'm grateful standards have come as far as they have -- and to support Moz at the heart of the open web.
I left Firefox in 2011 because it was unusably slow on my macbook. My recent experience has been that it is much faster and I am considering switching back.
At work we use CentOS, which only houses the ESR builds of FireFox as it fits Red Hat's intentions. I started here a few months ago, and found out that the studio was using Chrome as it's default browser. Turns out they had made the switch during the 57 ESR branch and never bothered to try the browser after, completely unaware of the Quantum project. Since we were having Chrome issues (which were admittedly our fault) I suggested trying FF again (CentOS now shipping with 68 ESR) as I couldn't replicate the issue. A colleague tried FF 77 on a personal laptop and was caught completely off-guard by the sheer performance difference. I'm excited with 78 ESR shipping on the 30th this month, it'll be a fun time getting all of the improvements over the past year!
It's the snappiest browser at the moment and I love its render as text function and automatic ad blocking on mobile. I've made a permanent switch on mobile, but I tend to miss the Chrome dev tools whenever I use it on a computer.
It's also wonderful that the browser is truly privacy conscious.
Tried it again last week. Still slow, I'm afraid, despite Mozilla literally inventing a new kind of programming language to speed it up!
A lot of it has to do with design, though. ie. when opening a new window, Chrome draws the window instantly and then fills in the UI, while Firefox waits until the window is completely built to display it. Even though they become usable at roughly the same time, Chrome responds instantly to the command while Firefox exhibits zero sign of life for hundreds of milliseconds.
Definitely not true on my system. There is a flash of some reorganization of the windows content that Chromium does not do, but both windows open instantly.
And also: Come on, that wouldn't make a browser slow. Users open new windows once when starting the browser. The rest is about how fast they render pages, react to JS workloads, and maybe how fast they open tabs. FF is more than on par in all of this.
I open new windows constantly. Opening the actual browser though is a whole other story, where the difference is even more striking.
Curious what you said about FF reorganizing the window contents, in my experience Chrome does that and not FF.
It's true JS performance is quite similar. But I've noticed (measured) differences in page load speed as well -- including latency again, the time until it actually responds to the enter key and initiates a network request. (In the network panel this is reported as Stalled.)
> because Firefox on Linux was never actually that bad.
On Linux, I use Firefox primarily for browsing, but for development I use Chromium. The reason for that is because the JS debugger in Firefox is pretty damn buggy. Some things I've encountered (though they don't happen every time):
- On a breakpoint, type expression in console, hit Enter and it just hangs there without giving you the result. The console will be unresponsive until you unpause.
- On a breakpoint in some part of the callstack, type expression in console and see that variables that should be in scope at that point in the callstack are not in scope for the console.
- Go to a different spot in the callstack and see that the place that Firefox tells you you're at is not correct. It might be off by a few lines.
This might be a very good reason why developers prefer to develop for Chromium/Chrome. Not because they prefer it for browsing or for its performance, but because its development tools actually work.
I made the switch recently, like a month ago, and I've been discovering little things that are just more pleasant when working in Chromium. For example "Copy as cURL", is formatted neater. Firefox puts all the curl options in a single line, but Chromium separates the options in multiple lines.
Some businesses are willing to (and sometimes should) take a 30% cut in traffic in order to ship a product more quickly. It's not a company/developer's fault that there are subtle differences between browsers.
Certainly not their fault. What's wrong is that it's possible to get the majority of traffic by developing for a single browser. They should not be sustainable doing that. It should be the case that in order to have sustainable levels of traffic they should develop for the standard. It should be the case that the cut is not 30% but rather 70% or more when compared to developing according to the standard.
Not entirely irrelevant, the thread is about browser support.
Also, I agree. I have a laptop with about 256 mb of working ram, so I only use terminal apps with it. If I'm trying to look up documentation and the site doesn't work with lynx it is not a happy day.
Looks like we are silent friends. The one thing I often get is just a message "JavaScript is not supported" and the other is wacky and long indices at the top. But, just having mywebsite.com/txt would not be a crazy idea...
It’s good advice (like most of the list!) but I’m not sure expecting a beginner[1] to “code to the standard” is realistic. The standard (i.e the spec) isn’t beginner-friendly. You learn by trying things out and seeing what happens.
1: Assuming they meant for the advice to apply to beginners rather than young developers - what age they are seems irrelevant.
Okay, this was long ago, but we had to roll out a new top-level website. I decided to be a complete hardass about it. Everything would validate, both for HTML and CSS. I would follow ADA standards as well as I could understand them. I dutifully tried things out in lynx. I even made some print style sheets (a new concept at the time). However, I had almost nothing to test on.
I got a lot of flak for being slow, we should hurry this up, and so on. And yet the emails would come in later from the higher ups, "Wow, this works on my Blackberry!" I had no access to such a device, but plodding adherence to various guidelines, as dull as they were, saved my bacon there. Even the disability folks I could find seemed pleased.
It isn't "move fast and break things" but you can reap a few benefits out of it.
Totally understand that, I don't like it, but I understand it.
My idea (when looking at the picture a tad narrowly, there's so many variables here) is really when it comes strictly to rendering content, all browsers should be the same. HTML/CSS/JS in one browser should produce identical displayed results/behavior in another. I'm all for the implementation being different, resulting in performance differences, differing external functionality and features, etc. But the core use, displaying content, should not be broken because you aren't using the browser the developer of the site/app was using.
Seems like a list of every web development ideal that gets upvoted on Hacker News.
Still, I think the list can pretty much condensed down to one point:
Use whatever technology is appropriate for this site or web app.
Because a lot of developers seem to have a 'when all you have is a hammer' attitude towards web development. They learn React/Vue/Angular/whatever, then seemingly decide everything they will ever build will use that framework, regardless of whether it's the right tool for the job.
A blog doesn't need to be an SPA. A static business site that never gets updated and doesn't do anything remotely interesting doesn't need to be an SPA. Your documentation doesn't need to be an SPA.
It's like that guy who was recreating CPanel as a WordPress plugin/install. Sure, you could do things that way, but may want to rethink whether this is really the best architecture to build a server control panel in.
I can't count the times I've started to write some basic internal tool with React only to rm -rf everything 1 hour later and replace it with 20 lines of jQuery/vanilla js
I think theres some validity to "you're the most productive with whichever tools you're most comfortable/familiar with", but I think people don't realize the levels of abstraction that come with web development.
( My learning path was: Angular 2 -> 7 + sucking at CSS, Angular + Tachyons (learning how to style), -> Angular + Custom CSS for everything, to Vue + Custom css -> Plain HTML + Plain CSS. )
Its like the more you learn the more you understand the boilerplate of libs/frameworks, but also understand what these large tools accomplish for you, and then you learn to appreciate how powerful & simple the "vanilla" web can be if you open your mind to it.
I can't count the number of times I had to write a HTML template for a small component with just jQuery and it was horrible every single time. Something like htm+preact [0] would clearly do the job much better and only add 5kB of Javascript to your site instead of leaving an unmaintainable mess.
It's literally just a folder full of perfectly normal HTML files. You don't need Javascript or a SPA to double-click one of those and look at it in a browser.
Even better, if your operating system has full-text file indexing, it'll be able to search them normally.
I was thinking (assuming this is one's own stuff), use rsync to download the files to avoid transferring lots of unchanged stuff. But if this is for an end user, yes, there would only be html access.
Edit: incidentally, a common way for this to work is that the documentation just comes with the software itself, so it's just sitting there on you computer. If the software updates, the documentation updates.
Websites like https://devdocs.io/ do this exact thing through desktop Progressive Web Apps.
Basically you keep your markup & source as static as possible, and allow a serviceWorker to cache those files locally. This can also be done with a SPA, but if we're talking docs, you get the benefit of only having to update a specific page if its raw html.
It's HTML, it's designed to link between URLs. Whether the URL is a file on your filesystem or on the web is irrelevant. If you keep all your resources in the same set of subfolders you can use the same html/ images/ CSS as the web and use relative links.
It amazes me that anyone asks this question. I have trouble seeing why you would want put documentaion in a SPA. Search result perhaps, but the rest of it?
I think it's a part of modern web developer culture. Where I work I started on a project which was already 3-4 months down the road and they were fully dedicated to react frontend and Koa on the backend. The whole stack was based on a react boilerplate the company built, as far as I can tell the idea of doing something other than JS on the server was never tabled. Likewise, the idea of rendering HTML on the server was never brought up. Everything is pure client side JS SPA even in places where it might make sense to just render things on the server or load a separate page.
Even as you are strawmanning our community[0] you outline well why it is such such a great community ;-)
[0]: most of us are not saying browsers shouldn't be allowed to run code, only that there's no reason why anyones statical documents should need to run code on my machine.
Many SPA examples will try load bits from the server and fail. And a non-SPA site can easily be provided as a download too, or use a service worker to provide offline access in the browser.
> They learn React/Vue/Angular/whatever, then seemingly decide everything they will ever build will use that framework, regardless of whether it's the right tool for the job.
At least where I live, small businesses contract with agencies that develop React sites for them, and suddenly these non-IT companies are owners of expensive and hard to maintain websites that they don't, and shouldn't need to, know the first thing about maintaining. No one wants to work with the projects, because they were written in, say 2015 React, back when React used X feature that isn't cool anymore, so it gets rewritten by another agency, and so on.
Meanwhile, WordPress on a managed host or a static site would suit those businesses just fine. Then, they wouldn't have trouble hiring to maintain it, or could even maintain it themselves.
If you work for an agency or you're freelancing, please stop burdening small businesses like this.
Serious question: if the business just needs a static site, why are they paying tons of money for bespoke software engineering? Just use one of the millions of good-enough and free site builders out there.
They don't know any better, and when they turn to the experts, they get upsold. Some business owners think they're the exception to the rule and seek out agencies for bespoke work, but again, they don't know any better.
But, yes, I've seen countless businesses for which something like Wix is perfect.
1. Site builders are still hard to use for most marketing staff, if the site should look professional and you need a few small integrations.
2. They don't mind paying for a solution where someone else does the work.
I guess it's hard for marketing departments to pick an appropriate agency and to know the consequences of the technical choices the agency makes. They generally evaluate based on design and then have a few requirements like: resonable performance and support for a handful of features in the backlog.
> Meanwhile, WordPress on a managed host or a static site would suit those businesses just fine. Then, they wouldn't have trouble hiring to maintain it, or could even maintain it themselves.
> If you work for an agency or you're freelancing, please stop burdening small businesses like this.
There aren't many more soul-destroying experiences as a freelance developer than maintaining a neglected WordPress installation that was built by a maverick agency that took the money and disappeared.
So much this. Bad plugins and outdated versions, cheap hosting with outdated PHP versions, cheap development with bad code quality. WordPress imho is not made to last without regular maintenance.
Honestly, 90% of the work out there seems to be maintaining some heap of shit, whether it is built in Python or Wordpress or whatever. All the better paid work at least. I have a theory that if a company has been around long enough top make money the software will be a mess.
That's why I suggested a managed WordPress host, so that they can outsource maintenance of their instance to professionals.
These projects get completely rewritten because they aren't fun to work with for most developers. What is being ignored is that there is an immense pool of labor that specializes in WordPress et al, and they're relatively cheap to hire. Even if these companies don't have dedicated staff to run their sites, many people are capable of using WordPress as long as its maintenance is outsourced to a managed host.
When I started at my current company I was shocked that they were using Wordpress for 90% of client sites. Now 2yrs in, I’m thankful we are using Wordpress for these sites. It keeps things maintainable and simple. And for 90% of businesses, that’s exactly what they need.
My take is just because you can doesn't mean you should. It seems like there is no such thing as infinite content, and if you feel like you are in a case where there is adding constraints will probably improve your product/ux
Infinite content can still be paginated, grouped, or whatever you like. For example think of Google search results.
Pagination gives mental boundaries, navigation markers and shortcuts to items.
Reading through infinite scrolling is psychologically addictive for a few reasons.
Another complaint about infinite scrolling is more technical: Implementations tend to forget your location, and/or significantly change the data when you return to the page. So if you leave an infinite-scrolling page and come back to it, you often can't continue from where you branched off.
In addition to not remembering the position and state, sometimes scrolling back down to where you were before takes a very long time. I've had occasions where I've had to scroll for ~20 minutes to reach an item I knew was there because I'd just seen it a few minutes prior, and forgot to use the "open in new tab" workaround when clicking on it.
My bank's phone app is bad for this. Scrolling through my transaction history takes ages. If I want to look at last month, no problem. If I want to check a transaction from last year, I'll have to scroll down and wait for a bit more to load, over and over and over.... Then if I click the transaction to view details, then return back to the history to look at more, I have to do the whole annoying scroll-and-repeatedly-wait dance all over again. For every transaction I want to look at.
And that's a mobile app not a browser, so no option to "open in a new tab". Mobile apps with all these flaws are horrible.
(Thank goodness browsers provide the "open in new tab" workaround for webapps that have linkable items. Pity it's broken by badly written webapps that don't make items linkable.)
The infinite scroll problem I feel comes up most that if there was a useful piece of information in the middle of an infinite scroll it is likely impossible for you to return there with any sort of reliability. You can't save the URL because it probably doesn't encode anything useful about where you are in a most cases. You can't logically organize 'where' this information is because its location is pure happenstance. It is pointlessly ephemeral. I can't start on page 5, I can't start on page 100. I have to scroll and just pray I get to get lucky which is the function of a slot machine, not someone who's trying to present me information. If I _really_ wanted to get that much more content I am more than happy to click the next button.
You don't dislike infinite scroll, you dislike "Social Media Feeds".
Imagine you are on a blog and can scroll back through all the posts chronologically in an infinite scroll. The location of that data isn't happenstance. You can always address a particular post or scroll to a certain date.
"Social Media Feeds" are bad not because they're infinite but because the sourcing algorithm is obscured from you likely to drive "increased engagement" or something nefarious like that. Pagination isn't going to fix social media feeds.
I didn't get that sense from the post. I took that they were advocating for basic HTML/JS when appropriate. A reminder that it's still a valid way of doing things.
If you're building an app, yeah use React.
If you want to put some contact info on the internet, there's no reason it can't be vanilla HTML.
Looking over the article again, I'd say your right. It was the statement "The web is built around server-side rendering." that made me feel that way. As a whole you're right.
However, I didn't think everyone was out making landing pages with React and VueJS. Maybe they are.
you could also use gatsby to generate static sites in that case -- imo react offers enough developer quality of life features where it's pretty hard to justify not using it
> Even if you need to preserve client state between page loads (for e.g. music or video playback) you can let the browser do most of the heavy lifting by fetch()ing a new page and replacing your content container at the DOM level.
Anyone knows of some easy to learn example of such DOM replacement?
Window load events fail to fire this way among other likely problems. You'd have to specifically design around doing it, or do something else like put the whole page in an iframe with your video/music player staying floating outside, or put back inside when it's loaded.
> Always validate your data server-side; anything that comes from the client is suspect.
At least sanitize in a way that won't break the server but will throw an error. For internal applications and side projects it's ok to just respond with a 40X or a 50X and move on.
> To the developer, “isomorphic” code breaks down the barrier between client and server.
"Breaks down the barrier" sounds great, but it's actually has been rather detrimental. "Isomorphic" is confusing even to the senior developers. Having a very clear delimiter of what runs in the server and what runs in the client is essential, and it makes your application much simpler to reason about. Take `isomorphic-fetch` for example... a request from a server to another API server has very different requirements and nuances than a request from a browser to a server.
OTOH, if you use Flow or Typescript, it is amazing to be able to share type-safe interfaces across the stack (not code). I suppose you could get this from any compiled-to-JS language too.
I've been using JSON Schema to define shared data structures like request/response data, and QuickType to generate Go structs (back-end) and Typescript interfaces (front-end), it's been great so far.
The realization that this permits end-to-end fullstack type safety and allows some awesome things (like surfacing breakage at compile time in response to changes to the data model) is a quietly brewing revolution.
This is in constant tension with the point that GP is making though.
If you’re not _very_ careful with your software architecture, you can inextricably tie your frontend and backend applications together. Depending on the size of your product, or why the growth plans are for that particular frontend/backend app end up being, this might not be a problem.
If it becomes one, though, then every bad technical design decision made in that `common` set of modules or packages ends up hurting you as it gets unspooled from (at least) two components that likely have very different architectural idioms.
When you really stop and unpack this, you can see that this is a non-issue. Adding an object or a field to the schema (the most common operations in a growing schema) never interfere with dependents and can be performed independently of client adoption.
The remaining coordination issues can be solved by documenting or using e.g. a '@Deprecated' decorator in Typescript. And, of course, you can always just remove a field to see where the code has dependencies on it (where code breaks during compilation).
The concerns about shared code may apply in some cases, but the global schema is not one of them, in my experience. I do agree it takes a bit of extra thinking to do this correctly but it's really not that difficult.
> At least sanitize in a way that won't break the server but will throw an error.
If you need to sanitize to avoid breaking the server then the server is already broken. Also, never sanitize, validate on input and escape/encode on output, but sanitization (meaning removing/cleaning invalid input) is the wrong way.
> To the developer, “isomorphic” code breaks down the barrier between client and server. To a malicious client, it means they have control over the server too.
Huh? I don't follow this. Sharing some helpful util functions between the frontend and backend doesn't allow malicious clients to control your server.
Maybe they are thinking of services like firebase where much of the traditional server logic is now handled in the same js libraries that the frontend uses? But I'm also not sure what exactly the author is referring to.
Think of transpilers like GWT, where you write java that's converted to in-browser Javascript; or the current trend of server-side Javascript.
(For what it's worth, both are really really cool technologies!)
Edit: But I also suspect this relates to a temptation to write browser-side Javascript without thinking about the server-side or database; IE, browser-side Javascript that just loads objects willy-nilly via fetch / AJAX and creating lots of round trips.
What I was trying to (clumsily) say is that when people develop "isomorphic" code they tend to forget that some of it runs on the client and some of it runs on the server and the interface between the two cannot be trusted.
Form validation is a common example of where things can break, like someone injects malicious data that's already been validated by the client-side code and then the server assumes that the code has already been validated by the client.
And if you don't even know which code is running where, that makes it even more dangerous.
Hmm I guess since it's advice to young developers they might make that mistake but any slightly experienced developer knows not to trust anything client side. Not validating data from the client isn't exclusive to isomorphic code.
People are motivated to learn and build what inspires them. Some started web dev because they wanted to make the type of projects they saw in chrome experiments that only run on the latest version of Chrome. Some people see very complex SPA apps and are inspired to make complex tools that can't just be done with HTML. Some get into web dev because they had a passion for browser and flash games. This list isn't wrong but also doesn't take into account the huge variety of web developers.
Excellent list. I would add: sometimes it's tempting to rewrite an entire site or application to get away from a world of problems, but you could just as easily be walking into another set of issues at the expense of lost time and existing code value if you aren't careful.
Grr... I read through the EmberJS tutorial and thought everything was very cool; only to find out that the whole thing is rendered with in-browser Javascript.
Advice: don't make everything slow as shit please. Note, this most likely means writing your own trim left function and not depending on zillions of libraries. If you can't write something as simple as this, please don't! Just output a static web-page that loads ultra fast. Thanks young web developers!
Why are infinite scrolls so demonized? I like them, especially if they update the url so you can go back to the same spot. Everyone loved it when Reddit Enhancement Suite did it way back in the day, but now Facebook does it so it's evil.
Ironically, it uses tumblr, so the damn back button is captured (try getting back here).
This is my fave:
> Infinite scrolls are inhumane. People need to be able to reach “the end.” There are forms of eternal torment described in religious texts that are less mean.
"Give people consistent but random stimulus and you will be habit-forming. Getting people hooked on your product might seem like a good idea, but the tobacco industry feels the same way."
DO NOT Listen to this. Make your site as addictive as possible. It can only help you win at life. More users = more impact = more money = better life. So long as it's not porn, your website won't be as bad as tobacco.
I think this is a little tone deaf to the target audience. Not all developers want to aspire to extracting the maximum amount of resources from users. Some, especially beginners who want to code, just want to build something and build it well.
328 comments
[ 4.4 ms ] story [ 290 ms ] threadLet's rebuild html rendering, navigation history, forms, etc, all with Javascript, because it's the hip thing to do.
Please don't misuse words, especially in a negative context to mean "something I don't like", it cheapens the word in legitimate cases.
No comment on whether SPAs are worth anything though, I reserve my opinion.
you've never seen certain architectures that smell because they're not following an established pattern?
1) Prevent reloading of the page every time the user clicks a link, reducing the overhead of fetching common content between pages multiple times (headers, menus, etc) and providing a more seamless experience to the user.
2) Better emulate the feel of mobile applications, for users who spend most of their time on their phones and don't often or have never interacted with a computer. Yes, those exist.
3) Improved network performance (by sacrificing initial load time). Once the browser downloads and caches the bundle on initial load, the user can revisit the page on regardless of their connection stability or speed.
This isn't to say SPAs are a perfect choice in all cases (they also have just as clear drawbacks), but saying "it's what everyone does" is the only reason they exist is downright false.
You don't need a SPA for that. And page load/render times are much shorter when html is delivered straight to browser fr most applications
> Better emulate the feel of mobile applications,
That's pretty weak defense.
> Once the browser downloads and caches the bundle on initial load, the user can revisit the page
Giving we're now in the world of Continuous Deployment, I doubt the cache lasts long.
All 3 of those reasons sound very reaching to me.
And here's the kicker - doing a SPA well enough to be seamless and performant is hard enough that most sites suck if they're delivering a SPA.
Also, if, for example, you do your payments or other sensitive pages in a SPA, you're still running 3rd party scripts on those pages for no reason. Let me know when unloading scripts(&their in mem code) is doable.
Please don't dilude conversations like this, it doesn't do anyone any favors.
Are you legitimately worried about unloading third party libraries into memory on the browser??
or else gaining the ability to freeze their code and all derived/generated code from accessing the dom/network/etc.
Not sure you could ever call them an anti-pattern.
Assuming you add video, 99% of the web is just text,images,links,forms, and video. None of these things even require Javascript.
Or is your opinion that it should only be possible to do those things in native, purpose-built apps? Because in that case, how do you justify using an operating system? Perhaps we should exclusively use purpose-built assembly code that you flash to some writable media every time you want to run a particular program!
Also, a SPA is not the only option with Javascript.
A lot of people think that moving to an SPA would mean killing both those aspects. But the truth is, you CAN have an SPA that is both lightweight and fast - the developer just needs to know what they're doing.
https://community.nodebb.org/category/2/general-discussion
1) Load the page.
2) The page is now fully loaded and ready for reading without any need for further network requests.
For even more offline use, try printing it! HN threads work superbly when printed, again unlike most modern sites.
Or you could reimplement newsgroups (but with less interoperability) as an SPA, which in theory would work great (once you work out the kinks) but in practice would suffer from all kinds of little issues in the from-scratch reimplementation of everything. For example, printing would probably forever be a wishlist item in the backlog.
[0] https://www.notion.so/
* That is the design pattern dictated by your large framework.
* Maintaining state is absurdly simple, but it requires original code if not using a big framework.
* The browser provides a simple standard API for interacting with HTML, but your framework provides abstractions you didn’t know you could live without.
That’s it. Developers twist themselves in knots trying to qualify their opinions as anything more valid than what sounds like incompetence, but with any level of informed discussion it’s clearly about competence (or insecurity).
This is my user experience with SPAs regarding navigation.
That doesn't mean good SPAs don't exist - many do!
And then people stopped using PHP.
Evidence?
In my experience, PHP seems to be more in use now than ever.
Conversely, I’m gonna need evidence that PHP is more popular than ever because that absolutely is an extraordinary claim.
it was kind of slow, and all the functions were inconsistent, and had a lot of foot-guns. It was easier to write more robust code and model-view-controller code in other languages. (not that it was impossible in php)
unfortunately it's the only actually viable language in the browser.
* Your web app requires heavily interactive bits, such as smart forms, smart tables, previews, content editing, etc. To deliver such functionality in a maintainable way, you use a framework. (As a side note, yes it is possible to deliver this functionality in vanilla JS, but to make it maintainable one must essentially build an ad hoc framework.) Because most frameworks push users towards a SPA, you end up following the path of least resistance and developing a SPA.
Posts like this frustrate me because you seem to be suggesting complexity in the web domain is largely incidental.
I form this opinion as a professional web developer with 20 years experience.
It’s such a shame that many of these tools are pushed as large SPA solutions when they can just as easily be included ad-hoc over a CDN when necessary.
* And I agree that it’s just madness to wire up your own components once the use case becomes anything more than the most trivial behaviors.
and then I'm still going to say "yeah, i'm roughly equally verbose and spaghetti-like in even the best most prescient framework from the gods themselves" and merely wish for the means of modularization: breaking my server- rendered page that my javascript "unfolds from" into further little bits that can each have their own smaller less-spaghetti like world without having to try to dynamically load and include javascript on the client. Break it up. Divide et impera...
I wish this was listed at the top of the list, in the middle, and at the end. It’s super annoying when a site or application isn’t “supported” because it wasn’t tested in a separate browser (i.e. non-Chrome browsers).
I know it’s not always easy with a fair amount of nuance which the Chrome Compatibility post[0] touches on, but developing the web platform should be done openly, with the browser vendors working together to be compatible with each other and not introduce developer or user inconvenience. Otherwise you end up with web ownership and a fragmented platform.
[0] https://news.ycombinator.com/item?id=23563525
You also need a Mac to debug safari on iOs. I hate Safari.
The modern equivalent is tuning uBlock Origin, uMatrix, Privacy Badger, or similar products, on top of correctly configuring your browser itself.
I've used Firefox for 15+ years now and never had the problems that people talk about.
It's also wonderful that the browser is truly privacy conscious.
A lot of it has to do with design, though. ie. when opening a new window, Chrome draws the window instantly and then fills in the UI, while Firefox waits until the window is completely built to display it. Even though they become usable at roughly the same time, Chrome responds instantly to the command while Firefox exhibits zero sign of life for hundreds of milliseconds.
And also: Come on, that wouldn't make a browser slow. Users open new windows once when starting the browser. The rest is about how fast they render pages, react to JS workloads, and maybe how fast they open tabs. FF is more than on par in all of this.
Curious what you said about FF reorganizing the window contents, in my experience Chrome does that and not FF.
It's true JS performance is quite similar. But I've noticed (measured) differences in page load speed as well -- including latency again, the time until it actually responds to the enter key and initiates a network request. (In the network panel this is reported as Stalled.)
On Linux, I use Firefox primarily for browsing, but for development I use Chromium. The reason for that is because the JS debugger in Firefox is pretty damn buggy. Some things I've encountered (though they don't happen every time):
- On a breakpoint, type expression in console, hit Enter and it just hangs there without giving you the result. The console will be unresponsive until you unpause.
- On a breakpoint in some part of the callstack, type expression in console and see that variables that should be in scope at that point in the callstack are not in scope for the console.
- Go to a different spot in the callstack and see that the place that Firefox tells you you're at is not correct. It might be off by a few lines.
This might be a very good reason why developers prefer to develop for Chromium/Chrome. Not because they prefer it for browsing or for its performance, but because its development tools actually work.
I made the switch recently, like a month ago, and I've been discovering little things that are just more pleasant when working in Chromium. For example "Copy as cURL", is formatted neater. Firefox puts all the curl options in a single line, but Chromium separates the options in multiple lines.
Also, I agree. I have a laptop with about 256 mb of working ram, so I only use terminal apps with it. If I'm trying to look up documentation and the site doesn't work with lynx it is not a happy day.
And that doesn't even touch on servers.
That's what I don't understand. How hard is it to just make a plain text copy of the data to serve to people who want it instead.
1: Assuming they meant for the advice to apply to beginners rather than young developers - what age they are seems irrelevant.
Okay, this was long ago, but we had to roll out a new top-level website. I decided to be a complete hardass about it. Everything would validate, both for HTML and CSS. I would follow ADA standards as well as I could understand them. I dutifully tried things out in lynx. I even made some print style sheets (a new concept at the time). However, I had almost nothing to test on.
I got a lot of flak for being slow, we should hurry this up, and so on. And yet the emails would come in later from the higher ups, "Wow, this works on my Blackberry!" I had no access to such a device, but plodding adherence to various guidelines, as dull as they were, saved my bacon there. Even the disability folks I could find seemed pleased.
It isn't "move fast and break things" but you can reap a few benefits out of it.
The one with the greatest market share is incentivized to the contrary in order to cement their position.
My idea (when looking at the picture a tad narrowly, there's so many variables here) is really when it comes strictly to rendering content, all browsers should be the same. HTML/CSS/JS in one browser should produce identical displayed results/behavior in another. I'm all for the implementation being different, resulting in performance differences, differing external functionality and features, etc. But the core use, displaying content, should not be broken because you aren't using the browser the developer of the site/app was using.
Companies also frequently skip testing in favor for faster release times.
Still, I think the list can pretty much condensed down to one point:
Use whatever technology is appropriate for this site or web app.
Because a lot of developers seem to have a 'when all you have is a hammer' attitude towards web development. They learn React/Vue/Angular/whatever, then seemingly decide everything they will ever build will use that framework, regardless of whether it's the right tool for the job.
A blog doesn't need to be an SPA. A static business site that never gets updated and doesn't do anything remotely interesting doesn't need to be an SPA. Your documentation doesn't need to be an SPA.
It's like that guy who was recreating CPanel as a WordPress plugin/install. Sure, you could do things that way, but may want to rethink whether this is really the best architecture to build a server control panel in.
I think theres some validity to "you're the most productive with whichever tools you're most comfortable/familiar with", but I think people don't realize the levels of abstraction that come with web development.
( My learning path was: Angular 2 -> 7 + sucking at CSS, Angular + Tachyons (learning how to style), -> Angular + Custom CSS for everything, to Vue + Custom css -> Plain HTML + Plain CSS. )
Its like the more you learn the more you understand the boilerplate of libs/frameworks, but also understand what these large tools accomplish for you, and then you learn to appreciate how powerful & simple the "vanilla" web can be if you open your mind to it.
[0] https://github.com/developit/htm
Disagree with this. Having the entire documentation site working as normal on my browser when I have bad/no internet connectivity is extremely useful.
Even better, if your operating system has full-text file indexing, it'll be able to search them normally.
Edit: incidentally, a common way for this to work is that the documentation just comes with the software itself, so it's just sitting there on you computer. If the software updates, the documentation updates.
Websites like https://devdocs.io/ do this exact thing through desktop Progressive Web Apps.
Basically you keep your markup & source as static as possible, and allow a serviceWorker to cache those files locally. This can also be done with a SPA, but if we're talking docs, you get the benefit of only having to update a specific page if its raw html.
If you are a javascript developer chasing the bleeding edge of web dev, it's pretty close to real time!
https://en.wikipedia.org/wiki/Doxygen
Run this:
You'll be surprised.Your system's package manager is installing the HTML documentation right along with the software you install.
When you update your system, new package versions along with their corresponding documentation are downlaoded.
[0]: most of us are not saying browsers shouldn't be allowed to run code, only that there's no reason why anyones statical documents should need to run code on my machine.
At least where I live, small businesses contract with agencies that develop React sites for them, and suddenly these non-IT companies are owners of expensive and hard to maintain websites that they don't, and shouldn't need to, know the first thing about maintaining. No one wants to work with the projects, because they were written in, say 2015 React, back when React used X feature that isn't cool anymore, so it gets rewritten by another agency, and so on.
Meanwhile, WordPress on a managed host or a static site would suit those businesses just fine. Then, they wouldn't have trouble hiring to maintain it, or could even maintain it themselves.
If you work for an agency or you're freelancing, please stop burdening small businesses like this.
But, yes, I've seen countless businesses for which something like Wix is perfect.
1. Site builders are still hard to use for most marketing staff, if the site should look professional and you need a few small integrations.
2. They don't mind paying for a solution where someone else does the work.
I guess it's hard for marketing departments to pick an appropriate agency and to know the consequences of the technical choices the agency makes. They generally evaluate based on design and then have a few requirements like: resonable performance and support for a handful of features in the backlog.
> If you work for an agency or you're freelancing, please stop burdening small businesses like this.
There aren't many more soul-destroying experiences as a freelance developer than maintaining a neglected WordPress installation that was built by a maverick agency that took the money and disappeared.
These projects get completely rewritten because they aren't fun to work with for most developers. What is being ignored is that there is an immense pool of labor that specializes in WordPress et al, and they're relatively cheap to hire. Even if these companies don't have dedicated staff to run their sites, many people are capable of using WordPress as long as its maintenance is outsourced to a managed host.
Pagination gives mental boundaries, navigation markers and shortcuts to items.
Reading through infinite scrolling is psychologically addictive for a few reasons.
Another complaint about infinite scrolling is more technical: Implementations tend to forget your location, and/or significantly change the data when you return to the page. So if you leave an infinite-scrolling page and come back to it, you often can't continue from where you branched off.
In addition to not remembering the position and state, sometimes scrolling back down to where you were before takes a very long time. I've had occasions where I've had to scroll for ~20 minutes to reach an item I knew was there because I'd just seen it a few minutes prior, and forgot to use the "open in new tab" workaround when clicking on it.
My bank's phone app is bad for this. Scrolling through my transaction history takes ages. If I want to look at last month, no problem. If I want to check a transaction from last year, I'll have to scroll down and wait for a bit more to load, over and over and over.... Then if I click the transaction to view details, then return back to the history to look at more, I have to do the whole annoying scroll-and-repeatedly-wait dance all over again. For every transaction I want to look at.
And that's a mobile app not a browser, so no option to "open in a new tab". Mobile apps with all these flaws are horrible.
(Thank goodness browsers provide the "open in new tab" workaround for webapps that have linkable items. Pity it's broken by badly written webapps that don't make items linkable.)
A DB tool I made has infinite scroll plus pagination buttons. It updates the pagination buttons while scrolling.
Imagine you are on a blog and can scroll back through all the posts chronologically in an infinite scroll. The location of that data isn't happenstance. You can always address a particular post or scroll to a certain date.
"Social Media Feeds" are bad not because they're infinite but because the sourcing algorithm is obscured from you likely to drive "increased engagement" or something nefarious like that. Pagination isn't going to fix social media feeds.
If you're building an app, yeah use React.
If you want to put some contact info on the internet, there's no reason it can't be vanilla HTML.
Or at least that's how I read it.
However, I didn't think everyone was out making landing pages with React and VueJS. Maybe they are.
Anyone knows of some easy to learn example of such DOM replacement?
> Always validate your data server-side; anything that comes from the client is suspect.
At least sanitize in a way that won't break the server but will throw an error. For internal applications and side projects it's ok to just respond with a 40X or a 50X and move on.
> To the developer, “isomorphic” code breaks down the barrier between client and server.
"Breaks down the barrier" sounds great, but it's actually has been rather detrimental. "Isomorphic" is confusing even to the senior developers. Having a very clear delimiter of what runs in the server and what runs in the client is essential, and it makes your application much simpler to reason about. Take `isomorphic-fetch` for example... a request from a server to another API server has very different requirements and nuances than a request from a browser to a server.
If you’re not _very_ careful with your software architecture, you can inextricably tie your frontend and backend applications together. Depending on the size of your product, or why the growth plans are for that particular frontend/backend app end up being, this might not be a problem.
If it becomes one, though, then every bad technical design decision made in that `common` set of modules or packages ends up hurting you as it gets unspooled from (at least) two components that likely have very different architectural idioms.
The remaining coordination issues can be solved by documenting or using e.g. a '@Deprecated' decorator in Typescript. And, of course, you can always just remove a field to see where the code has dependencies on it (where code breaks during compilation).
The concerns about shared code may apply in some cases, but the global schema is not one of them, in my experience. I do agree it takes a bit of extra thinking to do this correctly but it's really not that difficult.
If you need to sanitize to avoid breaking the server then the server is already broken. Also, never sanitize, validate on input and escape/encode on output, but sanitization (meaning removing/cleaning invalid input) is the wrong way.
Advocating accessibility is nice though, so do try.
Huh? I don't follow this. Sharing some helpful util functions between the frontend and backend doesn't allow malicious clients to control your server.
(For what it's worth, both are really really cool technologies!)
Edit: But I also suspect this relates to a temptation to write browser-side Javascript without thinking about the server-side or database; IE, browser-side Javascript that just loads objects willy-nilly via fetch / AJAX and creating lots of round trips.
Form validation is a common example of where things can break, like someone injects malicious data that's already been validated by the client-side code and then the server assumes that the code has already been validated by the client.
And if you don't even know which code is running where, that makes it even more dangerous.
Grr... I read through the EmberJS tutorial and thought everything was very cool; only to find out that the whole thing is rendered with in-browser Javascript.
The most ignored
<details> <summary> It's not a good idea </summary> really. </details>
This is my fave:
> Infinite scrolls are inhumane. People need to be able to reach “the end.” There are forms of eternal torment described in religious texts that are less mean.
EDIT: I've updated the Tumblr version to make this a bit more clear.
DO NOT Listen to this. Make your site as addictive as possible. It can only help you win at life. More users = more impact = more money = better life. So long as it's not porn, your website won't be as bad as tobacco.
You cannot convince me that the addictiveness of social media is a good thing.