Good. I could do without the JS, to be honest (I'm a little tired of pages that refuse to show me anything unless I whitelist some stupid third-party jQuery script in uMatrix), but, baby steps.
When sites finally ditched their trendy Flash rewrites and went back to HTML, I thought, thank God.
The JAM stack the author is talking about is entirely driven by JS. The is “static” in the sense that a .dmg file is static and can be hosted on a CDN and not templated on the server.
I’m not a JS fan but quit with the toxicity. The proprietary logic is done with languages like Go, Rust, Python, JS, etc and built with a RESTful API in mind so the frontend can consume it. Angular, React, and Vue are built to do this well. It’s all in moderation and should be done responsibly. The downside with this of course is added complexity on all levels. However with this design maturing the complexity has reduced some or effort offloaded elsewhere (microservices, serverless, k8s.)
That people use Javascript in places they aren't forced to use Javascript should make you wonder what the upsides are for them instead of assuming they cannot form any valid preferences of their own, unlike yourself.
For example, Javascript is one of the few languages that actually delivers on "async everything" and has a very simple Promise abstraction (like Promise.all()), and that makes it better for me than building networked services in similar languages (PHP, Python, Ruby). It's also one of the few dynamically-typed languages with a bolt-on static type system that actually gained traction.
You might not care about these things somehow, like maybe you only write C and Python because you work with embedded systems. But I think it's time to stop calling it garbage in honest conversation.
Maybe the problem here is building networked services (sounds like synchronous communication between components). How often is it that a well architected microservice architecture needs to do more than push data into a decoupling resource and data store and consume data from a stream or a queue? Is Promise.all( ... ) really that relevant that often?
I've come to enjoy Node.js more than I thought I ever would, but it's still not something that's ever mindblowing to me, and I don't think that switching to Python would be a huge burden. With sensible tooling and contracts, neither would switching to a statically typed backend.
Async-by-default from the perspective of the developer is one of the chief sins of JS, in this writing-JS-since-the-90s developer's opinion. I've seen and written so damn much code to work around async-by-default. Now most of the code I read is comically full of (justified!) awaits, so at least we got the sugar to fix it without so much fuss, but we shouldn't have to in the first place.
Let async code surrender control, but don't continue executing the current logic unless the developer asks for that behavior. Await-like behavior by default. That would have been much saner, less bug-prone, more helpful, and easier to learn & reason about. It's the desired behavior at least 90% of the time, in my experience.
"i could do without the js" is an indictment of design decisions, not js. its performant as hell, and ubiquitous. its a great thing, ...what people chose to do with it is often not great, however.
Be interesting to see if we could start charging website owners fees for them using our processing power to render their site.
Something needs to be done to encourage some efficiencies given the fact it takes more resources to surf the internet and read about running a k8s cluster than it does to actually run the cluster
Only above a certain price point. Our financial system nor our consumer culture support micropayments yet. This effectively limits the web properties that can charge users to a small fraction, so unfortunately "just charge money" isn't the widely-available solution I wish it was yet.
Hell, it's more viable to charge users for your mobile client than the backing service. It's kind of the closest we have to micropayments in a way.
When flash was dying I said it was a bad thing because ads would no longer be contained in these tidy, controllable virtual machines sitting adjacent to the page content but instead would be redone in JavaScript in a huge soupy mess where the content is held hostage by ads that slide in and out of the screen and cover content, popping in and out of existence, reflowing the page, making the content jump around and disappear as terribly coded flash apps become terribly coded JavaScript modules slogging the whole browser along with it.
People thought I was wrong and insane. I wish I was. Realistic assessments are always less popular than hope and principles. Flash was the good times.
Flash ads were trivial to block with plugins :-). And it was safe to block because usually no serious pages used Flash much except for artist portfolios.
It’s a nice title but webapps have evolved from documents to application bundles.
It’s super cool that we built wildly complicated apps out of what was in spirit an FTP client with a PDF reader but it makes since that we have to hack the document retrieval system less now that the client can run code.
Maybe one day we’ll stop hacking on the document store’s limited RPC-ish protocol too.
I dipped out of web dev in 2015 to run an ecommerce project. I stopped tracking all the latest js framework news. I settled on a barebones CSS rule set. I stopped choosing SPAs as the starting point for mvp ideas. I shelved Wordpress and moved some content sites over to Netlify and just recently started using a nifty desktop ssr cms instead of Hugo, Gatsby, etc.
I was regressing to the environment I understood in the early 2000s-2010s. I did all of this because I knew there would be a steep learning curve going into modern ecommerce and it seemed reasonable to put everything into hibernation while I attempted to go all-in.
I pretty much missed the entire React, Angular, Vue ramp up in the industry.
I've since shut down that ecommerce project and find myself peeking back to the js-verse every now and then.
I doubt I'll ever voluntarily use one of those frameworks for web dev.
+1 for Publii. It feels like it's early days for them (i.e. they only have a few themes & haven't been picked up by the third-party theme developer crowd yet), but man, does Publii make it easy for any end-user to generate and publish a static website.
Coffeescript was 'replaced' by ECMAScript 2015. Ember is fine but it's not the end of the line - it's been superseded' in most scenarios by React and Vue.js because those are generally better tools.
JS technology changes quickly not for its own sake, but because there are still discoveries to be made about how to improve both syntax and how we think about code. I'm sure the pace will taper off sooner or later, until the Web is taken over by something else.
It’s also because JS raced to integrate features which were considered standard elsewhere, back in the dark ages with anonymous self executing functions.
Ember is still going strong, Octane is a fantastic new release and it’s been awesome to un-learn all the ember specific things in favour of all the new vanilla JS ways of doing things that Octane makes possible.
About the only negatives I can bring up are IDE (and other sorts of vendor tools/components) support/integration is not as good as more popular frameworks like React, but that’s really just to be expected as vendors tend to target based on popularity.
1) Some CoffeeScript features, like arrow functions and classes, made it into ES6.
2) CoffeeScript was never updated to properly generate ES6. Largely because the features that got adopted by ES6 had subtle differences that made the migration path for existing projects highly complex.
I think, to a lesser extend, the rise of TypeScript also had something to do with it.
I think you're right. But I think that's because it's still early days, nobody has really nailed it yet. We're all trying to make sure that when something sticks, we'll be ready for it. It seems like TypeScript and React are sticking around pretty good. I'm sure they'll be replaced at some point. My personal hope is that they'll be replaced by better standards within the browser.
Virtual dom isn’t that expensive compared to modifying dom. Svelte isn’t magical, it’s still diffing objects to figure out whether to change some dom element’s attributes
With react memoization and pure components, you get very similar benefits.
Sure svelte goes the extra step and removes unnecessary diffing of constant attributes that will never change and other opts. However there are tradeoffs
Svelte components compile to vanilla javascript plus a small runtime (a dozen or so functions that track state for context and the developer tools). It's much lighter weight than React or Vue's runtime and a side effect is that integrating Svelte components into other frameworks is a breeze (especially if you compile to web components). The author refers to it more as a separate language.
I've had a great experience with it recently developing a smart tv app - which are dog slow even with a quad core ARM CPU due to the resolution so I decided to learn Svelte for the project. The big downside is another templating language to learn and as you said, the community is tiny, but the surface area is small enough that it hasn't been a problem regarding tooling or debugging. Pulling in other frameworks into a svelte app is also relatively easy so it can be part of a slow incremental rewrite, although as always it devolves into a webpack/rollup config mess.
> Svelte components compile to vanilla javascript plus a small runtime
Same could be said of React though. React components are literally just plain JavaScript functions which return VDOM nodes that get diffed and applied to the DOM by the runtime library.
The only objective advantage I see to Svelte is it's tiny footprint, which if you really need you can already get by using Preact (3kb vs Svelte's 3.5kb) without having to learn yet-another-completely-arbitrary-templating-language to no benefit.
Svelte is actually quite a bit different. Quoting a random section from their docs
"[Svelte is a] compiler that knows at build time how things could change in your app, rather than waiting to do the work at run time"
My point being there is a large amount of compile time code transformation at build time. The run time is not so much a framework as a library like libc. In Svelte when you update state there is no virtual dom, dom diffing, fibers, or anything. It would have been compiled into a direct dom update of anything depending on it. It's no longer a Svelte app just vanillajs. There are some details or course but it's a different paradigm than to react or other modern UI frameworks.
I made a web app framework [0] for people like you (and me). It lets you use static HTML to build a web app.
Data attributes store data in the page and add dynamic features (like CRUD functionality and drag and drop sorting) very easily.
Plus, the whole thing is server rendered with Handlebars, so the front-end JS part isn't even required for 95% of visitors (it's only necessary if you're an admin who can edit the current page).
I wrote it because I missed the simple days of jQuery and REST APIs.
It's an open source Node.js app, so you can deploy yourself it to any host with a persistent file system. No 3rd party database required -- it uses a file-based architecture to make it easier to get started with and modify the data. Its goal is to be simpler and easier to work with than anything else out there.
There's also a built-in CLI that can deploy to our free hosting service, which is built on top of Digital Ocean.
It seems the trend points to slower and slower websites with more JS bloat. I also notice a increase in JS-errors causing entire sites to malfunction, recently this happened to large apps like Teams and Float
If JavaScript is disabled in your browser and you visit mobile.twitter.com, you get a link to proceed to "legacy Twitter", which is their pre-React mobile site.
Twitter's redesign is one of the most performant SPA's I've seen in a while. It's really smooth and nicely designed too. A lot better than their previous webapp.
Do you know any others? Every time I’m redirected to twitter on mobile I’m in awe, it’s genuinely the only SPA I’ve ever experienced work “properly” on my phone comparable to a native app without any polish.
For their infinite scrolling, they clean the DOM above and below the viewport and only keep a certain amount of tweets rendered. So once you start scrolling a little faster, the JavaScript can't keep pace and starts sputtering.
The trend in my work is to add more and more JS to get the render time below 11ms per frame (11ms for my code, plus 5ms for the browser to paint and update, for a solid 60fps). To do that takes a lot of data structure design, memoization, cache management, plus a decent understanding of how browsers put things in the DOM and on the screen. Admittedly I work on something that's a bit unusual (a diagram tool for lawyers.. kind of like Visio-in-a-browser), but I can assure you that if you want robust, fast rendering it takes a lot of code to do it well. It is not bloat.
Simple: every machine has already installed the gateway to your program: a web browser. No need to deal with issues like antivirus going bonkers, weird MSVCRT versions installed leading to support requests, you save a ton of money when you need to support OS X or god forbid Linux, and last but not least, an SaaS business model has recurring revenues while it doesn't have to deal with rampant piracy at the same time.
There's a weird subset of HN that think people should still be building desktop apps. It's like they haven't paid any attention to the software market for the last 10 years.
I for one would love the return of the good old days, where I could pay once for $software, have it on a physical medium and could work with it as long as I managed to have a computer/VM that runs it.
So much culture, especially in gaming, will be inevitably lost with the SaaS and streaming trend. For media like video, music and books at least many national library laws require the deposit of two or more copies at the national archives, but interactive media? Games that require online activation? That's all gonna be lost forever.
A browser gives you robust networking, caching, rendering, and security out of the box. SaaS means updates and versioning aren't issues. Online means I don't have to consider network installs behind law firm's firewalls. I'd prefer not to have to touch any of those myself even if it means I have to deal with JS and SVG rendering performance (which is actually really interesting).
This is a minor inconvenience for things like reddit, but the trend has also arrived at the webportal for my bank ("upgraded" to some sort of React thing, meaning it now takes 10x longer to load) and my cell provider (site no longer works in Firefox as of last month; error message: "check that you're connected to the internet!").
No, the SPA hype has warn off and people realize that although these new technologies exist, they are not always needed.
If you are building a web app, use React or similar.
If you are building a web site, use plain HTML+CSS w/ supplemental JS.
Sometimes your project can be split in half. Do the landing page, signup, login, privacy policy, etc. in plain HTML.
Maybe don't embed all that stuff in your app and you wouldn't struggle with forms and routing, something that browsers can do very well with no programming.
Of course the reasonable answer gets downvoted. Stay strong! And remember that you're not a good developer unless you write everything in vim compiled for an OS that you wrote for yourself in C, backed up on a trusty old 2MB platter drive via a series of rsync scripts. I heard the concept of version control was originally conceived and canned by IBM in 1967, because it was found that version control would eventually become mainstream, and therefore bad.
Preach. I teach a little "into to web dev" workshop that starts with a slide explaining that static sites, SSRs, and SPAs are all perfectly acceptable. They're different tools for different use cases.
> If you are building a web app, use React or similar.
I disagree with this, there's no reason to use React/Vue/Angular for a web app by default. And I would urge people to try and avoid it for as long as possible and see how far you get. From personal experience I can tell you that most of the time, you don't need a frontend framework to build a web app.
> I find it fascinating that we are back to generating separate HTML/CSS and JS files and then putting them on a static file server — the CDN. It has been a decade long effort and as we come back to where we started, I feel like we are at a whole another level (a spiral?).
"All of this has happened before. All of this will happen again."
I was recently considering that we went through this cultural shift with computing: we started out by having a system to run code onvdistributed to terminals, then to actual desktop computers, then back to remote with the cloud, and now pushing out to "edge" computing. I'm sure it's more nuanced than that, but we seem to do these cycles, refining our processes.
> The Dark Age - Somewhere on this path to render pages on the fly (SSR) and render pages on the client (SPA) we forgot about the performance of our webpages. We were trying to build apps. But the web is about presenting content first and foremost!
Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- in the browser. And hey, if you use a lot of the same logic and data models in the browser as you do on the back-end server, it's only natural to want to try to centralize the code. DRY. The problem is basically what @s_y_n_t_a_x said: developers got carried away with it and starting using SPAs for everything, including sites with low interactivity like blogs, which turned out to be less performant.
> But the web is about presenting content first and foremost!
Says who? I understand that the underlying structures of the web are all about transferring documents and other resources. But Gmail showed us that web 'apps' are useful. Why shouldn't we pursue that? Just because the original web architecture didn't account for it?
In the end, the article makes the right point: Use the right technology for what you're trying to build.
Its performance is so horrible that even on a high spec machine with fast internet, you have plenty of time to click the "switch to plain ol html" button. Which is actually more in line with the performance I'd expect from a glorified file drawer.
Loads instantly for me on FF desktop and laptop running linux. But i have experienced what youre talking about.
You either have graphics hardware support disabled or youre laptop CPU is not running in perfoance mode and has its govenor set to something like balanced or power saving mode.
The same reason your desktop based email client probably depends on it. It’s 2020 and developers are starting to make use of all the modern browser features. It’s time to stop thinking like the browser is some fickle thing that needs to be caressed and treat it like a sandboxed OS environment for delivering apps and content.
Obviously native code is faster than a generalized scripting language for the web. Again, it's all about what you're trying to achieve. You can still use those fast native clients, but you can also access your Gmail from any device that has a web browser, which is basically everything. If Gmail is slow today, then obviously Google has lost sight of that point.
I've never found a way around it. Hardware acceleration on/off, windows, linux, phone, workstation, ff, chrome/ium, it always loads like crap. And my daily drivers are a dual xeon workstation or an overclocked zen3 machine, pretty far from laptop constraints. Gmail just has no interest in being performant, I guess.
I don't have this issue with other sites, it's just Gmail being Gmail.
I don't think it's graphics support, but I have the same experience: The vast majority of the time, gmail in firefox loads in fraction of a second, too fast to click "basic HTML" view. And I'm not on something like fiber, just basic cable internet.
I was considering things like Hotmail and Yahoo mail to be competitors. Free, ad supported, web based email. Was Squirrelmail that? I don't know I've hardly heard of it.
Squirrelmail is a GNU licensed webmail client. If you get a domain and hosting and they provide webmail for your domain, it's likely through Squirrelmail or one of a handful of competitors
I was talking about the early Beta releases that caught on like fire. Specifically with their use of XHR. That doesn't mean that web apps are always slow and bloated.
Try FastMail. Its beautiful and refreshing. "Old school" in everyway.
If anyone from FastMail is reading this - do not change your design or UI framework...like ever. The moment you start slowing things down with animations and bloat, that's a slippery slope...
Quite the opposite, it does its job pretty well for me. It has good keyboard shortcut support, and the UI is only lagging if I go into 80-100 long email threads otherwise pretty good.
What's unintuitive about a list of emails and few simple features? You also bog my mind :)
I don't like how it is formatted for starters. Also the reply button is impossible to find- since its not at the time like it logically should be. Reply all and other options are hidden instead of being exposed. When clicking on reply, it takes me to the bottom, away from the content so its impossible to read and response.
It also doesn't have proper mailboxes, and rules are impossible to make.
Your critique doesn’t really carry a lot of facts but mostly your negative opinion. New Gmail isn’t the fastest but it’s interface is pretty much OK and its rules are great.
As much as I advocate for web apps, sadly I have to agree with this, gmail is maybe one of the worst examples to use. Especially once they launched the new experience, the performance has been god awful. And frankly thats part of the reason I refuse to use Angular if the company that designed it cant even optimize it properly.
> It's slow and most people prefer the static html version.
The only people I've ever heard talk about the static html version are a few HNers. I'd wager 99% of people don't care, don't mind their email client's first load being slow (they just keep it open in a tab anyways), and don't even know about the static html version.
> The only people I've ever heard talk about the static html version are a few HNers. I'd wager 99% of people don't care, don't mind their email client's first load being slow (they just keep it open in a tab anyways), and don't even know about the static html version.
Are you claiming that because people are ignorant of an option that is clearly better for them, the option is redundant? So if people don't care about something, it's not better by definition of that fact?
Most people know Google’s webapps are slow, they just don’t know how to do anything about it. Or they notice it as worse battery life and fans running constantly and think there’s something wrong with their laptop because they don’t realize a web app can cause that, or even know what a webapp is.
Of course it's just my personal experience, but almost all of that's with "normies". Teachers (they live in Google webapps), writers (=avoid because terribly slow and input-laggy on low-end hardware, which ought to be all you need if you're trying to make money writing rather than impress people at coffee shops—and anyway it's not a ton better on good hardware), various other non-tech folks. The ones who don't complain about it do complain about its effects on their machines, without realizing that's what's doing it.
The trick is to never sort e-mails into folders... just leave everything in your Inbox and let it index it. I know it sounds terrible, but I have 25k e-mails in my inbox (I've kept all since 2018-01-01) and I can search and sort in milliseconds
> Use the right technology for what you're trying to build.
Yep .. so if you want a rich responsive user experience, DON'T use any web technologies. GMail (AND Gsuite) is a perfect example of how a relatively simple concept like email can be turned into a slow, unresponsive piece of garbage.
I'm about 99% sure the store on the PS3 was webtech. That beast of a machine could barely run its own store. They lost a lot of money from me as a result of the store being super-slow, input laggy, and crashy (OOM I assume), and I can't be the only one.
PS4 feels like they've taken webtech all over the OS interface. Its store's snappier than the 3 but the rest of the interface performs way worse. Usable, but far less pleasant.
[EDIT] store should be snappier than the 3, mind, since it's way more powerful hardware—it's still kinda slow, considering.
Previous versions of GMail had a good experience but was significantly faster than the current version of gmail. Loading basic HTML mode can get you a previous version of it.
GMail is a poorly built app, that's all. There are plenty of great examples. Both Outlook and Fastmail have fast and feature-rich email clients. Gmail was good back in the day and got carried away by project managers and feature creep.
Meanwhile Google Docs continues to be a pinnacle of what you can achieve on the web.
My experience with the Outlook web app (not the "basic HTML" mode, which is perfectly usable in contrast) is the exact opposite --- it's extremely slow and consumes a ridiculous amount of memory for what it does (I've seen it take over 2GB of RAM, and this is with an account where all the emails with their attachments total less than 100MB.) When composing a message it lags so much that it will delay each keystroke by several seconds and drop keys intermittently, and I have resorted to writing in a real (native) text editor and copy-pasting. In contrast, the native client has memory usage in the dozens of MB and is far more responsive --- I've never experienced it being sluggish to that extent.
What I wish for every Christmas is that web developers across the globe finally learn that syncing a draft server-side onkeyup is the worst idea, and it should never be pursued in implementing it.
Reality has rtt and shitty 2G slow, and will drive people away from your web product if you are too silly to cache things locally.
Unused RAM is wasted RAM. If you don't have anything else that needs it then just let your system automatically handle it.
Also I find most performance issues with big apps are a result of browser extensions that interfere. Try using a private window without any extensions.
Vacuuming up RAM while all the other applications have to fight over the leftover scraps or wait for paging to get the data from disk (1) is NOT a good thing as much as Electron-zealots want to normalize running a multi-GB browser instance for every single application.
(1): burning through an SSD's limited number of write cycles OR being at least an order of magnitude slower to access in the case of HDDs
Bloat RAM is also wasted RAM. If it's not being used as a cache of reasonable size, or in a time/speed tradeoff, all you're doing is making things worse.
> If you don't have anything else that needs it then just let your system automatically handle it.
That's a statement that only really applies to people misunderstanding RAM used by the page cache or suspended programs. And both of those depend on active applications not allocating that memory!
Who says it was otherwise unused? Web apps aren't used in isolation, the additional RAM you're using to speed things up by 3% has caused my code look-ups to slow down by 30% because you've consumed what was my file cache.
Says the OS developer, says the browser developer, says the webapp developer, says the developer of whatever else you have running.
Developer time is expensive. Says one.
Look it runs fine and is snappy. Says another on his maxed out development pc forgetting about his grandma.
Why should i care about that extra memory load when most pc's nowadays have x amount. Says yet another.
And so the slugfest continues.
>Also I find most performance issues with big apps are a result of browser extensions that interfere. Try using a private window without any extensions.
Browser extensions can definitely make a browser sluggish but most don't interfere with the content.
The only ones that do AND are common are adblockers which have a tendency of making it less sluggish.
> Pfff - That's completely wrong. SPAs are all about performance.
Why are they consistently slower than especially when there is low bandwidth or bad reception (lost packets)? Your large JS script has to be downloaded and parsed by the browser. This is fine when you have high bandwidth and low package loss. But if the opposite is true that initial hit to get all your JS code can be really painful. Writing really fast JS is hard and is not normally something that can be done in a framework. I know React is better than things like Angular, but there is nothing faster than vanilla JS.
I write a lot of pure JS and I write stuff to be very fast. However it requires more effort and a higher skill bar (to the point where I am weaker at server side development and terrible with databases).
A lot of SPAs can be replaced with with a post back mechanism and some caching of assets (CSS etc) and a sprinkling of Ajax. The less you have to download, parse etc can really make things less painful when you are in that situation.
The problem is that many developers don't bother to learn JavaScript properly so unless you give them a framework like Angular or similar you end up with the jQuery spagetti of the past.
> Says who? I understand that the underlying structures of the web are all about transferring documents and other resources. But Gmail showed us that web 'apps' are useful. Why shouldn't we pursue that? Just because the original web architecture didn't account for it?
Documents and other resources are content. It is about displaying content in a meaningful manner to the user.
If it is something that the browser can't render (word docs for example) you need to deal with that appropriately.
Sometimes a plain page with some links to download your files is more than sufficient. I used the old gmail lite version for years because it was faster and did most of the same things. If you gave that interface some nicer CSS most people probably couldn't tell that it was quite old (if done right).
> Why shouldn't we pursue that? Just because the original web architecture didn't account for it?
Generally the browser already knows how to deal with HTTP and the OS knows how to deal with documents you download (if it has the right programs installed). So I think generally things just end up better when you try to keep as things were intended to be built.
I do however have the attitude of "the water takes the shape of the container" attitude to development. Whereas others don't.
Amen. I feel like no one remembers the days of Mapquest where you'd click "next tile" and then watch the page reload just to scroll a few miles north, then repeat.
Google Maps is definitely a great example. I chose Gmail as my example, because from what I've read, that's where XHR was born, which is what I view as the birth of web apps. It's the idea that you don't have to pull an entirely new document from a server to update a small part of the view. I think that transforms the web from a simple document transfer system into something capable of behaving like an application.
>Says who? I understand that the underlying structures of the web are all about transferring documents and other resources. But Gmail showed us that web 'apps' are useful.
I have always thought Gmail wasn't really an App, and shouldn't / doesn't need to be an App. There are lots of so called Apps are nothing more than some documents with some interactivity. But people start using Javascript for everything. I hope Hey.com will prove this soon.
Everyone who isn't only on the web to try to make money. That's who. But all you for-profit types are runining it. As the browser becomes more powerful it is more important to secure it. As security becomes more important features are removed and the browser begins telling the user what they can and cannot do. And on the webmaster side it becomes infeasible for browsers to display your site or search engines to index it unless you depend upon the leased whim of third parties to get your centralized authority signed SSL cert.
As someone who loves the internet largely due to all the cool things people have made for profit, I can’t imagine how they for profit people have hurt the internet more than they have helped it.
You and I wouldn’t be talking right now if it weren’t for a company making hacker news for profit.
That's not true we would be talking on something else.
In fact, the forums of yore were much better communities than places like Hacker News. And sadly Hacker News is probably one of the better communities on the internet today.
Ditto. Intrusion of for-profit entities into online communities have well and truly killed the spirit. I base that on the fact that being exposed on any online destination where people congregate these days such as, Twitter, Reddit, hacker news, Facebook, for even a few minutes a day results in me feeling tired, demotivated, sluggish, angry, confused and just generally down. This is in stark opposition to how hanging around in communities of yester year felt. Further, I'm 27 so it's not like I'm some old veteran that yearns for the 90s or something but the quality has palpably gone down year after year. Sure there are small enclaves within these behemoths that somewhat manage to preserve a pleasant community but they're increasingly hard to find and only a matter of time before they too lose that magic to effects of profit driven actions.
Welp, on we go to the next post to read opinions of a nauseatingly self-assured tech nerd, who makes an above average living, declare everyone beneath as failed experiments of nature based on supreme principles of the free market..
> I can’t imagine how they for profit people have hurt the internet more than they have helped it.
By turning the Internet into what is first and foremost an ad delivery system. Everything else stems first from the need to show people ads, track their online movements and ensure they are spending as much time as possible "engaging" with your "brand".
Why is it slower than ever to load a page with text and images? It's because of the invisible fatberg of ad networks, A/B testing scripts, heatmaps and analytics trackers sending and receiving requests, all of which have zilch to do with actually sending a page from the server to the client.
"All the cool things made for profit" includes the real-time bid matching system without which websites like Youtube wouldn't exist, because it wouldn't be worth the
expense to Google or to some other megacorp.
Ha. Who says you shouldn't try to make money on the web? This is a deeper argument about capitalism and exploitation of resources. Practically speaking, capitalism will always find ways to make profit from exploitable resources. If you don't like that, you have to change society.
I'm fine with that. I'm not fine with browser and HTML/etc spec being defined by for profit entities now that the w3c has been marginalized. And I'm not fine with the changes they are requiring.
Update: OK, OK. I'm getting a lot of responses saying that Gmail is a bad example to use, because it's slow and bloated. I've responded to a few of those comments, but I think it should be addressed on a higher level.
To clarify, I said "Gmail showed us", because from what I've read, the early Beta releases are where XHR was born, which is what I view as the birth of web apps. It's the idea that you don't have to pull an entirely new document from a server to update a small part of the view, which translates into a more seamless experience typical of native apps. I think that transforms the web from a simple document transfer system into something capable of behaving like an application.
I think the explosion of JS frameworks since then are about how to effectively manage the use of XHR to update the view.
We are not going back full circle. We are facing new challenges and realizing how complex web development is.
1- There is no simple CSS start point; unless you don't want to be responsive, support mobile/tablets, add a print stylesheet. Then you have thousands of line. Time to add a pre-processor like Sass because CSS was not designed for such complex use cases.
2- There is no simple HTML either. Are you going to memorize how you coded that widget. Maybe use a framework (like bootstrap) to standardize things.
3- JS is not simple too; and the struggle is real. I remember coffeescript and then how EcmaScript 2015 tried to implement some of that nice stuff. Then you have TypeScript, because if your JavaScript is complex enough you might need stronger types.
4- Then you have JS/HTML/CSS; all of the three, interacting with your DOM.
5- Then you have JS interacting with your server; because who wants to reload the page multiple times. And there are different ways to do that too: Ajax, REST, WebSocket, GraphQl.
6- Now that things are getting too complicated, maybe add a build tool in the process (like Grunt) and a package manager too (npm). They might not be that good, so time to build new ones (gulp/webpack/yarn).
tl;dr: Developing for the Web is complicated. Any attempt to make it simple is going to add to the already complex ecosystem which brought us here in the first place.
Well, I completely disagree. Compared to developing sites 15-20 years ago, I think it's a walk in the park now. I feel like I can achieve far more with less code, the tools are more powerful, the code is easier to read, and there is much more consistency across browsers.
Did you want to make a box with rounded corners?
We can do that now... <div style="border-radius: 5px; border: 2px solid black;"></div>
It's intuitive and easy to understand. Try that 20 years ago. You're designing that in Photoshop, slicing up images for each corner, placing them into countless HTML table cells, messing around with all the table and cell heights, widths, paddings, margins, and borders, and struggling to get IE to render it correctly. That could have easily been an hour of work, and it would have resulted in a mess of images and inflexible code. Now, it's one line of code and 10 seconds of work. Did you want to fade the color of the border to red when the user hovers over the box? We can do that with two lines of CSS now. Good luck trying to achieve that in the past.
What do you mean thousands of lines for a responsive/mobile CSS layout, and no simple HTML?
There, it's a site with a header, footer, navigation, three columns, and it's responsive. 36 lines of CSS and 36 lines of HTML. Add 5-10 lines of CSS to reset spacing at the beginning, and that could literally be an entire responsive website.
The basics are easier yes, but the projects have become more complex. So yes, we can easily round corners instead of silly image slices, but like anything, making things easier just bumps up the expectations.
> because who wants to reload the page multiple times
happily, please, yes.
The browser caches pretty much everything but the HTML, so the payload is minimal. A fast SSR site is a dream compared to the myriad poorly implemented SPAs out there.
It's ridiculous going to, for example, an airline site; trying to book a flight and discovering that the damn reservation process is borked due to an uncaught exception in the latest update to the SPA (in which case the house of cards collapses, fun).
With an SSR the JS footprint is much smaller, which can lead to more stable/reliable apps.
I find the modern web to be a complete mess, but the loading spinners are nice, provided that the loading actually finishes (if it doesn't, look in the console and you'll likely find your answer in red).
>> because who wants to reload the page multiple times
> happily, please, yes.
A yes please from me, too. I like knowing, for a fact, that the input I gave your website made it to your server, your server processed it, and then I got back a response.
What I don't like is providing some data in a form, submitting it, being told, "Got it, buddy!", moving to another page on the site and then getting an error saying, "Acccctually something fell over. Sorry guy. Try again?"
This is something that I see espoused by "web traditionalists" for lack of a better term. Sure, there are a lot of web developers who are not optimising for performance but I think the difference is that it has simply shifted to the frontend where it's more noticeable.
The kinds of people who care about performance in the backend are exactly like the kinds of people who care about performance in the frontend. There's a variety of techniques that make sense in both areas to create a snappy, seamless experience. You need experienced engineers to create performance no matter what your domain is.
We've gone down the route of creating SPAs to largely replace experiences that would require desktop applications (it was only 5 years ago that I had to download an executable to do my tax return, now I do it with an SPA). Rather than create an SPA for a blog or a simple marketing site, we've largely replaced traditional "heavy"[0] infrastructure (PHP, Apache, MySQL just to display static content) with static JavaScript-generated sites. Many of these can simply be hosted on a CDN because they have no database and often no need for complex routing.
Pretending that SPAs were part of some dark ages is just silly. Horses for courses. If your application requires what I've dubbed "heavy" architecture (above) then by all means! Such infrastructure allows a high traffic service to be highly available, but is not required to serve a single .html file.
[0] When I say "heavy" I'm mainly talking about the attack surface and maintenance required. WordPress is great for serving a blog but has been the target of many hackers due to the amount of security vulnerabilities it has had over time.
SPAs being the darks ages is over-the-top, but being an SPA when other web architectures could better serve the user is a dark pattern. That tax app doesn't need to be an SPA. JavaScript powered interactions make the experience nicer for the user, but that doesn't mean it needs or is improved by being a single page.
I feel like Gmail has lost that edge. Email being a text medium should be fast, but Gmail using up many hundreds of megabytes of RAM and taking many seconds to load really feels like they've lost sight of what reading an email is about.
I too despise the "kitchen sink" approach seen in Gmail's UI where they are trying to cram every unwanted and unnecessary feature into your view and RAM at once.
If you used "Inbox for Gmail" before Google abandoned it and miss the much cleaner and focused UI, this Chrome extension upgrades Gmail to have the same styles:
No, it doesn't need to be, but it is nicer. There's quite a lot of complexities to my country's tax law (as with any country's tax law, really) and it's heavily simplified by giving you highly dynamic choices. Trying to use my country's immigration site, which has some JavaScript sprinkled on but is largely static, is a largely inferior experience.
There's no reason you can't query a backend for the complexities and present those dynamically to the user. For instance, quite often an SPA might ping the backend for a list of states or provinces once you've selected a country.
Sure. It's up to the engineer implementing said app to determine the best fit for the project.
At the end of the day, you have to choose what's right for your users; whether that's a seamless experience with no full page reloads, or the occasional full page reload.
"Single page" isn't the why it's the how. It enables you to take a JavaScript-first approach which in turn makes building complicated applications easier.
I mean... not really. I wouldn't invest in building client-side applications unless they bought me something. My customers don't really care, the majority don't even know what an SPA is. They do care that our application is faster and has more features than our competitors.
To word it more technically, building an SPA allows you to build applications as declarative composable functions which are deterministic, as opposed to the spaghetti code commonly seen in the days of jQuery and PHP which is harder to read, reason about, debug and maintain due to their imperative and nondeterministic nature.
> building an SPA allows you to build applications as declarative composable functions which are deterministic
How is that not the definition of a function or a method?
Deterministic in what sense? It’s output? It’s input?
Bad code exists on any language. Looks like you’re comparing bad code/coding practices to good ones, that’s another thing and completely irrelevant of the language.
> How is that not the definition of a function or a method?
It basically is and that's the point. With SPA's you generally structure it so your entire app is just a function. The same cannot be said of traditional server/client apps which consist of multiple moving parts (PHP backend / jQuery frontend) which do not have an explicit contract with each other, you're just taking shots in the dark hoping your jQuery selectors match up with what the PHP backend spits out.
> Deterministic in what sense? It’s output? It’s input?
What? There is only one sense in which something can be deterministic, which is given the same input you always receive the same output. PWAs are generally deterministic because they're just functions that take an input and give you back a DOM. Non-PWAs are non-deterministic because what you ultimately see can change depending on what generated HTML the server gives back, despite being given the same user-input, it can also change based on unrelated side-effects, for example, imagine you have some jQuery feature that resizes an element, and another one that changes it's background-color. The behaviour of both features are non-deterministic because the outcome of each depends on implicit state accumulated externally by the other one.
> Bad code exists on any language. Looks like you’re comparing bad code/coding practices to good ones, that’s another thing and completely irrelevant of the language.
This has nothing to do with languages, it's about project architecture and programming paradigms. The classic webserver+jQuery type architecture is inherently imperative. Of course it can have little islands of functionally pure, declarative code, but the overall software architecture is still imperative.
In a nutshell, traditional non-PWA software cannot be written in a fully declarative paradigm due to their nature, every non-PWA app on the web is intrinsically a jungle of imperative code, making assumptions about accumulated state. PWA's are generally written declaratively, where all state and dataflow is explicitly managed, and output is deterministic based on a given input.
> The same cannot be said of traditional server/client apps which consist of multiple moving parts (PHP backend / jQuery frontend) which do not have an explicit contract with each other, you're just taking shots in the dark hoping your jQuery selectors match up with what the PHP backend spits out.
If you don’t know how your code will work, that’s an issue with the quality of the code.
> What? There is only one sense in which something can be deterministic, which is given the same input you always receive the same output.
Agreed.
> Non-PWAs are non-deterministic because what you ultimately see can change depending on what generated HTML the server gives back, despite being given the same user-input,
With a language like PHP, if you call a function twice with the same input, why would the function return 2 different outputs?
> it can also change based on unrelated side-effects, for example, imagine you have some jQuery feature that resizes an element, and another one that changes it's background-color. The behaviour of both features are non-deterministic because the outcome of each depends on implicit state accumulated externally by the other one.
If your application also does this, the only difference is that you’re not using jQuery for it.
The output of this is deterministic. Given jQuery works, the element will resize and change color.
> In a nutshell, traditional non-PWA software cannot be written in a fully declarative paradigm due to their nature, every non-PWA app on the web is intrinsically a jungle of imperative code, making assumptions about accumulated state. PWA's are generally written declaratively, where all state and dataflow is explicitly managed, and output is deterministic based on a given input.
The assumption here is that declarative is deterministic and anything else isn’t and that’s just not true.
Determinism isn’t a function of the language, structure or paradigm.
If something is deterministic is dependent on the algorithm it has.
> If you don’t know how your code will work, that’s an issue with the quality of the code.
No, it's a fundamental difference between declarative and imperative programming. With imperative programming (e.g. PHP + jQuery) you cannot know what's in the DOM resulting from PHP-generated HTML you are working with, you need to either make naive assumptions about the DOM or litter your code with conditions checking the state of the DOM before operating on it. With declarative programming you declare the structure you want, so you know exactly what you have, because it's what you've declared. There's no need to check that the PHP backend rendered some element to the DOM to enhance with JS functionality, because I already declared that element is in the DOM in my JS directly.
> With a language like PHP, if you call a function twice with the same input, why would the function return 2 different outputs?
Again, this has nothing to do with languages and is purely about programming paradigms. What you're referring to is one of the possible "islands of functionally pure, declarative code" I previously mentioned. Pure functions in PHP can be deterministic, and pure functions in JS can be deterministic, but the overall application behaviour of how your front-end (jQuery) handles the output of your back-end (PHP) results in the application being non-deterministic. For example, say you have some form that submits data and on the posted page, displays a green thankyou message in a div. Say you want to animate this div message with jQuery. You cannot safely make any assumptions about the presence or prior presentation of the div, because from the context of jQuery you don't even know if the form has been submitted and the div rendered by PHP. You need to either:
- Imperatively check the current state of anything you wish to change prior to changing it.
- Naively make assumptions about prior state resulting in non-deterministic behaviour.
jQuery makes this easier by solving that problem on node "existence" with their selector-based API which simply doesn't run your function if the targeted nodes aren't found, but the problem still remains for general state, any jQuery code needs to either explicitly check the state of everything it touches (brittle code, hard to reason about and maintain) or make naive assumptions and be non-deterministic (which seems to have been the norm).
> The output of this is deterministic. Given jQuery works, the element will resize and change color.
False, it is non-deterministic because the ultimate outcome (what you see) depends on implicit state from side effects. For example if you toggle the resize control, the resulting display is based not only on your action (input) but also whether the colour change button was already pressed (an unrelated side-effect not a concern of the logic for resizing), or if PHP initially rendered it in a different size/colour, or maybe PHP decided to not render it at all because the user's session ended? From the context of jQuery you can't determine any of this, the only way you could come close to deterministic behaviour is by explicitly checking every single bit of stateful DOM before working on them, which I've never seen done in a large project (and would be hell to maintain).
> If something is deterministic is dependent on the algorithm it has.
Yes and any algorithm which has its outcome impacted by side-effects or unmanaged state (i.e. pre-rendered HTML/DOM from PHP, changes to DOM from other side-effect causing callbacks) is inherently non-deterministic. For an algorithm to be deterministic it needs to take every single thing that could affect it's outcome into consideration as input, and I have yet to see any jQuery apps which parse the entire DOM and use it as input to achieve deterministic behaviour
> The assumption here is that declarative is deterministic and anything else isn’t and that’s just not true....
Well, I'd argue that old fashioned PHP sites are structurally really similar to modern declarative client-side UIs, in that in both cases your're basically just constructing a series of functions that (deterministically) convert the current state to HTML.
Client-side rendering without declarative framework (say jQuery or vanilla) is different, in that you also need to consider state transition. This gets complicated fast.
And of course, the trade-off between the old fashioned approach and modern declarative revolves around how much interactivity is required.
If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously!
Yeah fair call and it's more the combination of PHP + jQuery I'm referring to as being non-deterministic rather than either on their own - you can definitely write deterministic PHP and jQuery code, but the implicit integration between them (PHP rendering HTML which becomes a DOM which jQuery imperatively operates on) is what I'm saying makes it non-deterministic. I'm mostly talking about the part you mentioned in managing client-side state using a non-declarative paradigm, where you either end up with a stupid amount of unnecessary complexity (conditions checking the prior state of literally any and everything you touch, I've never really seen this in a production project) or making naive assumptions about the DOM which means non-deterministic and potentially unexpected behaviour.
> If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously!
Fair point but there's also a flip-side to this though. You can write a client-side PWA with all your async state and data persistence magically handled by a service like Firebase Cloud Firestore, so just writing the UI declaratively and not having to worry at all about servers or databases, which generally requires a lot more upfront planning (figuring out models/schemas to represent your data, service architecture etc) than just slapping a UI together and wiring inputs up to a production-ready persistence layer API in front of a schemaless NoSQL DB like Firebase.
SPA gives you all the state stored client side, backend can be reduced to simple stateless functions. Anything persisted longer goes in the DB, and plenty of solutions exist that automatically keep the client side view of the DB and the backend in sync automatically, even across temporary loss of connectivity.
Compared to the bad days of server side session management, SPAs are far simpler to code and to reason about.
The elimination of the back and forth between client and backend means far less testing, and far simpler testing.
It is also arguably more efficient. Yes it uses more resources on the client compared to doing everything server side, but cpu and memory needs to be used no matter what. Treating web browsers as dumb terminals when the cheapest smartphone is at least quad core is a bit silly.
That said, there isn't any excuse for bad client side code that murders CPUs, but not using the client for anything but JPEG decoding doesn't make much sense!
If it's a web-based user interface as this tax app sounds to be, it is arguably improved purely by being an SPA. Requiring full page reloads just to submit or change some tiny bit of data in a page is objectively bad UX.
Mostly I want my forms to be reliable, that doesn't seem to be the case for many SPA's. Getting a blank page is a very common experience and much worse than a barely discernible delay submitting a form.
A problem is, that I need to fiddle around with JS blocking, even on official websites from city, state or gov, because they hired inresponsible web devs or made inresponsible decisions to let Google and others track me on their website. So initially they will be blocked. As far as "experts" for SPA are concerned, they often do not even include a noscript tag, which means I see a white page. Now it cannot become less user friendly than that. I've yet to see a SPA, which offers a working alternative via noscript tag, when I blocked all their tracking.
The thing is that SPA all too often serves as a way to force tracking onto the unsuspecting user. "You need to allow our JS! Your browser is outdated! Use Chrome!" and the unsophisticated person will think: "Oh well, lets just whitelist this page dammit!"
What in JavaScript are you using to take the place of a server side database?
Your comment seems to imply that the only options are SPA or WordPress..
If you are building something that would normally need to be a desktop app, sure, an SPA might be a good idea. But this is still rarely the case, most web pages are just are just presenting data, and in those cases, the less JavaScript the better.
Are you aware of any open source applications as a CMC for static generators like Jekyll? Would be very convenient to have one with a a simple github login/auth settings page and then add/edit page/post options and the ability to select or upload a theme would be great.
Yup, exactly that. WordPress editors (WYSIWYG and Gutenberg) are still far more user-friendly and mature than a Netlify CMS that still is buggy like hell and where many little details and YAML formattings need to be fixed in code editor. You really cannot expect such a thing to be done by a non-coding person.
A huge variety of plugins, and a large pool of cheap developers with plenty of experience in the stack. I personally like Jenkins, but if I’m handing the site over to a low-tech client, I’d use WordPress hosted on managed WordPress.
>You need experienced engineers to create performance no >matter what your domain is.
Actually the funny thing with HTML is that the simplest things are fast. If you just write a old school HTML web page without a bazillion frame works and not going too heavy on graphics things are usually fast.
And doing that is literally so much simpler and easier than learning all the super complicated frameworks of the day.
So it's a progression from initially fast for simple, to slower and slower as people learn the complicated (and slow) frameworks, and then eventually maybe fast again if you have an expert who can make all this mess fast again.
Most people never reach that expert stage of course, but sadly still leave the "easy and fast" stage.
This perspective is reasonable, until you start applying it to highly interactive / dynamic GUIs.
Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience.
Another example: any page that displays a row/table of data that the user wants to sort (frontend libraries make sorting instantaneous, compared to full page refreshes with html-only).
There are lots of people using complicated frontend frameworks in cases where pure html from the server would obviously be better. But it’s difficult to argue all libraries are bad and slow for every application.
Yeah if you actually want to sort datasets of any meaningful size, you’ll be making requests to return database results anyway since a database is going to be infinitely faster and more comprehensive than any client side solution.
> Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience.
The retro approach is to have two frames. One to submit, one to slow-stream a bunch of html elements which we can thankfully now lay out via flexboxes which are highly efficient when it comes to relayout, i.e. only the appended elements would incur some runtime costs, the already rendered ones don't get recomputed.
I have seen chan-style imageboards that update posts as people type (every dozen milliseconds) with 10k posts in a thread. The layout recomputation overhead is really low.
> Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience.
I can’t recall the last time any website offered me an acceptable embedded chat experience (not counting dedicated clients like Discord) so that’s all for the better.
Server side rendering is not really that slow, and SPA is not really that fast if your bundle size is huge.
More important is that most users will not able to distinguish the difference. I have asked my friends how they feel to compare Facebook to a traditional MVC web site in term of speed difference, none of them can feel the difference.
However, the transition from page to page do affect the user experience. As a user, when I want to do a task that involve many UIs and I need to click multiple pages, I will think it is a bad experience, but I do accept to switch to another page for another task. Therefore, It makes sense to have a SPA for some rich UI feature so that user can remain in the same page
The Wild Wild West!!?
I remember doing jquery/ajax calling an API and while it was easy to churn out spaghetti or long js file code, it was still easier to read and pick up a few years later.
The really cool kids are just using something like Jekyll that does all the templating at publish time and you just have static files you dump onto a server.
We've been building Levels.fyi as a static website for the past 3 years! To create a new page, we simply hit new file on our text editor and start to fill the page. We have a simple build system + templating with Gulp and Nunjucks, but its really all we need.
Scaling a static site is incredibly nice & cheap too :P
> Scaling a static site is incredibly nice & cheap too :P
And secure. The only back end systems to attack are load balancers and web servers -- if you're self hosting those then just make the file systems read-only and now you're talking seriously tough security barriers between you and an attacker.
> But the web is about presenting content first and foremost
This is where the article started going wrong. I don't care about the web -- it's a tool for me to do my job. I use the web because it's a much better alternative to shipping a Swing app. I don't care what the web is "about" and neither do my clients.
Also I do think it's funny the JAM stack he's referencing is just the jQuery stack of 5-10 years ago.
Hell, I still write the HTML and push it to Github where Github Pages and Cloudflare put it up on the Web for me. I've never seen any reason to use Markup when I can just Mark my text Up in HTML pretty simply. If you write a site correctly (a site, not a webapp) it'll render in anything from the original Netscape to the Wii Browser (tested working with my site), Internet Explorer 8 (working), Links2 (working), and the latest Chrome.
A site like YouTube doesn't need to work with old stuff like Netscape or IE but if your site primarily focuses on text there's next to no reason there should be Javascript on your site. Sites like danluu's[0] and Michael Norman Williams'[1] may not look the best but they just work.
If I recall, Netscape or one of the other early browsers used to have an option to change the default font/color of text and the background in its settings. Nowadays you have to use an extension to do so.
> Hell, I still write the HTML and push it to Github where Github Pages and Cloudflare put it up on the Web for me. I've never seen any reason to use Markup when I can just Mark my text Up in HTML pretty simply.
This sounds like you're making everything more difficult for yourself with little to no gain whatsoever.
With Markup or Markdown, you're still writing that HTML, but you're writing it once and then using automation and data structures to abstract it away. After that's implemented, and it's already been done for you (Hugo, MkDocs, ...), you're just writing the actual content and using simple syntax to format it. Everything else is then handled for you.
> (though admittedly I don't spend as much time on it as I should)
It's pretty much just a howto and link repository for myself and my friends right now. Still mostly a work in progress. Consider it as an example for look rather than for function.
I think we just all have to agree that plugging a complex, dynamic component into a web site should be done with care and attention to the details.
If you need to offer some dynamic element to your website, such as a form that does validation, then just add a form that does validation with the most minimal of code, bloat and everything else.
I’m by no stretch of the imagination a modern web developer. I know plain JS well, HTML and enough CSS/Bootstrap to throw together an internal website.
Even then most of my experience is with server side rendering.
However, for any large project, I would much rather be forced into using a modern framework than not. Any web app that is large enough is going to have some type of bespoke framework that was created by the “architect” who has been there forever.
It’s just like dealing with a bespoke ORM, logging, or authentication/authorization framework.
Plus shifting processing from backend servers to end user browsers can be a huge plus of you have a decent amount of visitors. Also, just simply pushing my code S3 is so much easier for me than building a Docker image and putting it into a container orchestrator.
312 comments
[ 3.0 ms ] story [ 258 ms ] threadWhen sites finally ditched their trendy Flash rewrites and went back to HTML, I thought, thank God.
That people use Javascript in places they aren't forced to use Javascript should make you wonder what the upsides are for them instead of assuming they cannot form any valid preferences of their own, unlike yourself.
For example, Javascript is one of the few languages that actually delivers on "async everything" and has a very simple Promise abstraction (like Promise.all()), and that makes it better for me than building networked services in similar languages (PHP, Python, Ruby). It's also one of the few dynamically-typed languages with a bolt-on static type system that actually gained traction.
You might not care about these things somehow, like maybe you only write C and Python because you work with embedded systems. But I think it's time to stop calling it garbage in honest conversation.
I've come to enjoy Node.js more than I thought I ever would, but it's still not something that's ever mindblowing to me, and I don't think that switching to Python would be a huge burden. With sensible tooling and contracts, neither would switching to a statically typed backend.
Let async code surrender control, but don't continue executing the current logic unless the developer asks for that behavior. Await-like behavior by default. That would have been much saner, less bug-prone, more helpful, and easier to learn & reason about. It's the desired behavior at least 90% of the time, in my experience.
Something needs to be done to encourage some efficiencies given the fact it takes more resources to surf the internet and read about running a k8s cluster than it does to actually run the cluster
There are mechanisms to charge for it.
Only above a certain price point. Our financial system nor our consumer culture support micropayments yet. This effectively limits the web properties that can charge users to a small fraction, so unfortunately "just charge money" isn't the widely-available solution I wish it was yet.
Hell, it's more viable to charge users for your mobile client than the backing service. It's kind of the closest we have to micropayments in a way.
Why should I subsidize your failed model ?
Who should pay for the assembly of the stuff ?
Would you put it together for free just to decide ?
Who pays for the used resources ?
Netflix, Prime Video etc etc
Hacker News is a better example. It's generated entirely server-side. Why not pay YCombinator a few cents for every page load?
There is more JS being processed, but that JS is smartly split up, bundled and takes care of loading just the content you need on subsequent browsing.
So the gains are:
- less data sent over the wire overall
- faster page loads overall initially and especially on subsequent loads.
- on subsequent loads only parts of the DOM are being rendered, not the whole thing so in some cases it might save you processing power
- no round trips to a DB and template engine, this is mostly a pro for the provider of the content
- some sites with this pattern enable you to download the whole thing as a PWA, so you can look at it offline with a single download.
People thought I was wrong and insane. I wish I was. Realistic assessments are always less popular than hope and principles. Flash was the good times.
It’s super cool that we built wildly complicated apps out of what was in spirit an FTP client with a PDF reader but it makes since that we have to hack the document retrieval system less now that the client can run code.
Maybe one day we’ll stop hacking on the document store’s limited RPC-ish protocol too.
I dipped out of web dev in 2015 to run an ecommerce project. I stopped tracking all the latest js framework news. I settled on a barebones CSS rule set. I stopped choosing SPAs as the starting point for mvp ideas. I shelved Wordpress and moved some content sites over to Netlify and just recently started using a nifty desktop ssr cms instead of Hugo, Gatsby, etc.
I was regressing to the environment I understood in the early 2000s-2010s. I did all of this because I knew there would be a steep learning curve going into modern ecommerce and it seemed reasonable to put everything into hibernation while I attempted to go all-in.
I pretty much missed the entire React, Angular, Vue ramp up in the industry.
I've since shut down that ecommerce project and find myself peeking back to the js-verse every now and then.
I doubt I'll ever voluntarily use one of those frameworks for web dev.
I do, however, like this thing called, Svelte.
What are you using?
> I do, however, like this thing called, Svelte.
Svelte is just another one of “those frameworks”, except with a vastly smaller community: https://trends.google.com/trends/explore?geo=US&q=svelte%20i...
For example, what happened to CoffeeScript? https://trends.google.com/trends/explore?q=%2Fm%2F0hjc5m0&ge...
What happened to Ember? https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0s8...
JS technology changes quickly not for its own sake, but because there are still discoveries to be made about how to improve both syntax and how we think about code. I'm sure the pace will taper off sooner or later, until the Web is taken over by something else.
About the only negatives I can bring up are IDE (and other sorts of vendor tools/components) support/integration is not as good as more popular frameworks like React, but that’s really just to be expected as vendors tend to target based on popularity.
Two reasons why
1) Some CoffeeScript features, like arrow functions and classes, made it into ES6. 2) CoffeeScript was never updated to properly generate ES6. Largely because the features that got adopted by ES6 had subtle differences that made the migration path for existing projects highly complex.
I think, to a lesser extend, the rise of TypeScript also had something to do with it.
Hacker News is the epicenter of software engineer hipsterdom, come on.
With react memoization and pure components, you get very similar benefits.
Sure svelte goes the extra step and removes unnecessary diffing of constant attributes that will never change and other opts. However there are tradeoffs
I've had a great experience with it recently developing a smart tv app - which are dog slow even with a quad core ARM CPU due to the resolution so I decided to learn Svelte for the project. The big downside is another templating language to learn and as you said, the community is tiny, but the surface area is small enough that it hasn't been a problem regarding tooling or debugging. Pulling in other frameworks into a svelte app is also relatively easy so it can be part of a slow incremental rewrite, although as always it devolves into a webpack/rollup config mess.
Same could be said of React though. React components are literally just plain JavaScript functions which return VDOM nodes that get diffed and applied to the DOM by the runtime library.
The only objective advantage I see to Svelte is it's tiny footprint, which if you really need you can already get by using Preact (3kb vs Svelte's 3.5kb) without having to learn yet-another-completely-arbitrary-templating-language to no benefit.
"[Svelte is a] compiler that knows at build time how things could change in your app, rather than waiting to do the work at run time"
My point being there is a large amount of compile time code transformation at build time. The run time is not so much a framework as a library like libc. In Svelte when you update state there is no virtual dom, dom diffing, fibers, or anything. It would have been compiled into a direct dom update of anything depending on it. It's no longer a Svelte app just vanillajs. There are some details or course but it's a different paradigm than to react or other modern UI frameworks.
Data attributes store data in the page and add dynamic features (like CRUD functionality and drag and drop sorting) very easily.
Plus, the whole thing is server rendered with Handlebars, so the front-end JS part isn't even required for 95% of visitors (it's only necessary if you're an admin who can edit the current page).
I wrote it because I missed the simple days of jQuery and REST APIs.
[0] https://remaketheweb.com/
There's also a built-in CLI that can deploy to our free hosting service, which is built on top of Digital Ocean.
What hardware are you running?
So much culture, especially in gaming, will be inevitably lost with the SaaS and streaming trend. For media like video, music and books at least many national library laws require the deposit of two or more copies at the national archives, but interactive media? Games that require online activation? That's all gonna be lost forever.
If you are building a web app, use React or similar.
If you are building a web site, use plain HTML+CSS w/ supplemental JS.
Sometimes your project can be split in half. Do the landing page, signup, login, privacy policy, etc. in plain HTML.
Maybe don't embed all that stuff in your app and you wouldn't struggle with forms and routing, something that browsers can do very well with no programming.
I'm used to the downvotes on here unfortunately, it's easy to tell which topics will do it, the group think here can be thick...
My struggle on HN is to try to ignore the groupthink and keep the sarcasm out of my tone, but sometimes I just can't help myself.
I disagree with this, there's no reason to use React/Vue/Angular for a web app by default. And I would urge people to try and avoid it for as long as possible and see how far you get. From personal experience I can tell you that most of the time, you don't need a frontend framework to build a web app.
I urge people to practice and use the best tool for the job, don't avoid something because some hipster thinks it's too popular.
Feel free to go back to jQuery spaghetti code, it's nice until you build something too big.
React isn't a framework btw, it's just the view. You can stack anything or nothing with it.
"The wheel of reincarnation" from client to server and back: http://www.cap-lore.com/Hardware/Wheel.html
I was recently considering that we went through this cultural shift with computing: we started out by having a system to run code onvdistributed to terminals, then to actual desktop computers, then back to remote with the cloud, and now pushing out to "edge" computing. I'm sure it's more nuanced than that, but we seem to do these cycles, refining our processes.
Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- in the browser. And hey, if you use a lot of the same logic and data models in the browser as you do on the back-end server, it's only natural to want to try to centralize the code. DRY. The problem is basically what @s_y_n_t_a_x said: developers got carried away with it and starting using SPAs for everything, including sites with low interactivity like blogs, which turned out to be less performant.
> But the web is about presenting content first and foremost!
Says who? I understand that the underlying structures of the web are all about transferring documents and other resources. But Gmail showed us that web 'apps' are useful. Why shouldn't we pursue that? Just because the original web architecture didn't account for it?
In the end, the article makes the right point: Use the right technology for what you're trying to build.
And we really have come full circle. Gmail performance, at least on Firefox, is awful.
You either have graphics hardware support disabled or youre laptop CPU is not running in perfoance mode and has its govenor set to something like balanced or power saving mode.
I don't have this issue with other sites, it's just Gmail being Gmail.
Gmail is terrible. It's slow and most people prefer the static html version.
If anyone from FastMail is reading this - do not change your design or UI framework...like ever. The moment you start slowing things down with animations and bloat, that's a slippery slope...
What's unintuitive about a list of emails and few simple features? You also bog my mind :)
It also doesn't have proper mailboxes, and rules are impossible to make.
I do not like it at all.
I don't understand how you can say "its rules are great" when I can't have two different message subjects go to the same mailbox.
The only people I've ever heard talk about the static html version are a few HNers. I'd wager 99% of people don't care, don't mind their email client's first load being slow (they just keep it open in a tab anyways), and don't even know about the static html version.
Are you claiming that because people are ignorant of an option that is clearly better for them, the option is redundant? So if people don't care about something, it's not better by definition of that fact?
You watch people as they use Gmail? You actively ask them?
I guess if YOU haven't seen anyone do it, no one must be doing it.
Can you substantiate this with more than just your personal experience? This doesn't match my experience outside of the HN bubble.
Gawd.. now that's terrible.
But yeah... I don't agree Gmail is terrible, but I'd like it to be better.
Ive been on a few months after it launched, and got a service that's been reliable and stable for that long, I have to give it a lot of credit!
Yep .. so if you want a rich responsive user experience, DON'T use any web technologies. GMail (AND Gsuite) is a perfect example of how a relatively simple concept like email can be turned into a slow, unresponsive piece of garbage.
PS4 feels like they've taken webtech all over the OS interface. Its store's snappier than the 3 but the rest of the interface performs way worse. Usable, but far less pleasant.
[EDIT] store should be snappier than the 3, mind, since it's way more powerful hardware—it's still kinda slow, considering.
STBs, Smart TVs, IFE systems are or were web based.
One of the main drivers for getting a amazon fire stick is that it is much more responsive than the Smart TV itself.
How do you think that would have worked for Gmail's success?
GMail is a poorly built app, that's all. There are plenty of great examples. Both Outlook and Fastmail have fast and feature-rich email clients. Gmail was good back in the day and got carried away by project managers and feature creep.
Meanwhile Google Docs continues to be a pinnacle of what you can achieve on the web.
Probably because that RAM wasn't doing anything else. Why not use it as cache to speed things up. I'm sure it can work fine in much smaller RAM sizes.
And that doesn't explain how the "cache" is twenty times bigger than the source data.
I bet with less RAM available it would start thrashing.
Reality has rtt and shitty 2G slow, and will drive people away from your web product if you are too silly to cache things locally.
Also I find most performance issues with big apps are a result of browser extensions that interfere. Try using a private window without any extensions.
(1): burning through an SSD's limited number of write cycles OR being at least an order of magnitude slower to access in the case of HDDs
Bloat RAM is also wasted RAM. If it's not being used as a cache of reasonable size, or in a time/speed tradeoff, all you're doing is making things worse.
> If you don't have anything else that needs it then just let your system automatically handle it.
That's a statement that only really applies to people misunderstanding RAM used by the page cache or suspended programs. And both of those depend on active applications not allocating that memory!
Says the OS developer, says the browser developer, says the webapp developer, says the developer of whatever else you have running. Developer time is expensive. Says one. Look it runs fine and is snappy. Says another on his maxed out development pc forgetting about his grandma. Why should i care about that extra memory load when most pc's nowadays have x amount. Says yet another.
And so the slugfest continues.
>Also I find most performance issues with big apps are a result of browser extensions that interfere. Try using a private window without any extensions.
Browser extensions can definitely make a browser sluggish but most don't interfere with the content. The only ones that do AND are common are adblockers which have a tendency of making it less sluggish.
Why are they consistently slower than especially when there is low bandwidth or bad reception (lost packets)? Your large JS script has to be downloaded and parsed by the browser. This is fine when you have high bandwidth and low package loss. But if the opposite is true that initial hit to get all your JS code can be really painful. Writing really fast JS is hard and is not normally something that can be done in a framework. I know React is better than things like Angular, but there is nothing faster than vanilla JS.
I write a lot of pure JS and I write stuff to be very fast. However it requires more effort and a higher skill bar (to the point where I am weaker at server side development and terrible with databases).
A lot of SPAs can be replaced with with a post back mechanism and some caching of assets (CSS etc) and a sprinkling of Ajax. The less you have to download, parse etc can really make things less painful when you are in that situation.
The problem is that many developers don't bother to learn JavaScript properly so unless you give them a framework like Angular or similar you end up with the jQuery spagetti of the past.
> Says who? I understand that the underlying structures of the web are all about transferring documents and other resources. But Gmail showed us that web 'apps' are useful. Why shouldn't we pursue that? Just because the original web architecture didn't account for it?
Documents and other resources are content. It is about displaying content in a meaningful manner to the user.
If it is something that the browser can't render (word docs for example) you need to deal with that appropriately.
Sometimes a plain page with some links to download your files is more than sufficient. I used the old gmail lite version for years because it was faster and did most of the same things. If you gave that interface some nicer CSS most people probably couldn't tell that it was quite old (if done right).
> Why shouldn't we pursue that? Just because the original web architecture didn't account for it?
Generally the browser already knows how to deal with HTTP and the OS knows how to deal with documents you download (if it has the right programs installed). So I think generally things just end up better when you try to keep as things were intended to be built.
I do however have the attitude of "the water takes the shape of the container" attitude to development. Whereas others don't.
I have always thought Gmail wasn't really an App, and shouldn't / doesn't need to be an App. There are lots of so called Apps are nothing more than some documents with some interactivity. But people start using Javascript for everything. I hope Hey.com will prove this soon.
Everyone who isn't only on the web to try to make money. That's who. But all you for-profit types are runining it. As the browser becomes more powerful it is more important to secure it. As security becomes more important features are removed and the browser begins telling the user what they can and cannot do. And on the webmaster side it becomes infeasible for browsers to display your site or search engines to index it unless you depend upon the leased whim of third parties to get your centralized authority signed SSL cert.
As someone who loves the internet largely due to all the cool things people have made for profit, I can’t imagine how they for profit people have hurt the internet more than they have helped it.
You and I wouldn’t be talking right now if it weren’t for a company making hacker news for profit.
In fact, the forums of yore were much better communities than places like Hacker News. And sadly Hacker News is probably one of the better communities on the internet today.
Welp, on we go to the next post to read opinions of a nauseatingly self-assured tech nerd, who makes an above average living, declare everyone beneath as failed experiments of nature based on supreme principles of the free market..
By turning the Internet into what is first and foremost an ad delivery system. Everything else stems first from the need to show people ads, track their online movements and ensure they are spending as much time as possible "engaging" with your "brand".
Why is it slower than ever to load a page with text and images? It's because of the invisible fatberg of ad networks, A/B testing scripts, heatmaps and analytics trackers sending and receiving requests, all of which have zilch to do with actually sending a page from the server to the client.
"All the cool things made for profit" includes the real-time bid matching system without which websites like Youtube wouldn't exist, because it wouldn't be worth the expense to Google or to some other megacorp.
To clarify, I said "Gmail showed us", because from what I've read, the early Beta releases are where XHR was born, which is what I view as the birth of web apps. It's the idea that you don't have to pull an entirely new document from a server to update a small part of the view, which translates into a more seamless experience typical of native apps. I think that transforms the web from a simple document transfer system into something capable of behaving like an application.
I think the explosion of JS frameworks since then are about how to effectively manage the use of XHR to update the view.
1- There is no simple CSS start point; unless you don't want to be responsive, support mobile/tablets, add a print stylesheet. Then you have thousands of line. Time to add a pre-processor like Sass because CSS was not designed for such complex use cases.
2- There is no simple HTML either. Are you going to memorize how you coded that widget. Maybe use a framework (like bootstrap) to standardize things.
3- JS is not simple too; and the struggle is real. I remember coffeescript and then how EcmaScript 2015 tried to implement some of that nice stuff. Then you have TypeScript, because if your JavaScript is complex enough you might need stronger types.
4- Then you have JS/HTML/CSS; all of the three, interacting with your DOM.
5- Then you have JS interacting with your server; because who wants to reload the page multiple times. And there are different ways to do that too: Ajax, REST, WebSocket, GraphQl.
6- Now that things are getting too complicated, maybe add a build tool in the process (like Grunt) and a package manager too (npm). They might not be that good, so time to build new ones (gulp/webpack/yarn).
tl;dr: Developing for the Web is complicated. Any attempt to make it simple is going to add to the already complex ecosystem which brought us here in the first place.
Did you want to make a box with rounded corners?
We can do that now... <div style="border-radius: 5px; border: 2px solid black;"></div>
It's intuitive and easy to understand. Try that 20 years ago. You're designing that in Photoshop, slicing up images for each corner, placing them into countless HTML table cells, messing around with all the table and cell heights, widths, paddings, margins, and borders, and struggling to get IE to render it correctly. That could have easily been an hour of work, and it would have resulted in a mess of images and inflexible code. Now, it's one line of code and 10 seconds of work. Did you want to fade the color of the border to red when the user hovers over the box? We can do that with two lines of CSS now. Good luck trying to achieve that in the past.
What do you mean thousands of lines for a responsive/mobile CSS layout, and no simple HTML?
https://www.w3schools.com/html/tryit.asp?filename=tryhtml_re...
There, it's a site with a header, footer, navigation, three columns, and it's responsive. 36 lines of CSS and 36 lines of HTML. Add 5-10 lines of CSS to reset spacing at the beginning, and that could literally be an entire responsive website.
happily, please, yes.
The browser caches pretty much everything but the HTML, so the payload is minimal. A fast SSR site is a dream compared to the myriad poorly implemented SPAs out there.
It's ridiculous going to, for example, an airline site; trying to book a flight and discovering that the damn reservation process is borked due to an uncaught exception in the latest update to the SPA (in which case the house of cards collapses, fun).
With an SSR the JS footprint is much smaller, which can lead to more stable/reliable apps.
I find the modern web to be a complete mess, but the loading spinners are nice, provided that the loading actually finishes (if it doesn't, look in the console and you'll likely find your answer in red).
> happily, please, yes.
A yes please from me, too. I like knowing, for a fact, that the input I gave your website made it to your server, your server processed it, and then I got back a response.
What I don't like is providing some data in a form, submitting it, being told, "Got it, buddy!", moving to another page on the site and then getting an error saying, "Acccctually something fell over. Sorry guy. Try again?"
Give me that slower but guaranteed feedback.
The kinds of people who care about performance in the backend are exactly like the kinds of people who care about performance in the frontend. There's a variety of techniques that make sense in both areas to create a snappy, seamless experience. You need experienced engineers to create performance no matter what your domain is.
We've gone down the route of creating SPAs to largely replace experiences that would require desktop applications (it was only 5 years ago that I had to download an executable to do my tax return, now I do it with an SPA). Rather than create an SPA for a blog or a simple marketing site, we've largely replaced traditional "heavy"[0] infrastructure (PHP, Apache, MySQL just to display static content) with static JavaScript-generated sites. Many of these can simply be hosted on a CDN because they have no database and often no need for complex routing.
Pretending that SPAs were part of some dark ages is just silly. Horses for courses. If your application requires what I've dubbed "heavy" architecture (above) then by all means! Such infrastructure allows a high traffic service to be highly available, but is not required to serve a single .html file.
[0] When I say "heavy" I'm mainly talking about the attack surface and maintenance required. WordPress is great for serving a blog but has been the target of many hackers due to the amount of security vulnerabilities it has had over time.
Email is a great example of this - GMail, at launch, had much better UX than existing server-rendered applications like Hotmail.
You can find bad UX everywhere - in SPAs and server-rendered interfaces alike - but there’s nothing implicit to SPAs that reduces usability.
If you used "Inbox for Gmail" before Google abandoned it and miss the much cleaner and focused UI, this Chrome extension upgrades Gmail to have the same styles:
https://chrome.google.com/webstore/detail/simplify-gmail/pbm...
At the end of the day, you have to choose what's right for your users; whether that's a seamless experience with no full page reloads, or the occasional full page reload.
Uh-huh...
> which in turn makes building complicated applications easier.
What? This is vacuous market-speak.
How is that not the definition of a function or a method?
Deterministic in what sense? It’s output? It’s input?
Bad code exists on any language. Looks like you’re comparing bad code/coding practices to good ones, that’s another thing and completely irrelevant of the language.
It basically is and that's the point. With SPA's you generally structure it so your entire app is just a function. The same cannot be said of traditional server/client apps which consist of multiple moving parts (PHP backend / jQuery frontend) which do not have an explicit contract with each other, you're just taking shots in the dark hoping your jQuery selectors match up with what the PHP backend spits out.
> Deterministic in what sense? It’s output? It’s input?
What? There is only one sense in which something can be deterministic, which is given the same input you always receive the same output. PWAs are generally deterministic because they're just functions that take an input and give you back a DOM. Non-PWAs are non-deterministic because what you ultimately see can change depending on what generated HTML the server gives back, despite being given the same user-input, it can also change based on unrelated side-effects, for example, imagine you have some jQuery feature that resizes an element, and another one that changes it's background-color. The behaviour of both features are non-deterministic because the outcome of each depends on implicit state accumulated externally by the other one.
> Bad code exists on any language. Looks like you’re comparing bad code/coding practices to good ones, that’s another thing and completely irrelevant of the language.
This has nothing to do with languages, it's about project architecture and programming paradigms. The classic webserver+jQuery type architecture is inherently imperative. Of course it can have little islands of functionally pure, declarative code, but the overall software architecture is still imperative.
In a nutshell, traditional non-PWA software cannot be written in a fully declarative paradigm due to their nature, every non-PWA app on the web is intrinsically a jungle of imperative code, making assumptions about accumulated state. PWA's are generally written declaratively, where all state and dataflow is explicitly managed, and output is deterministic based on a given input.
If you don’t know how your code will work, that’s an issue with the quality of the code.
> What? There is only one sense in which something can be deterministic, which is given the same input you always receive the same output.
Agreed.
> Non-PWAs are non-deterministic because what you ultimately see can change depending on what generated HTML the server gives back, despite being given the same user-input,
With a language like PHP, if you call a function twice with the same input, why would the function return 2 different outputs?
> it can also change based on unrelated side-effects, for example, imagine you have some jQuery feature that resizes an element, and another one that changes it's background-color. The behaviour of both features are non-deterministic because the outcome of each depends on implicit state accumulated externally by the other one.
If your application also does this, the only difference is that you’re not using jQuery for it.
The output of this is deterministic. Given jQuery works, the element will resize and change color.
> In a nutshell, traditional non-PWA software cannot be written in a fully declarative paradigm due to their nature, every non-PWA app on the web is intrinsically a jungle of imperative code, making assumptions about accumulated state. PWA's are generally written declaratively, where all state and dataflow is explicitly managed, and output is deterministic based on a given input.
The assumption here is that declarative is deterministic and anything else isn’t and that’s just not true.
Determinism isn’t a function of the language, structure or paradigm.
If something is deterministic is dependent on the algorithm it has.
No, it's a fundamental difference between declarative and imperative programming. With imperative programming (e.g. PHP + jQuery) you cannot know what's in the DOM resulting from PHP-generated HTML you are working with, you need to either make naive assumptions about the DOM or litter your code with conditions checking the state of the DOM before operating on it. With declarative programming you declare the structure you want, so you know exactly what you have, because it's what you've declared. There's no need to check that the PHP backend rendered some element to the DOM to enhance with JS functionality, because I already declared that element is in the DOM in my JS directly.
> With a language like PHP, if you call a function twice with the same input, why would the function return 2 different outputs?
Again, this has nothing to do with languages and is purely about programming paradigms. What you're referring to is one of the possible "islands of functionally pure, declarative code" I previously mentioned. Pure functions in PHP can be deterministic, and pure functions in JS can be deterministic, but the overall application behaviour of how your front-end (jQuery) handles the output of your back-end (PHP) results in the application being non-deterministic. For example, say you have some form that submits data and on the posted page, displays a green thankyou message in a div. Say you want to animate this div message with jQuery. You cannot safely make any assumptions about the presence or prior presentation of the div, because from the context of jQuery you don't even know if the form has been submitted and the div rendered by PHP. You need to either: - Imperatively check the current state of anything you wish to change prior to changing it. - Naively make assumptions about prior state resulting in non-deterministic behaviour.
jQuery makes this easier by solving that problem on node "existence" with their selector-based API which simply doesn't run your function if the targeted nodes aren't found, but the problem still remains for general state, any jQuery code needs to either explicitly check the state of everything it touches (brittle code, hard to reason about and maintain) or make naive assumptions and be non-deterministic (which seems to have been the norm).
> The output of this is deterministic. Given jQuery works, the element will resize and change color.
False, it is non-deterministic because the ultimate outcome (what you see) depends on implicit state from side effects. For example if you toggle the resize control, the resulting display is based not only on your action (input) but also whether the colour change button was already pressed (an unrelated side-effect not a concern of the logic for resizing), or if PHP initially rendered it in a different size/colour, or maybe PHP decided to not render it at all because the user's session ended? From the context of jQuery you can't determine any of this, the only way you could come close to deterministic behaviour is by explicitly checking every single bit of stateful DOM before working on them, which I've never seen done in a large project (and would be hell to maintain).
> If something is deterministic is dependent on the algorithm it has.
Yes and any algorithm which has its outcome impacted by side-effects or unmanaged state (i.e. pre-rendered HTML/DOM from PHP, changes to DOM from other side-effect causing callbacks) is inherently non-deterministic. For an algorithm to be deterministic it needs to take every single thing that could affect it's outcome into consideration as input, and I have yet to see any jQuery apps which parse the entire DOM and use it as input to achieve deterministic behaviour
> The assumption here is that declarative is deterministic and anything else isn’t and that’s just not true....
Literally every sentence is wrong.
Client-side rendering without declarative framework (say jQuery or vanilla) is different, in that you also need to consider state transition. This gets complicated fast.
And of course, the trade-off between the old fashioned approach and modern declarative revolves around how much interactivity is required.
If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously!
> If you can get away with it, I'd say the old fashioned approach takes less development time because you don't need to handle asynchronous (and possibly failing) state syncs. The database containing any state you might want to access is available synchronously!
Fair point but there's also a flip-side to this though. You can write a client-side PWA with all your async state and data persistence magically handled by a service like Firebase Cloud Firestore, so just writing the UI declaratively and not having to worry at all about servers or databases, which generally requires a lot more upfront planning (figuring out models/schemas to represent your data, service architecture etc) than just slapping a UI together and wiring inputs up to a production-ready persistence layer API in front of a schemaless NoSQL DB like Firebase.
Compared to the bad days of server side session management, SPAs are far simpler to code and to reason about.
The elimination of the back and forth between client and backend means far less testing, and far simpler testing.
It is also arguably more efficient. Yes it uses more resources on the client compared to doing everything server side, but cpu and memory needs to be used no matter what. Treating web browsers as dumb terminals when the cheapest smartphone is at least quad core is a bit silly.
That said, there isn't any excuse for bad client side code that murders CPUs, but not using the client for anything but JPEG decoding doesn't make much sense!
At least my SPA tax software makes the form filling a little more exciting, and doesn't s#!t the bed when I hit enter by accident
Your comment seems to imply that the only options are SPA or WordPress..
If you are building something that would normally need to be a desktop app, sure, an SPA might be a good idea. But this is still rarely the case, most web pages are just are just presenting data, and in those cases, the less JavaScript the better.
https://www.netlifycms.org/docs/jekyll/
Actually the funny thing with HTML is that the simplest things are fast. If you just write a old school HTML web page without a bazillion frame works and not going too heavy on graphics things are usually fast.
And doing that is literally so much simpler and easier than learning all the super complicated frameworks of the day.
So it's a progression from initially fast for simple, to slower and slower as people learn the complicated (and slow) frameworks, and then eventually maybe fast again if you have an expert who can make all this mess fast again.
Most people never reach that expert stage of course, but sadly still leave the "easy and fast" stage.
Real-time chat is the most obvious case where the html purist won’t offer an acceptable experience.
Another example: any page that displays a row/table of data that the user wants to sort (frontend libraries make sorting instantaneous, compared to full page refreshes with html-only).
There are lots of people using complicated frontend frameworks in cases where pure html from the server would obviously be better. But it’s difficult to argue all libraries are bad and slow for every application.
???
https://jsfiddle.net/r3u5yvk8/I'm now on their contact list.
The retro approach is to have two frames. One to submit, one to slow-stream a bunch of html elements which we can thankfully now lay out via flexboxes which are highly efficient when it comes to relayout, i.e. only the appended elements would incur some runtime costs, the already rendered ones don't get recomputed.
I have seen chan-style imageboards that update posts as people type (every dozen milliseconds) with 10k posts in a thread. The layout recomputation overhead is really low.
Slow-stream?
I can’t recall the last time any website offered me an acceptable embedded chat experience (not counting dedicated clients like Discord) so that’s all for the better.
More important is that most users will not able to distinguish the difference. I have asked my friends how they feel to compare Facebook to a traditional MVC web site in term of speed difference, none of them can feel the difference.
However, the transition from page to page do affect the user experience. As a user, when I want to do a task that involve many UIs and I need to click multiple pages, I will think it is a bad experience, but I do accept to switch to another page for another task. Therefore, It makes sense to have a SPA for some rich UI feature so that user can remain in the same page
Compared to what?
Scaling a static site is incredibly nice & cheap too :P
And secure. The only back end systems to attack are load balancers and web servers -- if you're self hosting those then just make the file systems read-only and now you're talking seriously tough security barriers between you and an attacker.
As simple and nice as static HTML is, it's inefficient. The reason we care about this now is mostly:
A) A lot of people just hate Javascript. And a lot of that hate is understandable. B) People still worry about the crawlability of their SPAs
JS has a lot of problems but it's also fixing some of these by growing really fast (paradoxically, also one of its problems).
Bots will get more comprehensively better at rendering client-side only apps.
This is where the article started going wrong. I don't care about the web -- it's a tool for me to do my job. I use the web because it's a much better alternative to shipping a Swing app. I don't care what the web is "about" and neither do my clients.
Also I do think it's funny the JAM stack he's referencing is just the jQuery stack of 5-10 years ago.
A site like YouTube doesn't need to work with old stuff like Netscape or IE but if your site primarily focuses on text there's next to no reason there should be Javascript on your site. Sites like danluu's[0] and Michael Norman Williams'[1] may not look the best but they just work.
My website: https://www.instantfloppy.net/ (though admittedly I don't spend as much time on it as I should)
[0]: https://danluu.com/
[1]: http://michaelnormanwilliams.com/
This sounds like you're making everything more difficult for yourself with little to no gain whatsoever.
With Markup or Markdown, you're still writing that HTML, but you're writing it once and then using automation and data structures to abstract it away. After that's implemented, and it's already been done for you (Hugo, MkDocs, ...), you're just writing the actual content and using simple syntax to format it. Everything else is then handled for you.
I wrote this recently: https://www.thecloud.coach/terraform/understanding-state/
If I had to write that from first principles, as you're doing above, I simply wouldn't have.
It's pretty much just a howto and link repository for myself and my friends right now. Still mostly a work in progress. Consider it as an example for look rather than for function.
If you need to offer some dynamic element to your website, such as a form that does validation, then just add a form that does validation with the most minimal of code, bloat and everything else.
Why is this hard?
Surely this just translates to user first ..? Devs moving from "it's about me" to "it's about you", perhaps with a bit of a shove from google, et al.
Even then most of my experience is with server side rendering.
However, for any large project, I would much rather be forced into using a modern framework than not. Any web app that is large enough is going to have some type of bespoke framework that was created by the “architect” who has been there forever.
It’s just like dealing with a bespoke ORM, logging, or authentication/authorization framework.