As a frontend dev this has always been my stance, but I’ve been consistently shunned for it.

How much of that was naïveté vs. misaligned incentives I’m not sure.

In any case, these thing always leave me with the feeling the industry is getting way too saturated with script kiddies. It just feels immature, and the culture that’s grown around web dev seems to reflect that. Or more likely I’m just bitter and old.

Or more likely I’m just bitter and old.

Farmville Devs <- Facebook Devs <- Chrome Devs <- OS Devs <- Chip Devs <- Factory Devs

The abstractions are not, however, good enough yet.

Once you start adding conditions and context to the heuristic, it starts to look a lot like a Design Pattern.

What I was describing could maybe be conceptualized as multiple applications that serve one larger site. You have the public facing staticly rendered site, built in whichever way, but that ultimately has accessible rendered content on page load and as fast as possible. Then you also have interfaces to the data that is rendered there, which might be completely separate codebases for different purposes.

These could also take place in things like a reporting portal inside a company, where stakeholders need to regularly see static or filterable reports of pre-rendered data, and then you have other internally available apps that different departments can use to manipulate that data in ways that they can easily receive immediate feedback on whether or not it's valid or how it looks etc..

Maybe we don’t talk about the same thing, but isomorphic code with react is great for websites too: server side render, instant page change on client side. Reuse of exact code. Huge benefits.

I am just curious, why would I use Rails over something like .Net in today's time? I am no apologist for .Net or anything, I am just genuinely curious.

It's an engineering decision with tradeoffs, like every engineering decision.

Actually the latter is a candidate to k8s because the team knows less and less of server management. I think they are going to replace complexity with complexity for something that fits well in a small VM. We will see.

About Elixir, I don't think it's an overkill. I find its pattern matching much better than anything similar in Python and Ruby. Running a background job without having to use Celery or Sidekiq is great. The deploy story is worse than Ruby's (IMHO) in part because it's compiled (I prefer to deploy with Capistrano than having to build and deploy.) Python's deploy story just doesn't exist. According to the project I'm using a self made Capistrano equivalent, git pull or sending git patches to the server.

Unless you have some specific requirements for you app like high concurrency or memory safety and so on, then you can pick whatever you (or your team) are most comfortable with: Django, Rails, Symphony, .. are all excellent.

It's more about solving business problems and building great systems than anything else. All tools have pros and cons of course, it's simply up to us to review the requirements and pick the right one for the job.

You are not wrong though, and it's quite annoying when hopping between multiple .Net versions. I feel like I have a bit of insight into what it would have been like to be developing in Python during the 2.x to 3.x schism years back.

Then, they come up with The New Thing every few years, which is not backwards compatible and only handles 20% of what the old thing did + a few new things, but they promise this is the future and will eventually have all the features. The Old Thing is always there if you want it, so there's no reason to revolt when this happens.

The New Thing will eventually be replaced by a Newer Thing, get frozen in its current status, and the Newer Thing will be promised to be the future.

A nice example is Windows GUI. The Old Thing is GDI. Then they invented WinForms in .NET, then WinForms was abandonned in favor of WPF, then WPF was abandonned in favor of Metro/Modern/Universal apps, and last I checked they had some new HTML+JS-based stack available. All of these frameworks still work - you can take an app built with any of them and run it on the latest Windows, and you can even build a new App based on any of them and still find resources for it etc. But none of the old ones are getting new features, and MS will steer you to one of the newer ones instead.

The same kind of thing happened with communication frameworks (COM, then WCF, then???), with ORMs (ADO.NET, LINQ to SQL, Entity Framework, Entity Framework Core) and I'm sure others.

I detect a similar strategy with Apple and the app store: make it so that the long tail of small developers can't invest in more than one platform by moving goalposts so frequently you spend any spare cycles you have trying to keep up.

But all t he other stuff common to popular libraries still applies, tons of community support, huge extensibility, large population of devs that have experience building large apps.

That means it's not likely to make huge breaking changes without lots of notice. Its development team isn't going to find something more interesting to do tomorrow. Lots of people know it. There are lots of libraries and tools that work with it. Its capabilities and limitations are well understood and predictable. Its future isn't tied to a single vendor. Lots of people know it.

I mean, I solve most of my problems with the hammers I have at hand. But I try not to fall exclusively in this trap of “I will use tech X because that’s what I know.”

But I see a majority of my programming peers who will avoid moving “forward” because it’s easier to “stay behind.” At first, this works, because the difference between what’s new and evolving versus what’s established and a “core competency” is trivial and easy to marginalize. As it persists over time though, the investment can become a real millstone.

I am pretty comfortable with Python. We use it some pretty key areas in our product. It’s an established technology and competency for us. Last year, I needed to construct a service that was going to involve spinning up LOTS of little long lived threads. I was concerned about doing this in Python. Doing so would be easy and straightforward. “Because I know it” would definitely have said “do this in Python right now, deal with scaling issues later.” Instead I looked around and deemed this a good reason to take Elixir for a spin. I’m glad I did. It turned out to be a good fit for this problem. “Because I don’t know it” caused others around me to raise their eyebrows and question my approach initially. Was it the 100% best choice? Who knows for sure. But it’s worked out well. Ironically, just the other day, a data serialization library I have in both systems, the Python one needed to run faster (new use case for it suddenly needed speed that we didn’t hitherto care about). After some profiling, I rearchitected the python algorithm to be more similar to the Elixir one and gained about 50% speed up.

