Websites have evolved back to static HTML/CSS/JS files
paramaggarwal.substack.com
paramaggarwal.substack.com
Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acquired the skill of successfully selecting the correct architecture for the project goals (even if it is _boring_ to actually work on).
Whereas, take the junior to mid developer streams. Every time there's an opportunity to learn something new and break the grind from doing [X] for the past [Y] months, there tends to be unwarranted justifcation on why "we should use this new thing" despite there already being a well-known and battle-tested solution sitting right there.
For example: We need to build a basic company website. Someone from reception needs to be able to update the contact form and trading hours around five times per year. Someone from marketing needs to update product brochures once a month.
Seasoned engineer: Let's use any well-tested CMS such as WordPress and install a caching front-end.
Junior - mid engineers: EW WordPress! Doesn't that use PHP? Hahaha. Hahaha. Why on earth would we want to be known for using _PHP_!?!? We'd be _far_ better to just create a front-end on react and then write a microservice that will allow our staff members to update content. If marketing says SEO is necessary, we can _simply_ add a server-side rendering layer for the react front-end and deploy it onto a second microservice. And to make sure it all works, we can subscribe to some monitoring services, write a full test suite and CI pipeline. Everyone can install monitoring on their phones so if it ever goes offline, someone can immediately sign in remotely and debug which micro service is broken.
With WordPress I don't worry about the PHP part, but for the tendency of people to bloat it by installing plugins and not updating it enough.
I mean how do you skip the "storing some sort of state in DB including a users table" step?
It is very typical for a small to medium business site client to want a minimal CMS and ability to add a few more users with edit rights.
With Netlify CMS it seems the build happens from a git repo so wouldn't it require for end user to learn git?
I love how fast and easy it is to publish static sites on Netlify but I do not see how one could host client sites on Netlify without requiring constant hand holding.
Content, copy, even menu items, metadata etc can be edited by multiple normal people. Translations too
A static site can be set up to rebuild when someone updates content.
You could also fetch content with JavaScript on the page. That would work if it was just opening hours as in the parent example
Regarding WordPress and plugins:
<?php define("DISALLOW_FILE_MODS", true);Tech is about automation. Php + mysql still serves well in this era. Wikipedia still runs on it and it’s a pretty fantastic and responsive site. So does Facebook to some degree I suppose.
Next dev will have easier time changing string in plain, straightforward code or static site generator than migrating plugins from PHP 5.3 or whatever.
>Tech is about automation.
Tech isn't about "automating" things that ultimately cause you to do more work to maintain status quo. Tech isn't about spending week to automate things that take you 1 minute three times a year.
I do agree that if you need plug ins, that appears to get messy very fast, but the default WordPress site does everything I want and requires very little for maintenance.
For example, I like Ghost (https://ghost.org/) for my personal needs.
Worst case I use a dedicated PHP page and MySQL. But in reality I think I usually put my code in functions.php(?) And it works fine.
More specifically, it isn't always up to the engineers:
> We need to build a basic company website.
Marketing is inherently trendy and the people designing the website, as in dictating what it needs to do and look like, are the marketers, who are influenced by the "cool" websites they've seen. Marketers follow trends. It isn't really negotiable in that profession. The engineers do their best to deliver on what marketing wants, and if that requires a WASM re-implementation of NyanCat to prove that we're retro-hip and DownToFax, so be it.
Pretty sure that’s not the case anymore, I have been a developer for 3 years and have never ever seen anyone use either of these for work
Really the problem is that the standard solution hasn't improved. Backends are still a hassle in the 2020s. People keep reinventing CGI.
Every now and again I think "why doesn't someone just produce a simple standardised solution that would be cheap to host and easy to write", and have to lie down until the madness goes away.
Maintaining a static site is easy and places like github pages will host it for free; you can put a "SPA" in there if you like for no additional cost. But as soon as you need a backend it gets more complicated and expensive. Still cheap in absolute terms, but relatively more complicated. Oh and you need to keep an eye on it for security. I know the long list of reasons for this situation, but I'm questioning why it has to be this way.
Back in the 80s there were proprietary monolithic single-user systems for producing what were effectively interactive databases, such as dBase and FoxPro. There was also the legendary programmable hypertext system HyperCard. And yet developing a small web application to do something that could be knocked up with a few screens of dbase or hypercard is much more time-consuming.
It seems to me I see more and more a growing distance between how data is stored in a sql db and how the data is actually rendered or represented in the application.
Dokku install:
$> wget https://raw.githubusercontent.com/dokku/dokku/v0.19.13/bootstrap.sh;
$> sudo DOKKU_TAG=v0.19.13 bash bootstrap.sh
Create an app:
On the server:
$> dokku apps:create application_name
$> dokku postgres:create application_db
$> dokku postgres:link application_db application_name
On the client:
$> git remote add dokku ssh://dokku.servername.tld:22/application_name
$> git push dokku master
$> dokku letsencrypt application_name
$> dokku letsencrypt:cron-job --add
For a static site, you literally push a repo with a `.static` file and an `index.html` in the root dir (you can do more complicated things, too).
It's not quite as powerful as k8s or whatever, but it can run small to medium sites easily, and it does have an Alpha-quality scheduler to push to k8s that I haven't tried yet, but should work as well as the Docker backend, eventually (and I'll switch to that when it's fully capable, too).
With DigitalOcean, I hear you can do 1-click Dokku servers if you don't want to do it yourself (I haven't tried this).
Is this C vs Rust again? (it's a joke, but go ahead, downvote).
I related too hard.
I had an intern say something like this but didn't give a reason. So I asked "why?". He couldn't give me an answer.
this is one reason why i fully believe companies should have a give each developer a half-day or day to work on new thing for the company so that new developer get to scratch that itch without trying to force using something new just for the sake of using something new.
Also, if companies stop requiring 4 years of experience in a technology that came out 3 years ago in their job description that would also help. Instead, let people transfer from similar technologies and let them learn it on the job.
I thought that was your junior response... you update it once a month, seems like WordPress is seriously overengineered for something managed internally. Static website + a 1h ticket once a month seems much better.
You'll save in performance, security, and it over a few years, it would take you less work time than doing a full WordPress.
If it's more than once a month, now it may be more interesting to go toward a WordPress, but that would be doubtful.
Sincerely, someone with way too many Wordpress sites.
Some experienced developers get it, but I have argued with plenty who are busy keeping up with the hype cycle and resume driven development.
This article is about static HTML/CSS/JS. You can accomplish a good, modern CMS in halfway-decent languages using netlify and any static site generator framework you want without making your devs miserable.
Wordpress does what is required out of the box.
In fact, you don't even require a developer to do it. It's a point and click operation of selecting a theme, installing a cache add-on, add an SEO add-on, and hell, there's probably a "office hours" plugin as well.
If the receptionist isn't a technophobe s/he can probably do it themselves.
If you want to assign resources, get a designer in to make it look pretty. Wordpress has everything else covered.
Why not use Wordpress --> static generator --> Netlify (aka free hosting)?
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.
No my point isn't declarative being inherently deterministic, rather that imperative is almost always inherently non-deterministic. By the nature of imperative programming you are making assumptions about your environment (i.e. there's DOM nodes to work with) which makes it intrinsically non-deterministic (those DOM nodes could not even be there)
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.
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.
???
<pre>If you have any questions:
Phone: <b>0123456789</b> <a href="tel:+18123456789">[call me]</a>
whatsapp: <b>0123456789</b> <a href="https://wa.me/0123456789?text=I'm%20interested">[message me]</a>
facebook: <b>html.purist</b> <a href="https://www.facebook.com/messages/t/html.purist/">[message me]</a>
</pre>
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
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...
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.
There's also a built-in CLI that can deploy to our free hosting service, which is built on top of Digital Ocean.
When sites finally ditched their trendy Flash rewrites and went back to HTML, I thought, thank God.
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.
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/
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.
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.
"The wheel of reincarnation" from client to server and back: http://www.cap-lore.com/Hardware/Wheel.html
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.
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 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.
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.
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.
My ageing memory may be failing me, but wasn't Perl the first widespread language to be used for CGI ?
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.
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.
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.
A static site may be archived. It may be used with any browser at all. It will probably be useful even without a browser.
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?
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.
I didn't wanted the hassle of a DB, theming, etc. Why can't I edit webpages with Dreamweaver like 25 years ago?
Then I've found Hugo (https://gohugo.io/), set a template in like 5 minutes and now I edit my docs directly in VSCode and see them change in realtime. Also, the docs can be easily versioned (git in my case).
For a dumb like me (in the web-developing sense), static pages are a blessing. I am glad we are "evolving back".
Article author here - I wrote this after realising that buzz words have entered our industry again in the form of the JAM stack terminology. Hence I took an approach of actually what is going on under the hood.
What I want to see is more support for serving svelte and integration between front end components and backends. (I.e., the backend has a list of root components generated by the front end and a route can return one of those components in a statically typed way)
This quote is from Johan Cruyff - A football legendary. I feel it also true with programming.
Nothing wrong with the technical stacks, in my opinion: Do the right work, at the right time, with the right tool.
``` npm i -g vue-cli; vue-cli create my-app; cd my-app; npm run build; aws s3 cp --recursive dist/ s3://my-site/; ```
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.
Compared to what?