That would be a VERY interesting case study. Any chance you could write it up as a blog post or similar?

You could just fade out rails as you could with any other monolith, but many companies aren't doing it because it offers legitimate advantages.

Database driven sites and apps have experienced great performance and functional gains since the marketing teams pushed SPAs onto everything and it's tragic that billions of dollars will be thrown off a cliff (once again) to refactor everything back to prior methods... Hubris always wins until it fails massively.

That being said, SPAs do work well for certain things, but people just keep losing track of the right shoe for the right foot.

On big, sprawling, multipage content-rich websites, not so much if at all.

It depends. Web people should have this tattooed on their foreheads.

I'm aware that Google can run JS, but its support is limited compared to server rendering and there are other crawlers behind Google which probably will never be as sophisticated.

The other way is to add a few lines to your `robots.txt`.

If you mean "google" as "google properties as a whole", then yeah (the fusion of google maps and google earth is something absolutely _mind blowing_ to see in a web browser, for example).

If you mean "google" as "the search engine", then I was perfectly fine with a server side rendered, non-so-much-semantic search it was until last decade. Advanced search worked well, fast as hell already. Hell, there were two search text boxes if you wanted to search for something else once you scrolled down to the bottom of the page.

The whole concept of Single Page Applications was misguided from the start, and the reason for that is even in the name. Pages and applications should never have been mashed together. The moment we decided we needed apps, we should have abandoned the static document-based "page" concept altogether.

We shoul've replaced it with a browser-hosted VM-based execution environment in which proper apps could be built.

It's never been a question of MPA vs SPA. The question has always been how do you build browser-based applications in a way that escapes the impedance mismatched document/html model?

And, we're now delivering entire frameworks to the browser to support, essentially, a kludgy VM-based approach that just shoehorns app concepts onto the HTML document model.

So, what I'm suggesting is more of an in-browser hybrid.

Assuming the only two approaches are Flash or React seems like an industry-wide failure of imagination.

I'd venture to guess that even an MPA comprising multiple SPA 'pages' is an unsurprising composition especially for captive audience apps like internal, or government etc.

How many micro-interactions do you want --- the more you have, the more likely you want an application rather than a site.

When you first go to aws.amazon.com, you get a website with content about AWS.

Once you log in, you’re in the AWS web application, and it’s time to start doing things.

Forums like HN, I would consider websites because there is a lot of reading and not much doing.

Wikipedia and blogs are mostly for consuming content and it's the same content for everyone. Clearly a website. Instagram usually isn't super interactive, but it's extremely personalized, so it's much more like an app. Gmail also clearly a web app.

Amazon is highly personalized and fits well into the standard web page paradigm. What about Instagram's "personalization" wouldn't work as a standard web page?

Really nothing. But for most people Instagram is primarily a mobile application and comes with the usual experience of a mobile application. Transitions, fast reactions, no "whole page" reloads, etc.

Continuing this experience into the less frequently used browser version only makes sense, especially given the fact that Instagram's tooling allows for a relatively easy transfer (iirc large parts of the mobile apps are implemented using React Native)

Firstly if it's "transactional" it fits more often into the label of "application". If it is there mainly for consumption of media, it's more "Web site".

Secondly, I think it's useful to think about what it'd feel like as a desktop app. Stuff like say Google Sheets would feel perfectly normal running on your desktop. It's super snappy, all on-page. Something like the BBC or HN, not so much.

The only clear line I've seen is javascript. If it uses javascript for anything nontrivial, people believe it's a web app. This comes up all the time in threads about "the old web" or "how you would fix the web," in the context of what seems to be a prevalent belief on HN that the web should be split up between the two paradigms, with purely static, noninteractive "sites" in one place, and "apps" in the other.

Problem is, as mentioned upthread, the vast majority of sites using javascript, including SPAs, are still meant to be read as documents. If you include any form of interactivity, including backend processing and rendering, even more sites become apps.

In practice, it seems to me to be more of a religious taxonomy than a technical one, based on the belief that the modern web has become tainted by complexity and needs to be made pure again.

I see it more being whether a page uses progressive enhancement. If I can disable JavaScript and at least be able to read a page's content, then its a web page rather than an app. If JavaScript is an absolute requirement for any functionality it's an app.

A page with some client-side form validation, AJAX submissions, or even just some dynamic content are awesome uses of JavaScript so long as the pages themselves don't hinge on me running the JavaScript. Posting a comment might be a POST and clicking an image thumbnail might load it in a new tab instead of a light box. The functionality is all still there if for any reason the JavaScript doesn't load.

One of my big problems with "apps" is they have zero provisions for JavaScript not running. Most "apps" don't even give an error page telling you explicitly JavaScript is required. Even when you have JavaScript enabled they tend to break in stupid ways if you've got an ad blocker.

anything that can be done offline ought to be an SPA so that it can be made to actually still work without internet access.

So the "It's even in the name" argument is not an easy decision point as you make it look like.

    Slack, Dropbox, Google, Notion,
    Spotify, superhuman, 1Password, Robinhood…

Thanks for letting us know everyone was waiting for you stating your personal preferences, so they can follow suit.