None of my projects want to be SPAs - <AUTHOR> https://whatisjasongoldstein.com/writing/help-none-of-my-projects-want-to-be-spas <comment><USER3> This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Why? Because big companies like Facebook and Google use them. Why? Because they actually are doing things that require them. 99% of the SPAs in production are things that should have been done the old Rails/Django/Laravel way, but that would not set you up as a developer who can do SPA's.

I have also witnessed discussions where management admits that they want something done in an SPA so that they can show that work to their investors, as a means of getting funding to do other projects. So basically the same reason, except for managers to impress investors instead of developers to impress potential employers.

Not saying all SPAs are mistakes; some uses clearly are not. But most of them are.

<comment><USER4> Yeah, some people go so far as to directly claim that something is good because Google uses it. And when Google uses it, it probably IS good for solving Google's problems. But most people aren't Google and don't have Google's problems.

<comment><USER5> Ugh… We've had one of those developers. Now we're stuck with a legacy GWT¹ SPA that sucks the life out of any developer who touches it.

1: Google's abandoned webapp toolkit where you get all of the drawbacks of writing Java code with none of the benefits.

<comment><USER6> GWT ouch. Or as I call it "get with the times!"

</comment></comment></comment></comment><comment><USER4> Back when I was doing React, what pulled me in was that it WASN'T a framework for SPAs. What I got from it was the ability to build UI widgets (components, in React terms) that worked within a page, and were composable with other UI widgets.

With that approach, you really wanted to keep every component self-contained. That meant a lot of bookkeeping with passing events back and forth between parent and child widgets, but while it was a lot of typing, it was all fairly easy, and if I wanted to change how an event was handled, it usually only involved a component and MAYBE the components immediately above or below it in the component tree. Data passed further than that was generally wrapped in objects and therefore didn't require code changes.

Then introduce Redux and similar frameworks, and I totally lost interest. It's as if the entire React community forgot all the lessons they learned writing Python and C programs in college and went back to creating global state. What in the actual hell? I wrote a good amount of code in Redux, too--I worked on teams that used it--so this wasn't just pre-judgment. These frameworks add a huge amount of hidden global complexity just to avoid having to pass parameters to components, which is the simplest thing to do.

And once you're doing that, you HAVE TO write an SPA, because any part of the page you want to be interactive gets pulled into Redux and your JS eventually eats the whole page. It's an infection.

When writing JavaScript now, I sometimes end up rolling my own version of the component style. It's an effective design pattern for UI widgets. But it hasn't been worth it to use React for a while now because the tooling and tutorials are all too conflated with Redux and similarly awful tools. And on a team, there's always the worry that someone on your team will infect your code with Redux and it will grow and consume your entire site. It's a real shame.

<comment><USER7> > These frameworks add a huge amount of hidden global complexity just to avoid > having to pass parameters to components, which is the simplest thing to do.

Redux offers a few benefits:

1\. Allows you to keep your global application state 100% predictable by treating it as a pure function of an event stream (dispatched actions). This makes it trivial to test.

2\. Allows you to "time travel" the state of your store using the Redux dev tools by replaying/modifying the event stream. You can also set up QA folks to export their events so that developers can reproduce any bugs in the global state 100% reliably.

3\. Allows you to access global state without explicitly passing down props from great-grandparent to great-grandchild.

While I'm not a fan of using Redux for everything (it does have costs), you mentioned only the most minor benefit. If you only want #3, you would just use React's built in context API.

<comment><USER8> I have yet to see a long term project built with Redux that was maintainable. That seems to be the common denominator in React projects that do not survive technical debt accumulation.

The issue with Redux is that it encourages side effects in components. After a while people are dispatching all over the place and you end up in a similar situation as you were with keeping track of JavaScript events. All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc.

If you can convince and enforce that all Redux activity only happens at the root component, you should be okay. But the reality is that once you have the discipline to only mutate state in your root component, then setState tends to be more than enough for anything but very large and complex interfaces.

With that said this article has the author implementing their homebrew bespoke event system which is likely even worse. This was a very popular and much maligned anti-pattern during Angular 1.x days. This article is suggesting the absolute worst possible idea for maintenance.

What kills the maintainability of React and similar frameworks is tracking down what component did what. Unfortunately, in real world examples, in my experience, Redux increases that issue and ultimately leads to a very difficult application to maintain long term.

<comment><USER9> > I have yet to see a long term project built with Redux that was > maintainable.

The only maintainable projects I have worked on in terms of web apps have been with Redux.

Redux is not great for simple projects, it is great for medium and large scale projects.

> All of a sudden something stops working because someone removes a component > that is dispatching on a timed interval etc.

That's the problem: react and redux are not enough for large projects, you also need a way to manage side-effects. Incorporating `redux-saga` would fit that purpose.

React, redux, redux-saga -> this is the recipe for large scale applications that I have used, built, and helped maintain with success.

One of the strongest benefits of redux is being able to see every single event in a debugger that displays current state, action payload, next state. It really does make tracking down state changes a matter of reading a global log.

Furthermore, because redux is not dependent on react and under the hood it is simply and event emitter, it becomes relatively easy to use the same exact business logic for one web app and use it for some other delivery.

We did this at my last company: because our business logic was based on redux and completely separate from the UI layer: we were able to build: a cli, chrome extension, outlook plugin, and mobile apps using the same exact business logic.

<comment><USER4> > Redux is not great for simple projects, it is great for medium and large > scale projects.

I'd say that the only times I've seen Redux work effectively at all is when the project was small enough that the complexity remained manageable.

> > All of a sudden something stops working because someone removes a > component that is dispatching on a timed interval etc.

> That's the problem: react and redux are not enough for large projects, you > also need a way to manage side-effects. Incorporating `redux-saga` would fit > that purpose.

I don't need a way to manage side-effects, if I don't use Redux...

I'll admit I haven't used Redux-Saga, but you'll excuse me being skeptical that introducing more complex tools will solve my complexity problem.

> We did this at my last company: because our business logic was based on > redux and completely separate from the UI layer: we were able to build: a > cli, chrome extension, outlook plugin, and mobile apps using the same exact > business logic.

Again, this is not unique to Redux. It's perfectly possible to have your business logic completely separate from the UI layer without Redux. In fact, my experience is that Redux tends to cause devs to mix UI logic into business logic (and any sufficiently complex UI will have its own state and logic separate from the business logic).

<comment><USER10> > but you'll excuse me being skeptical that introducing more complex tools > will solve my complexity problem

I'm a consultant and in my experience this misconception is by far the most common source of problems in redux projects. Redux is a very small and simple thing so you have to build a framework around it. Even redux-thunk isn't enough - that's only 5 lines of code.

I wouldn't recommend react/redux for public facing sites if there's no experienced, pure frontend team. A more batteries-included kind of framework would be better. There's a lot of thinking to do and hardcore levels of scaffolding to maintain before writing anything useful and maintainable with redux. But it can absolutely lead to maintainable applications.

Also, I've never seen any homegrown "vanilla" frameworks or data stores work well as complexity increases. It usually ends up as spaghetti, especially with a growing team + growing business demands. Or best case a poor re-invention of the wheel. There must be brilliant counter examples but they're probably rare, I may never have the pleasure of working with one.

<comment><USER11> Hi, I'm a Redux maintainer.

FWIW, we've got a new Redux Starter kit package that tries to be a bit more "batteries included". It includes utilities that help simplify several common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state automatically. It also includes `redux-thunk` built in, as well as some middleware that check for things like mutations.

Please try it out and let us know what you think!

[https://redux-starter-kit.js.org](https://redux-starter-kit.js.org)

<comment><USER10> Thanks, this is incredibly useful, I use everything in this package! It also doesn't deviate from the spirit of Redux or abstract too much, like rematch for example. Without something like this, I find that many people structure their entire Redux code based on simple tutorials. They typically only read the docs or worry about best practices and complexity _after_ they encounter problems. This kit will have them start off on the right foot.

<comment><USER11> Exactly!

I understand why folks have opted to create higher-level frameworks around Redux like Rematch, and it's not "wrong" that they've done so. But, looking at Rematch code, you can't really tell that it's actually Redux underneath.

With RSK, I've aimed for an intermediate level - decreasing the amount of things you have to write by hand and the literal number of keystrokes you have to type, but preserving the idea of "dispatching actions" and using reducers.

Glad to hear that you think it looks good! If you've got any additional feedback or suggestions, please let me know.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I went from MVC style all-in-one frameworks (Rails, Laravel) to application APIs fronted by single page applications and hope the developer mindshare tilts back to MVC frameworks. Something that'd take me an hour or two in Rails can take a week using these new tools, even after being reasonably experienced with them. Don't even get me started on Apollo (not my thing at all, and from my experience most don't know how to use it well, including myself).

Most apps are fine serving html, using plain old boring forms, and having the odd React or Vue component where necessary to do some heavy lifting for user interactions. Moreover, it's a lot quicker as a small team to iterate.

<comment><USER13> I recently started a hobby project and initially went with a JS solution. But when I had to start deciding on auth, maybe an orm, routing, db layer, and templating, I said fuck it and installed Rails.

Previously I had never built a real product in Rails, only the book store tutorial. I'm really happy with Rails so far. I don't have to worry about a lot of shit I had to worry about in JS land and now I can focus on the app itself.

<comment><USER14> As you're doing Rails I recommend you check out Stimulus JS ([https://stimulusjs.org/](https://stimulusjs.org/)). I've installed it in a recently project (Rails 6, rake webpacker:install:stimulus) and it's like a breath of fresh air. Totally gets out of your way, but lets you add behaviour to your app as you need it.

<comment><USER15> Agreed. Stimulus has been great and very refreshing. I love writing my html using erb templates, and being able to do that and easily add client side interactivity has been great!

</comment></comment></comment></comment><comment><USER16> I feel as if many sites that used to be fine and work well have regressed in usability and features and introduced unexpected behaviors and bugs since the SPA paradigm seems to have taken over. This seems especially true for many corporate, bank, shopping brand sites, etc. An example is the Capital One 360, Chase, and AMEX sites and even Reddit.

Even JustWatch.com seems like it's fairly polished, still has it's quirks. So, I just end up using InstantWatcher.com instead. Hacker News works well as is too, except the search on the bottom can act up it seems once in a while.

Edit: How could I forget, Netflix. The UI, getting to the details of a show/movie. Browsing, discovery, searching, it all feels broken and unintuitive. The DVD site last I checked was still decent. Netflix seems like the poster child for usability and regression issues moving to a SPA.

<comment><USER17> Fellow JustWatcher here, care to elaborate which quirks exactly you mean? Back when SPAs were still pretty new, we took the bet to make one with a pretty large surface area and despite a lot of issues (SEO especially) so far we're pretty happy with that decision.

<comment><USER16> Infinite scroll, showing the details, clicking back sometimes doesn't bring me back to where I left off. Same when scrolling horizontally for example on the New releases I'll have to start scrolling right again after click on the details.

Honestly, your website is probably the best implementation of a SPA website with multiple pages I have ever seen I can recollect. It still has quirks though. I just don't see why you would want to make a website like this a SPA.

Does that help a little? I wrote this quick, off the top of my head. I can try and provide more details maybe in an email or some other communication means too.

<comment><USER17> Hey, that's super helpful, thanks!

Why SPA? Well, a good question indeed. Actually, we're cross-compiling the same code for the webapp onto iOS and Android targets with build flags, where we're leveraging more platform features (i.e. geolocate cinemas).

Also, it lets us make the experience itself much more snappy once you're on the page, as there's just content to be re-loaded. You can switch tabs, we can remember scroll positions, stuff like this.

Stay tuned though for our completely rewritten release based on very recent technology, I'm hopeful this will change your perception about SPAs on large sites coming in March!

<comment><USER18> > Stay tuned though for our completely rewritten release based on very recent > technology

Nothing can possibli go wrong

</comment></comment></comment></comment></comment><comment><USER19> I don't use Elixir/Phoenix, but Phoenix's LiveViews brings all the butter to the monolith bread. State remains on the server, only visual state is sent over websockets, and the HTML is transformed with morphDOM.

[https://dockyard.com/blog/2018/12/12/phoenix-liveview- intera...](https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive- real-time-apps-no-need-to-write-javascript)

I hope to see this idea brought to Rails, but the its websocket story doesn't seem there yet.

<comment><USER20> I agree - it seems like a LiveView equivalent for Rails should be doable in principle. Check out these two projects, they're sorta heading in that direction: Fie: [https://fie.eranpeer.co/](https://fie.eranpeer.co/) AnyCable: [https://anycable.io/](https://anycable.io/)

<comment><USER21> If you watch Chris Mccord's videos (the creator of Phoenix and LiveView), it was an attempt to build a similar system for Rails that drove him to create Phoenix. The Ruby/Rails concurrency model mean that he was patching over so many cracks to try and get it to work, and it never quite did.

</comment></comment></comment><comment><USER22> For CRUD apps, using Rails etc. with Turbolinks[1] is the best way to go IMO. It gives you the SPA feel without the headache. In all SPAs, we load JSON, with Turbolinks, we load HTML of that page alone (without the CSS, JS etc).

[1] [https://github.com/turbolinks/turbolinks](https://github.com/turbolinks/turbolinks)

<comment><USER23> this is not just one simple drop in replacement, well it is if you load only html, but pages are usually html + js, even for "old" mvc. so because there is no page relaod you have to rethink all your events, objects and so on.

so if i have to rewrite my js with this just so i could fake SPA then benefits are so much smaller

<comment><USER24> Take a look at Stimulus JS in conjunction with TurboLinks

[https://stimulusjs.org/handbook/origin](https://stimulusjs.org/handbook/origin)

</comment></comment></comment><comment><USER25> We turned to React as the UI solution in our Rails app almost 2 years ago. It was the hot thing and I fell in love with the concept of components. While it did work well, I regret the decision. It convoluted our codebase and it seemed like simple tasks took way longer than I estimated. We're now back to doing things the "Rails way" with erb templates, turboklinks, and Stimulus to give us that JS functionality we were looking for when we chose to start using React. It's been a breath of fresh air.

<comment><USER14> I've started a new project with Rails 6 and Stimulus just recently. Stimiulus really does feel like a breath of fresh air. Just enough to let me do what I need to do without feeling like a burden.

</comment></comment><comment><USER26> Personally I was dumbfounded by complexity of doing async things in redux. Libraries like redux-thunk, redux-sage, redux-observable should not exist. The amount of boilerplate required was incredible and meaningful typescript support was very difficult to achieve.

Then I tried mobx, I was able to write a small app after 15 minutes of reading the docs and now I love react.

<comment><USER27> With context api and hooks you don't need redux or mobx.

Not that either one was really all that necessary in the first place anyway.

<comment><USER28> I've still found the concept of computed properties in mobx to be extremely useful (and I say this as someone who relies on regular React + SetState 90% of the times). MobX encourages you to think about representing your state in the minimal possible representation and to heavily use computed properties that depend on this smallest, irreducible state representation for everything else. Switching to this mindset makes developing more complex components (especially UI/forms) a breeze. I also find MobX to be great for async things and much easier to handle than via setState. Using setState alone in these types of complex components ends up being really tedious and prone to errors (largely driven by the async nature of setState updates).

</comment></comment></comment><comment><USER29> As a developer I agree that developers should prefer to get features out quickly and optimize the experience later. However, as a user, I think this section is _really_ important:

 _I'd like to try and make it work offline. To do that, and do it well, you need a way to show the data in different ways even when you can't call a server._

I often have "What the hell is this thing doing" moments as a web app hangs trying to complete a round trip over my mobile connection when I _know_ it has already fetched the information on that page or I know it could be doing something useful despite not being able to connect.

The author is not proclaiming that SPAs are a bad idea. He's just pointing out how much extra work they are, and that some types of apps are worse as SPAs, or simply much harder with nothing to show for it. He even points out that not all the badness of SPAs is intrinsic to being an SPA:

 _Why does a website that orders food from restaurants need a Megabyte of javascript?

I tried to figure that out by inspecting the API calls. It turned out they were tracking every mouse event._

In short: 1) horses for courses, and 2) SPA apps are a lot more work and you have to decide when the benefits are meaningful. Less contentious but maybe less fun than trying to argue which is the one to rule them all.

</comment><comment><USER30> There is a place for SPAs. I just built a single page React app (using the create-react-app package) that mostly replaced a complex pile of spreadsheets. It came out fantastic, I think. The entire compressed Javascript is about 150 kilobytes, the scripts typically load in less than 500 milliseconds, and my co-workers are very happy. The code is easy to change and the interface between the client and server is clean. (Note: I disabled the built-in PWA features; they made versioning difficult due to excessive caching.)

On the other hand, I also maintain a public facing service that is mostly server-rendered with lots of JQuery snippets. I don't see a need to convert it to a SPA. It works well as-is.

I conclude from my experience that public facing services probably shouldn't be SPAs, while things that outgrow spreadsheets might be good candidates for SPAs. I wonder what other areas have been explored.

</comment><comment><USER31> > It beats being a Magpie Developer. I have more time time to pet my dog, read > a lot of books, make fresh pasta by hand, and circle a more slowly evolving > collection of powerful technologies that let's me get stuff done without > spending half my free time chasing shiny new things.

Saying stuff like this is sure to please the hacker-news hipsters. But... is this honestly anyone's experiencing using new web technologies?

I tend to be on the bleeding edge of tech, and I very rarely regret learning a new technology. And I do not feel like I am wasting all of my time flitting from technology to technology.

I just think this is a smarmy attitude disguised as wisdom. People should like what they like. And as someone who has had to climb that hill before: Waiting around not expecting the world to change around you is a losing bet every time.

The fool doth think he is wise, but the wise man knows himself to be a fool.

<comment><USER32> > I just think this is a smarmy attitude disguised as wisdom

> The fool doth think he is wise, but the wise man knows himself to be a fool.

I fear that this wasn't meant to be ironic.

</comment></comment><comment><USER33> Another angle is that "SPAs" are build on top of a fragile and anti- engineering tech stack: JS, CSS, HTML.

In the past a 'SPAs' was build on top of more solid foundation like smalltalk or later Delphi. Most issues is that the browser stack, put it in real terms, is not the "right tool for the job" and will never will, without serious re- engineering.

<comment><USER34> Could you provide some links/keywords about these alternative solutions? This sounds very interesting but I don't know were to start.

<comment><USER33> Is unclear to me if you talk about Delphi and smalltalk?

<comment><USER34> I am interested in designs/technologies that could be viewed as alternatives to the usual tech stack for SPAs, even if these technologies are outdated but exhibit interesting properties compared to what we are used to today. That would include Smalltalk and Delphi yes. Sorry if I misunderstood your initial comment.

<comment><USER33> Well, Delphi is well alive and current:

[https://www.embarcadero.com/products/delphi](https://www.embarcadero.com/products/delphi)

(it have a free edition) and alzo exist Lazarus, a open source clone:

[https://www.lazarus-ide.org](https://www.lazarus-ide.org)

Is probably the most fleshed idea under more "traditional" paradigms (OOP, RAD, etc)

Smalltalk and others are less popular(?) and only know them passing, so can't give too much of that.

\---

Another interesting stuff can be rebel/red:

[https://www.red-lang.org](https://www.red-lang.org)

much low-level but nice way to do UIs in a apparent declarative way..

<comment><USER34> Thank you!

</comment></comment></comment></comment></comment></comment><comment><USER35> I come across so many sites that have been needlessly built as SPAs, and so many of those are broken in ways that are really hard to understand even as a technically savvy user. For regular people, it's a truly appalling experience - the sites my wife has to use for work are all like this, all broken and all slow - she blames her laptop. SPAs need to die.

<comment><USER36> Isn't this just the same as saying bad code acts badly though?

People can, and have written bad websites using every technology. I can think of plenty of badly written, hard to use MVC websites from my past.

It should come as no surprise, that bad developers have found ways to make badly written SPAs as well today.

I don't think we should judge a technology by its worst implementations.

<comment><USER35> I don't think it is, no. A plain old HTML and CSS website gives me some clues about what's happening when I click things: if I click and nothing happens I can see a progress bar in my browser that shows me that I'm waiting on network - if I do the same in a SPA I get no feedback at all. You could say that all SPA developers should be writing this feedback, but even that isn't reliable - quite often the broken SPAs _do_ show their own feedback with a spinner or similar, but still there's no way of knowing if it's actually doing something or if it's broken. I can open the web inspector and look for XHR requests, but if it's trying to do something with no XHR then again, no way of knowing. They break user expectations, and when they don't function correctly this can be hugely frustrating.

<comment><USER35> Oh, and I forgot to mention that they often break standards that a lot of people rely on, in particular the native zoom in browsers.

</comment></comment></comment></comment><comment><USER37> A SPA should be the emergent _result_ of creating an application that does something people want, not a goal in itself. Your builder doesn't show up at your house to put on a new deck and go "Gee, I really hope I get to use this 20-pound sledgehammer on this job. I hear it makes great projects"

If you start with how it's going to end -- it's not going to end well.

Having said that, what you're most likely seeing is that a ton of tools and frameworks are built for no other reason than 1) Coders need something to create to show other coders how awesome they are, and 2) People want something that works like everything they know -- it just does these one or two new things

This is a great way to make a mess over a decade or two, and you're right for waiting it out.

Make a SPA if you need a SPA. Key question: How do I know whether I need a SPA or not? (Or whether React makes sense, etc)

</comment><comment><USER38> There are lots of applications which don't really benefit from being an SPA (blogs, books, etc.). As soon as you start thinking about meaningful interactions you quickly start having to pile enough JavaScript into the HTML that you quickly run into a mess - defining ways to marshal data back and forth with an ad-hoc structure.

While SPA tooling like React are incomplete since they don't provide all of the client/server data communications that comes for free with a server side application. That is starting to become more "standard" as GraphQL and Apollo start filling the gap of boilerplate. Though of course wrapping your head around GraphQL takes a bit of work for anybody who's spent their life with REST.

Most applications should be SPAs to create the interactions that users expect.

<comment><USER39> This builds an implication that spa tooling is the way to avoid a mess.

Which is ironic to me. As soon as the teams I've seen start piling a ton of extra stuff into the UI, be it types to make things more safe or logic to make things feel faster, you get a mess.

Note I'm not claiming either of those are the problem. More code is just almost always more mess. Keep it small. If possible, keep it separate.

<comment><USER38> There are two forms of mess in my experience, none of them have to do with SPA.

1) You have the problems that different developers have different styles. So when you jump from one area to another in the code base you're hit with WFT this is functional/procedural/inheritiance/composition, etc. style and your first thought is "barf" they did it wrong...

2) People either have huge functions that are spaghetti or tiny little functions to avoid complexity that are one line if statements.

Both of these are usually rooted in lack of a shared code culture, these are not SPA issues but team issues.

<comment><USER40> These could also partially be language and tooling issues.

There are some languages that are so "powerful", "flexible", and unopinionated that every developer has dramatically different coding styles (JavaScript, Scala, etc.). On the other end of the spectrum are tightly prescriptive, constrained languages where everyone's code looks the same (Go comes to mind).

No doubt team culture plays a part as well, but in team settings it is important to pick tools that are designed for team settings. These tend to prioritize regularity, lack of flexibility, syntactic simplicity, static analysis, etc.

</comment></comment></comment></comment><comment><USER41> SPA and react are not the same thing.

React is about components and you can use React in something like NextJS which is not a single page app but a server rendered pages.

Also, SPA itself is getting outdated concept, now most apps are hybrid of initial bundle followed by a dynamically imported modules. Finally, MVC is a pattern for web pages, the complexity in the client side because what is the being shipped to the browsers are a client side apps with their own router, render functions, state management and APIs.

</comment><comment><USER42> We recently went in the opposite direction for a student project I'm working. We have a full SPA Angular frontend, and we use CouchDB as our datastore. There is a Node "backend," but it only serves things like Slack integration, the browser has a local PouchDB instance that directly syncs with the server's CouchDB. This way, we can deploy hotspots with nothing more than a Couch install and a static server for the SPA.

The modern, offline web is great. If we had to do this in a native app we would never have gotten the project off the ground, because we initially need to use BYOD phones which were evenly split from iOS/Android. We'd have had to use three languages, but a Mac, get developer licenses, and learn Swift and Java just to get an offline frontend, and sharing business logic code would be impossible.

<comment><USER43> This sounds interesting. I'm light on details on how CouchDB and its sync works, but how do you deal with data validation/data conflict? Or maybe malicious actors tampering your data? Or is it a closed app that already have those dealt with in the spec? It would be awesome if you can share more about the project.

<comment><USER42> I'll email you a copy of the whitepaper once it is finished. The famous quote is, "CouchDB is bad at everything, _except syncing_." It has a built in revision system that will create two conflicting revisions on both ends, and allow your code to implement the business logic to determine the one true revision. This could be a prompt, or a rule based on the data (ex newer timestamp winds), or even an average of various data fields to create a whole new field.

[http://guide.couchdb.org/draft/conflicts.html](http://guide.couchdb.org/draft/conflicts.html)

<comment><USER43> Wow, the revision system is really interesting. Makes sense why you used it that way. Thanks for the link! Am excited to wait for the whitepaper.

</comment></comment></comment></comment><comment><USER44> To add to this, bandwidth and app size is not important to the user(they'll watch netflix later). The only thing they notice, is response time.

React with well defined static content routing and server-side rendering is amazing at this because the first packets that the server sends the user is html/css jumble.

You can get your app to show text and formatting in as little as 20ms(depending on where you deploy it), then show images, then you don't care if the rest of App and all the js and 3rd party crap take another 2.5s and 3mb to load, The user will do a bit of reading and picture watching, before using a button or input field. However if they're on the go and loose connection, now they have a fully functional back button in their browser to read the next or previous cached html/css content.

<comment><USER45> How is this amazing?

We've been "server side rendering" since the inception of the internet.

If you build your pages with CSS at the top and JS at the bottom you're already achieving most of that effect right there, no extra tools needed.

The browser will load the css and content first, and then process the JS requests (Which are easily cachable by the server AND the browser).

<comment><USER46> I suspect nisten is referring to server side rendering using React.

<comment><USER45> I think so too, but my statement still stands.

There's nothing new or especially special about "server side rendering", and nothing about React rendering either.

Rendering on the server lets you do whatever you want.

Want to put the user in a specific state? Sure, go for it.

Want to use a starter or null-state? Sure, go for it.

</comment></comment></comment></comment><comment><USER47> Also one of the things not listed here is the added complexity of an SPA, the routing bugs, the old browsers bugs, the added complexity of splitting js files so the initial load does not become too big, the data storage...

I'm currently maintaining alone two large websites and only one of them is an SPA, that's definitely the harder one to maintain by far.

</comment><comment><USER48> What I did for a mobile web app I built last year after the react prototype was to slow on old devices:

\- Render all pages/routes/states into a _single_ html file (size ~2mb) but each page/component/state hidden via style=display:none;.

\- then write some hand crafted js (few hundred lines) to add event listeners to forms and show/hide the components depending on url change

\- cache everything via appcache/serviceworker

\- result: not so fast initial load (1-2 seconds) but really fast interaction afterwards even on old lowend devices, almost no time spent running js/react/vdom. even some scrolbugs I had to work round before when using react (eg replacing dom nodes but keeping scroll position of a parent container) resolved on their own.

<comment><USER45> 2mb html file, + whatever else for initial load?

That's only 1-2 seconds on a fast connection.

If you have zero of that content cached locally and are on a mobile or just not-fast connection it'll be way more than 1-2 seconds.

Your "solution" is one of the ones responsible for locking up mobile browsers all over the place, because the browser still has to deal with the entire DOM, and it's often done way inefficiently.

<comment><USER48> > 2mb html file, + whatever else for initial load?

nothing else because all images are already inlined as svg as well as all styles and the mentioned js code

> Your "solution" is one of the ones responsible for locking up mobile > browsers all over the place, because the browser still has to deal with the > entire DOM, and it's often done way inefficiently.

I only came up with doing it this way after previously having build the same app using react and old devices (eg android pre chrome) could not handle all the vdom diffing and add/removeNode.

Our users preferred a slightly longer initial load (even 10 seconds) and lightning fast interactions afterwards over fast initial load and sluggish UI for all the time using the app.

When doing client sit rendering you would still have to transfer and parse little chunks of json all the time.

As it turns out browsers are really good at handling even huges DOMs as long as you do not manipulate it to much.

Granted this way only works if you have a limited set of states/pages (eg a few thousand).

</comment></comment></comment><comment><USER49> This article and discussion does show, in a pretty stark way, the options and demands of very different career paths for a software developer.

One option is to become a programmer for hire. You keep your skills up, and those skills are as much about getting a job as doing the job. You re-study data structures and algorithms. You can permute sets, find matching subtrees in binary search trees, and answer questions about how addresses in web browsers are resolve to web sites. You learn java, then GWT, then EJB, then spring, then struts, then you add a 2 to the end of struts, then Rails or Django, then you give it all up and do it again in Javascript, React, Vue, Ember. You also play the agile "estimate roulette" as you write down tasks and expected completion times in JIRA, and are asked about deadlines every morning in an almost inevitable corruption of the original methodology[1].

You would never do this for your own project. If you had an exciting new idea, the last thing you would do is go off and learn to find all subsets of a larger set that, when concatenated, form a member or the larger set, at the whiteboard, in 45 minutes. It's also fairly unlikely that you'd set out to write an SPA for many business ideas. But you'd definitely be doing this if you were applying for the next job, which you sort of always are doing, if you're a programmer for money. Even if you aren't looking to change jobs, you still do this, by and large.

Or, you can become the kind of programmer who creates a product, chooses the right tool for the task, and makes it work. The reason that this is difficult is that these jobs are rare. To really have this option, you often need to make the leap into doing your own thing.

That sort of entrepreneurial skill and mind-set seems to be orthogonal to most programmers. I couldn't tell you if it's innate or learned, but I do know that it's a big leap, involves risk, requires a period of economic uncertainty that is tough for people with dependents (or people just trying to pay rent and make it through the next few months in an expensive city). But it may be the best way out of the programmer-for-money quagmire.

The thing is, if you have that kind of entrepreneurial spirit... well I'm not sure you really need to be a programmer at all, there are all kinds of great opportunities out there.

[1] Yes, this is a bad case. Not a worst case, but a pretty bad one. I'd say all programmers for money have gone through some version of this more than once, but I'm putting them all together into something that is more grim than most have to put up with.

</comment><comment><USER45> I have to say my experience tracks this too.

A lot of the "modern" toolsets just aren't worth the extra fluff they add.

Writing SPA's in React, Angular, etc. tend to result in a very heavy first page load, then api calls with poor UX for all actions.

<comment><USER50> Don't regular web sites do exactly the same? They also usually pack all JS and CSS into two big files in order to reduce the number of requests on the initial load, right? And beside in SPAs you can split the code and lazy load it to reduce the load.

<comment><USER51> In the last Angular app that I inherited every menu on the page needed a separate call to populate it. It probably wasn't the best written app. I think if it had been plain Django with some jQuery for front end validation the size code could have easily been cut by a half or more.

</comment></comment></comment><comment><USER27> Why do people insist on comparing the initial frontload of a SPA to the page load of every page in their SSR web app?

Once a SPA is loaded you can send tiny crumbs of data faster than any significant SSR.

<comment><USER52> > Why do people insist on comparing the initial frontload of a SPA to the page > load of every page in their SSR web app?

Because a user doesn't care if it's the initial frontload or not.

<comment><USER53> Prerender the initial page and they won't notice any difference.

<comment><USER52> yeah there are a few ways to reduce the initial load time, but my point is it's valid to compare the initial load to every page in an SSR (for most use cases).

</comment></comment></comment></comment><comment><USER54> Completely agree on this one. I feel that a big chunk of "let's make it an SPA" is coming from the development team wanting to use and learn first hand these new exotic tech stacks. In the past two companies i have been, there was no strict guidance on the technology stack for each microservice or web app, so it ended up being a jungle of microservices written in GO, Elixir serving apps in React.js, VUE.js etc.

Did the company or the end user benefit from this? Hell no. Only one benefiting were the developers who ten left and asked for a 10k more salary on their next job for sporting that fancy new javascript framework. NICE!

</comment><comment><USER55> The latest project I'm currently working on I got to choose how to build. It is an internal CMS. I went with Rails API, React, Material-UI. So far, I like it.

I like separation. I know that one side ( ruby, rails, gems, pg, sql etc ) is all about data -> one mindset.

Another side is about views ( js, css, html, multiple select, date pickers, autocompletes etc ) -> different world.

I build my assets in one place, I work with my data in other. I wear one hat as a backend guy, and when I need refocus completely on front end work.

I wouldn't argue it's easier, but I think it's easier for me. I like it better.

Plus, the API will be consumed eventually by user-facing site and apps.

<comment><USER56> I'm almost exactly the same situation these days: small project, got to choose my tech stack, so I went with a "conservative" part I have good experience with (backend in Flask) and a more experimental part (for me) that I'm taking the occasion to explore and learn: React + TypeScript + Material UI.

For that latter part, although I must recognize that the tooling has evolved into a quite complex pipeline (which is a cognitive investment, almost a gamble, in itself), I also clearly see the benefits of a set of ideas that have rapidly evolved in the turbocharged settings of the web development ecosystem:

React: the distillation of many programming paradigms (functional, composition over inheritance, etc) for building UI components.

TypeScript: the augmentation of JS with mature and powerful programming constructs.

Material: a visual language for UIs with a strong focus on coherence and being truly cross-platform.

All in all, although I'm well aware of the critiques that can be addressed to the modern webdev environment (the so-called "JS fatigue"), I feel like all these new tools empower me, and I really enjoy learning about them.

</comment></comment><comment><USER57> There is a slight advantage of separation in frontend & backend - <USER2> tests for an API-only backend is so easy. On the other hand, the frontend SPA still needs tests, and I have no idea how to make that trivial yet.

P.S. If you folks want a really small react-like SPA, I recommend either [https://mithril.js.org](https://mithril.js.org) or [https://riot.js.org](https://riot.js.org)

And you can avoid state management complexity by using a pattern like [http://meiosis.js.org](http://meiosis.js.org)

<comment><USER58> Testing is easy in Angular. (Thanks to the everything is an object approach.)

[https://angular.io/guide/testing#component-class- testing](https://angular.io/guide/testing#component-class-testing)

[https://angular.io/guide/testing#service- tests](https://angular.io/guide/testing#service-tests)

</comment></comment><comment><USER59> I see the same thing happening on the front end that I saw happen on the back end with big data. Just because it fits better into Google and Facebook's Enterprise patterns doesn't mean it will work for everyone. Very few companies need Hadoop, probably as few as need react

</comment><comment><USER60> After working exclusively on SPAs for a number of years (React, Vue, Inferno) I'm getting out of that unless there is a strong argument in favor such as a hybrid mobile app (and that will go away once we move into Flutter).

I don't want to go back to Rails/PHP/Python though. I like having a REST/GraphQL API. With Hasura I don't have to worry about backend anymore for 80% of the cases.

What I'm doing right now for the front end is using Jekyll with Vue. It's really liberating not having to worry about a router or managing application state anymore. For certain in-house projects I don't even have to use Babel or Webpack anymore and still get to use Async/Await.

</comment><comment><USER61> In my personal experience very few projects actually want or need to be SPAs, developers are just dying to work on SPAs so hiring managers oblige to hire talent.

</comment><comment><USER62> I'm in pretty much the exact same boat as the writer here. Nothing I want to build seems like it'd need to be a SPA, nor work better as one.

Maybe that'll change if I decide to build games with HTML/JavaScript/CSS or want to make some sort of online version of a desktop program, but nothing in my current ideas list is app like enough to really warrant the SPA setup.

</comment><comment><USER63> My favorite pattern right now is server rendered html shell including static parts of the page, and then invoking a view-only js framework with all the server data required sent in the initial page load for the dynamic client bits, which runs immediately on page load.

so, basically a "functional" front-end view-framework for client-side behavior, but with no routing.

</comment><comment> c-smile Yeah.

1\. Tons of existing jQuery components.

2\. Ten of custom, loosely coupled ones.

3\. Built-in PubSub for their communication:

       $(document).on("custom-event", function() {...})

4\. Routing (if needed) in 60 lines of code: [https://github.com/c-smile/spapp](https://github.com/c-smile/spapp)

And you can do any SPA out there. Or not SPA.

</comment><comment><USER64> Every time I read an article about SPAs... I feel like someone has a new view on what an SPA even IS, what it is good for, and so on. Many articles sound like they're talking about entirely different things.

I get the definition, but I don't see a lot of problems and etc .... necessary a part of SPAs.

</comment><comment><USER52> If anyone would like an example of the silliness that exists in SPA bundling see [https://github.com/angular/angular- cli/issues/6137](https://github.com/angular/angular-cli/issues/6137)

<comment><USER65> > For those of you who use moment-timezone there is a trick to reduce the size > (if you can get away with 2012-2022 dates)

Lol, a 3 year solution. I immediately feel sorry for the future devs jumping into a codebase like that on New Year's 2023 trying to figure out what broke overnight.

</comment></comment><comment><USER21> I'm really interested in Phoenix LiveView ([https://dockyard.com/blog/2018/12/12/phoenix-liveview- intera...](https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive- real-time-apps-no-need-to-write-javascript)) when it gets released. It means you have the normal simplicity of server rendered code, but then an option for interactivity (e.g. A rich form) without having to have part of your logic in a completely different place/technology.

When you start thinking about field validations and having to duplicate them client and server side, it makes even more sense.

</comment><comment><USER21> I had always assumed that the move to Spa's occurred in large part due to mobile apps. A mobile app effectively has to be a client rendering of data from an API, and if you have to do that for mobile, it makes sense to do it for the Web.

</comment><comment><USER66> I don't think many projects _need_ to be SPAs. But if you're using node for your backend anyway, I think it's basically equal work to make something an SPA vs a non-SPA. The SPA effectively handles the routing for you, and I think react-router is pretty easy to use.

The speed benefits are noticeable on sites where you're doing a lot of internal navigation. But you can just as easily make a slow SPA (see JIRA).

So I guess in the end, do whatever takes less development time. Which usually isn't an SPA, just because there isn't really a good framework that reduces effort required. Rails and turbolinks are pretty legit.

</comment><comment><USER67> The Meteor framework has been actively developed ever since it was released and continues to have a broad, enthusiastic user base.

Mr Goldstein would have known this if he had visited the Meteor blog ([https://blog.meteor.com/](https://blog.meteor.com/)) and Meteor forums ([https://forums.meteor.com/](https://forums.meteor.com/)).

</comment><comment><USER68> If the project I'm working on is a personal project, then hosting price becomes a big factor, and being able to host an SPA on S3 for pennies a month, with a free Firebase backend, becomes a MAJOR advantage over hosting a Rails app on Heroku. If I'm working on OPH (other people's hardware), then I'll go with whatever makes more sense. Or whatever the rest of the team wants to use.

</comment><comment><USER69> As a mobile app developer, looking at the architecture of PWAs is a bit obvious to me. It's to turn webpages into stand alone mobile / desktop apps, with all of the power & setup that implies. But without the size overhead of an actual app, because every phone has a runtime library called the browser.

It's a great tool if that is your goal. Otherwise why spend the extra effort?

</comment><comment><USER70> To contrast, I've been looking for a reason to use Go for a couple years now on an actual project, I haven't really found one yet. That doesn't mean that go doesn't serve a purpose and is probably more representative of me being adverse to taking on the risk of learning/using it with a project than it does as to the ability of Go to serve a specific role.

</comment><comment><USER44> Wtf is an SPA?

<comment><USER71> If you have Javascript disabled, all you should see is a blank white screen, and if you're lucky a small note saying 'This site requires Javascript to work correctly'. That's what a SPA is

<comment><USER72> React Server Side rendering takes care of this... but most people don't know how to do it.

Without JS, Server Side JS defaults to good old school MVC.

<comment><USER73> When you are adding a new framework to render your single page app on a server, that's the point to stop and re-evaulate your technical decisions IMHO.

</comment></comment></comment></comment><comment><USER74> As someone who's self-taught in Wordpress development, I tried to branch into React but I had similar questions that stopped my progress. I'd always be thinking "why are they setting it up this way"?

Are there any barebones tutorials out there for CRUD apps that don't require Node.js, Python etc, and can be learned using PHP, MySQL and HTML?

</comment><comment><USER75> Do we really need to defend SPA every other week? The market, users, product, ui/ux designers and the vast majority of developers decided that SPA is a better user experience.

Page loads greatly degrade the user experience, especially when you have long lag (which for many of us the reoundabout time is longer then the download time of 100k).

Even if you make your site extremely lean, it's still a worse experience, and let not forget that for the majority of sites lean is far beyond them (not the least because you must integrate third party code such as social and analytics or fade into obscurity against those who do)

So some developers feel that the old way of doing things is just fine. There are always some of those. Probably the same ones who surf the web with js disabled. This is not even remotely what the average person expects and anyone who thinks they can build a website like that and compete are delusional (and hacker news is perhaps the exception that proves the rule. Even google is not html only anymore)

<comment><USER76> The phrase, "the exception that proves the rule" is not used properly here.

A proper example is something like: "Parking allowed on Fridays", which is an exceptional case to a rule that is implied: "No parking any other days."

Just a heads up, feel free to ignore.

<comment><USER75> Properly is a very loose term. It is common in speech and literature to use it to mean "an exception so rare that by virtue of it's rarity it strengthens the general rule".

If we are going by wikipedia definitions, then: "A rural village is "always" quiet. A local farmer rents his fields to a rock festival, which disturbs the quiet. In this example, saying "the exception proves the rule" is literally incorrect, but it is used to draw attention to the rarity of the exception, and to establish the status of the village prior to the exceptional event. "

</comment></comment></comment><comment><USER77> ... I read this entire article and still don't know what a SPA is :)

Seriously, I've tried looking it up... [https://acronyms.thefreedictionary.com/SPA](https://acronyms.thefreedictionary.com/SPA)

<comment><USER78> [https://en.wikipedia.org/wiki/Single- page_application](https://en.wikipedia.org/wiki/Single-page_application)

</comment></comment><comment><USER79> I've found the most annoying aspect of using a SPA is having to consume your own API's. Using Swagger or gRPC on both ends helps immensely.

These, combined with Angular CLI or Create React App, allow me to be just as productive as the pre-spa days

<comment><USER80> I think the beauty of SPAs is consuming your own APIs, because it makes you realize that _your website is just another client application_.

Nobody worth their salt would recommend coupling display components and database manipulation together in an iOS or Android app. A webpage is the same thing, because it's not running on your server, it's running in the browser _on the user 's computer_.

With this blog post, like most "I don't like X technology" blog posts, I find myself asking, "does the author not like this technology, or has he not taken the time to become a real SME in it?"

<comment><USER79> I guess another real advantage of SPA is that you get an API for free. Last place I worked, the product people had a genius idea to "build a public API". They decided to give us half a year to do it.

We had a SPA using OAuth.

I spent a few weeks adding docs, ran Swagger codegen, then declared it finished. Every call our front-ends used was now part of an API. Then we just trimmed out the parts we didn't want to officially support.

</comment></comment></comment><comment><USER81> I don't like them because they're against the nature of the web.

They override routing, they override SEO, they make it hard to use build in browser tools, etc, etc.

</comment><comment><USER82> Nr4. "people argued that it would be faster to only pass the data you need as JSON than to render whole pages" \- This also kills your SE(O)-ranking

</comment><comment><USER83> I gave up on the article as soon as I did a ctrl-f to find the definition of an SPA and didn't see it.

</comment><comment><USER84> Is SPA with unique-urls (think angular-routing) still a SPA ? Most of my websites+apps are done using Angular/PWA.

<comment><USER58> Why wouldn't it be?

</comment></comment><comment><USER85> Nothing wrong with the concept of SPAs. It's just these modern front end frameworks leave a lot to be desired. None of them simplify complexity and modularity is an illusion. Most of your components can't be reused in another project.

Additionally these frameworks are harder to debug thanks to leaky abstractions.

The only front end abstraction I've seen do it correctly is Elm. I'm not saying Elms' pattern or language is good or correct; (I have no comment about that) I'm saying that the abstraction isn't leaky. No javascript errors in Elm, just elm level errors. React Vue and all these modern frameworks need to be handled the same way.

I know technically that react is just a framework and not an entire language over javascript, but the ways and technology React is typically bundled with makes it a leaky abstraction and the common use case should be handled.</comment>


France Télécom / Orange Exec Confirms Apple Tablet Is On The Way - <AUTHOR> http://www.techcrunch.com/2010/01/11/france-telecom-orange-apple-tablet/ <comment><USER2> That's the first story that makes it very clear to me that a tablet is on its way.

Despite what Orange's PR says, it's very difficult to interpret what he says any different than "yes an Apple tablet is coming soon". (I'm French, so there's nothing lost in translation)

Another thing it confirms is the fact that cell phone carriers are involved, with 3G connectivity…

edit: French colleagues around me are not as convinced as I am apparently. In any case, I suppose we'll know more in a few weeks</comment>


The Birdy Is a Super Simple Budgeting Site That Records Your Purchases Via Email - <AUTHOR> http://lifehacker.com/5836887/the-birdy-is-a-super-simple-budgeting-site-that-records-your-purchases-via-email

<comment><USER2> What I want is something that will parse and auto-categorize my Amazon purchases based on their emailed receipts, and somehow get that info into Mint.com. (Or another app that can replace Mint and also do this.)

Right now Mint does a decent job categorizing most of my other purchases based on vendor, but every month I end up with a huge, opaque line item for Amazon. Really hampers my budgeting.

(I have the same problem with Target and Wal-Mart, but to a lesser degree-- they don't carry as wide a variety of stuff as Amazon, and I shop there less.)

<comment><USER3> I was coming here to post exactly this for small business...

Something that when I get an email receipt in gmail I can forward to my unique address (or filter in gmail).

I get Canada Post emails that are such a pain in the ass to do accounting for, but even something like monthly saas emails would be great to forward and it detect amount, taxes paid, category, etc. (and let me email to that address in the way this site does as well)

Here's at least two people who want it, who's going to build it? ;-)

<comment><AUTHOR> It's actually being built. Check out <http://onereceipt.com/> once they open.

<comment><USER2> Edit: sounds intriguing, especially if it doesn't require any kind of vendor support and I can forward it anything.

I would love to beta-test, if anyone's listening.

<comment><USER4> By "I can forward it anything", do you mean that you want to be able to train the app on new vendors? That would be awesome, but (1) hard to do right if that ordinary (read: Not HN reading) users could create their own filters or (2) impose difficult privacy problems if users forwarded their purchases to humans for parsing.

With respect to beta testing, according to <http://blog.onereceipt.com/post/9256372304/hello-world>, posted one week ago, they're going to start sending out invites to people who registered their interest 'within the next few weeks.'

If you want an early invite, they'll give you a referral email after you register.

> Invite at least 3 friends using the link below. The more friends you invite, > the sooner you'll get access!

<comment><USER2> I saw that -- but although beggars can't be choosers, as a rule I don't spam my friends with invitations to try products I haven't been able to try yet myself.

<comment><USER4> Me either, which is why I didn't include a referral link in my comment above.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> These guys have nice Yahoo! Mail App for scanning your inbox automatically and aggregating purchase history:

<https://www.projectslice.com/mail_app>

Full disclosure: I work for Yahoo! and supported them building this on the Yahoo! Mail app platform.

</comment><comment><USER6> Zawinski's law of software envelopment at it again..

"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."</comment>


Will MySpace ever lose its monopoly? (2007) - <AUTHOR> https://www.theguardian.com/technology/2007/feb/08/business.comment <comment><USER2> Back in 2003, I would've found it absolutely _inconceivable_ to not chat with my HS classmates on AIM. For me, even bigger than MySpace dying was AIM dying. It still kind of blows my mind. AIM was _the_ way you got social cachet back then. Everyone was on AIM. _Young people_ were on AIM.

I am completely convinced that FB will go the way of the dodo in the next decade, and it will take Snapchat and Instagram with it.

<comment><USER3> I remember moving to FB when my mom joined MySpace... I've since straight up quit social media, but I know folks that moved on to IG/Snap so they could broadcast content they didn't want certain social groups to see via FB. Of course now those social groups are joining the newer mediums.

Maybe social media platforms are inherently cyclical? At least under the "maximum growth" mindset:

* Innovators develop new platforms because they're unhappy with the old

* Early adopters like the new platform's features or community

* If it's good enough, the early majority slowly follows as knowledge disseminates

* New features and narratives are developed to attract the late majority and laggards

* The presence of those people, and tactics used to attract them, disenfranchise the early adopters

* Unhappiness rises until a new digital eden is discovered. Then the cycle repeats

<comment><USER4> My personal journey: Slashdot, Digg, Reddit, HN

<comment><USER5> Based on other responses here, I guess I'd be dating myself to say mine started with Usenet.

<comment><USER6> BBS, Fidonet, Usenet, ...

Someone will oneup this too with Arpanet or similar :)

<comment><USER7> I talked to the other hams in high school using Morse code and a vacuum tube transmitter.

And get off my lawn. :)

I've actually joked about building a Bluetooth telegraph key to make texting more concenient.

<comment><USER8> I assume you already have the Morse key USB keyboard? ([https://mitxela.com/projects/morse_code_usb_keyboard_mk_ii](https://mitxela.com/projects/morse_code_usb_keyboard_mk_ii))

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> If Facebook goes away, MySpace is nowhere near an adequate analogy. Facebook has 2.2 billion monthly active users. In other words, there are more active monthly Facebook users in the world than:

* Roman Catholics (1.2 billion)

* People living in China (1.4 billion)

* Total speakers of English, the most widely-spoken language in the world (1.4 billion)

* Muslims (1.8 billion)

* Viewers of the 2014 FIFA World Cup final (1 billion)

* iPhones ever manufactured (1.2 billion; also, the top two most-used apps are Facebook and Facebook Messenger)

* Windows users (1.4 billion)

* Inhabitants of the European Union (508 million)

* Cats (600 million)

* Firearms (875 million)

* Africans (1 billion)

Now, obviously whether or not you use Facebook isn't as important to your identity or as hard to change as your religion or where you live, but it's also not something that's just going to suddenly disappear without some sort of replacement, or else if it does, it will be the first time in human history that _two billion people_ all decided at once to give up on something.

<comment><USER10> Probably half of that are fake profiles, profiles made by people for commercial purposes or bots. If you make fake account and you will start wandering in the endless facebook steppes, you will notice that many of them are one post account that advertise or play games. The best ones are those with pictures of known or lesser known models to collect friends and sell such an account for dollars later. I have reported several hundred of such profiles, of which maybe 1/20 have been blocked rest is fine because moderators can't see difference between real life person and photo from google images in 20 accounts in a row...

<comment><USER9> 2.2 billion isn't the total number of accounts, it's the number of "monthly active users"\--and Facebook would probably be in much hotter water than they are now if they cooked the books on that number.

<comment><USER10> This don't change my comment still many of them are fakes. I know people who have 5-6 accounts active at one time playing different games with 500+ friends on it. Many of those "friends" also are fakes, some even with the same profile picture of "real person" with fake data but I have nothing against FB, every medium is abused.

It's just interesting that not a single research was done on this topic that I know about. :)

<comment><USER11> Why do your friends have 5+ accounts opened? To get around limits on games?

<comment><USER10> Game limits, not wanting to share private account with some random folks used in games or for commercial purposes aka selling account later on and I can tell that this business is booming! :)

</comment></comment></comment></comment></comment></comment><comment><USER12> This is a perfect summation of how people feel about Google and Amazon, or Sears in the 1920s and Kodak in the 1960s. And it's a perfect reminder that monopolies are much more fleeting than people realize.

<comment><USER13> I'm not so sure that FB's place will be so fleeting. I think they will lose their place at the same rate that Microsoft lost theirs. They will still be around in 15 years later, just not quite as relevant.

<comment><USER14> Microsoft is coming back in a big way though. Sure, it may not have the dominance it used to have but they've learned from the problems of the Ballmer era. Satya Nadella seems to be a huge proponent of meeting customers where they are and it's paying off in a huge way.

If Facebook learns to listen to their customers the way Microsoft has (as opposed to trying to tell them what they want) then they could recover. But with Facebook, users are starting to have large issues with its core business model, and to listen to customers and adopt the changes they want, it would cost them too much and would eventually disappear as so many others have before them.

<comment><USER15> > Microsoft is coming back in a big way though.

Really? They still have corporate desktops and cheap skanky laptops (for some reason), but azure is not a challange to AWS, they aren't in the media business, the home market is being chipped away, where are they doing better now then they were 12 months ago?

<comment><USER16> [https://www.forbes.com/sites/laurengensler/2017/07/20/micros...](https://www.forbes.com/sites/laurengensler/2017/07/20/microsoft- fourth-quarter-earnings-cloud-azure/)

Since 12 months ago profits have doubled, shares are up 19%, revenue is up 13%, cloud revenue is up 11%, cash reserves are up, oh, and PC-related revenue is down a whopping 2%.

Actually the latest quarter shows cloud revenue up 98% (I assume year-on- year), so Azure is doing pretty well.

[https://www.computerworlduk.com/it-vendors/is-microsoft- azur...](https://www.computerworlduk.com/it-vendors/is-microsoft-azure-really- making-up-ground-on-aws-3671566/)

</comment></comment></comment></comment></comment><comment><USER17> Dan Rather, after offering sage advice[1] to Mark Zuckerberg regarding the recent FB/CA drama, concluded with:

> This is about Facebook's survival, pure and simple. If you don't change > things, people will leave faster than you can say "MySpace".

[1] [https://www.youtube.com/watch?v=kObNf_gUXxE](https://www.youtube.com/watch?v=kObNf_gUXxE)

</comment><comment><USER18> Facebook was started in, what, 2004? It went mainstream on most college campuses in 2005. By 2006, MySpace was a place for the non-college educated; the older generation never used it, the college-aged users had switched (if they ever used it at all), and the younger generation either weren't on either, or were on MySpace but aspired to be on Facebook by the time they got to college.

There were legions of people who couldn't handle how downright ugly and terrible MySpace pages were, and simply never used it, even when it was the only option.

The idea that MySpace had a "monopoly" on anything, 2 years after Facebook went mainstream, is absurd. It never had anything like the market penetration FB has, even among those online and interested in social media, let alone the overall user numbers that FB has.

<comment><USER19> I was slow to join Facebook and I signed up in late 2006, several months before this article was written. The author here was just out of touch.

In September 2006 Facebook opened to everybody. At the end of the year, Facebook had 12 million active users, roughly doubling their number from 2005. By April 2007 they had 20 million users. By the end of the year they had 50 million. The author wrote this piece right in the middle of Facebook's meteoric growth and they didn't even notice.

The press had the same blindness over AOL Time Warner. To 13-year-old me, that merger sounded like a dinosaur from the Cretaceous combining with a dinosaur from the Jurassic, but for some reason all the papers thought AOL was the business of the future. They had no sense for what was cool.

</comment></comment><comment><USER20> I love this article. I think I submitted it to HN myself a couple years ago during some other Facebook news cycle.

I'd call it "Peak Guardian", but they keep outdoing themselves, so there may never be a Peak Guardian.

<comment><USER21> Can you explain stereotypes of the Guardian? The article is pretty over the top, but as an American I am not intimately familiar with them like, say, the Journal.

<comment><USER22> The Guardian is generally a mildly left-ish, middle-class-ish kind of paper. I would say in the UK it tends to conjure up an image of a well-meaning, slightly naïve, hand-wringing sort of readership, though of course it's base is likely wider than that.

What particularly makes it stand out is it has quite an open comments policy; it quite often publishes fairly ludicrous points of view from a variety of commentators. I'd say on the whole that's quite a good thing, though it does tend to result in some absolutely preposterous headlines from time to time.

<comment><USER23> Although usually mild-left, they sometimes publish articles which are pretty crazy-left.

Here's an example[1]: You have a university professor citing research saying that the 'acting white' phenomenon exists in integrated schools, plus _her own black students tell her they suffered from the 'acting white' stigma_. Yet she somehow concludes that belief in the phenomenon is not just wrong but 'intellectually dishonest'.

[1] [https://www.theguardian.com/commentisfree/2014/oct/22/acting...](https://www.theguardian.com/commentisfree/2014/oct/22/acting- white-theory-dear-white-people-college)

<comment><USER24> > You have a university professor citing research saying that the 'acting > white' phenomenon exists in integrated schools

...in the course of arguing that it's image as a feature of all-black communities is false. ( _Integrated_ is very different from _all-black_.)

> plus her own black students tell her they suffered from the 'acting white' > stigma.

What sdoes is relate that the "bullying essay" is a well-known archetype of freshman comp essay, and the common subtype of that type of essay she sees is one conforming to a particular form of the "acting white" narrative.

Freshman comp essays from people who don't have stories they want to share reflecting the author inserting themselves into narratives from the common folklore of their community instead of actual personal experience is a rather well-known phenomenon.

</comment></comment></comment></comment></comment><comment><USER25> "It did." -Ron Howard narration

<comment><USER26> Comedy doesn't seem to fair well on HN, but at least Arrested Development is still sacrosanct.

<comment><USER26> Ahem, _fare_ well.

</comment></comment></comment><comment><USER27> If FB declines completely and goes the way of my space, what will happen to all those 3 million dollar 100 years old, 1200 sq ft houses in palo alto?

<comment><USER28> Facebook != Palo Alto. The real estate in Palo Alto is propped up by far more than just Facebook. Mainly by massive amounts of venture capital flowing into startups.

</comment></comment><comment><USER29> At 2B users, it's hard to imagine doing a faceplant as fast as MySpace did. But I can definitely see a situation where it is hollowed out in the short term, meaning that 'high value' demographics flee to some other service. If it's bad enough, it could drop their advertising revenue enough to hobble them and precipitate a slow decline.

<comment><USER30> The "face-planting" could be regional. It's possible North American and European users might drop off swiftly while FB continues to grow in other parts of the world.

</comment></comment><comment><USER31> This reads like a comedy now, the flow of logic faultless, reminding us how fleeting these technologies are along with the anxieties we have about them taking over the world.

<comment><USER32> Right, a social network gaining market power and maybe abusing that? Ha, those days are long gone, kappa.

</comment></comment><comment><USER33> I wonder if an open source platform and protocol for messaging and contacts would have the potential to confront all the Facebooks, Whatsapps, etc

I am not talking about broadcasting / sharing. Just messaging and contacts (a listing where you can publish your latest contact data).

So many people say that they would leave FB but they have no other means to contact many of their friends on their list. So is there anyone who can offer a solution for just this?

Email is a protocol that works very good. So is sms. Platform and provider independend. - Something as successful as email with a listing of people and auto-updating contacts list (details only shown to someone that I allow).

<comment><USER34> There are a few projects that try and address this. The issue for 99% of the population is that you need to run it yourself (read run a server) or know someone who does.

You could go the p2p route (I'm thinking Torrents + magnet links kind of decentralised) so you just run a client and connect to the network.

Of course this then leads to the problem that users would have to backup their data (which they don't) and be online to participate with no real capacity for offline comms. Which leads back to needing to running a server of some kind.

</comment></comment><comment><USER35> Do monopolies of this scale are ever overthrown? MS in desktop OS, Intel in desktop and server chips. IBM is still a monopoly in mainframe market(not sure). It's just that new powerful industry in terms of mobile, internet services, social media have come up.

American Tobacco, Bell, Standard Oil and too some extent MSFT are all gone because of govt. actions.

FB has already successfully maneuvered industry change to mobile. It bought in its way into mobile apps and communication platforms. So FB won't be replaced by mastodon or Signal, but by an industry level shift which FB misses and can't buy in.

<comment><USER36> You're correct, IBM is more of a monopoly in the mainframe market now than ever before.

As far as I know, no one else makes mainframe hardware anymore aside from storage racks you can use with an IBM mainframe.

</comment></comment><comment><USER37> My take is, The Guardian does not understand the concept of monopolies well.

</comment><comment><USER38> Facebook has long been losing its monopoly... to Instagram. They have enough money to keep buying the Next Big Thing.

<comment><USER39> But isn't instagram (and also Snapchat) mostly photo sharing? How can that replace a communication tool?

Do young people really like chatting in public comments and in that cumbersome Snapchat chat?

Mostly I've seen teen girls just writing and "luv ya bb" under each others photos...

</comment></comment><comment><USER40> Does Diaspora still exist? (Answer is "yes") Does anyone use it? Asking because I have no idea, but the idea looks cool. [[http://DiasporaFoundation.org](http://DiasporaFoundation.org)]

</comment><comment><USER41> It's funny, I used to use MySpace to bookmark bands I liked or may like. Now I use FB for the mainly same thing, as well as keeping up on other interests like skating and surfing. Oh, how cyclical the world is...

</comment><comment><USER42> Was this article supposed to be a joke at the time it was written? Facebook had been open to the public for a year at that point and it was clear that Myspace didn't even have a monopoly left to lose.

<comment><USER43> There's another article from a few months later about Facebook "opening up" their platform with apps. They were taking over fast at that point.

[https://www.theguardian.com/technology/2007/may/31/newmedia....](https://www.theguardian.com/technology/2007/may/31/newmedia.media2)

</comment></comment><comment><USER44> Breaking monopolies is always a good thing for consumers.

Anyone knows a Social network with solid features, perfect UI and good privacy ?

<comment><USER45> I hear Mastodon [1] is getting traction, though for me the UI is a bit unintuitive.

[1] [http://joinmastodon.org](http://joinmastodon.org)

<comment><USER46> IIUC Mastodon is a twitter alternative; [https://diasporafoundation.org/](https://diasporafoundation.org/) is more targeted at replacing FB.

<comment><USER47> Diaspora has been around for a while; I remember joining about 6-7 years ago, but it suffered from the problem all new social networking sites suffer from -- nobody I knew or wanted to follow was there, so I abandoned it.

I've since come to the conclusion that I'm not really a social networking type of person.

<comment><USER48> Both Mastodon and Diaspora suffer from absolutely horrible names.

</comment></comment></comment></comment></comment><comment><USER49> Wait, MySpace is dead?!?

</comment><comment><USER50> And to think Fubar.com outlived them all.

</comment><comment><USER51> They lost it when they couldn't scale

</comment><comment><USER52> Google+ is going to take over the world any day now!

<comment><USER53> I'm sticking with Facebook. They're the only social network with whom I can trust my private data.

<comment><USER54> Said no-one ever.

Seriously, I'm too biased now to remember, but was there ever a time this was the feeling about FB?

<comment><USER53> It was never even a consideration. Social network are still a relatively new phenomenon for the world and few people thought seriously about their implications. In retrospect, more of use should have thought about how our data is bing used. Hopefully we can learn from our mistakes.

</comment></comment></comment></comment><comment><USER55>
       facebook.com (1998)

"With aboutface.com you can easily set up a directory for your organization in your own private location right on this Web site. If you prefer, we also offer a traditional, Windows-based product, AboutFace/Windows version 3.9, which you can use on your LAN.

aboutface.com is a Web-based service that functions as a directory for your organization. aboutface.com maintains photographs and biographies of your employees and takes the place of your old-fashioned printed phone lists, address lists, facebooks, etc. aboutface.com is available for low monthly rates and resides in a secure, private location on our servers.

We are the premier producer of electronic facebooks (online "names and faces" directories) for the business and academic communities."

Source:

[http://web.archive.org/web/19981212013921/http://facebook.co...](http://web.archive.org/web/19981212013921/http://facebook.com:80/)

</comment><comment><USER56> Pedant alert: "it's" -> "its" :)

<comment><USER57> They don't call it the Grauniad for nothing!

See: [https://en.wikipedia.org/wiki/Private_Eye#In- jokes](https://en.wikipedia.org/wiki/Private_Eye#In-jokes)

</comment></comment><comment><USER58> All the cool kids were on facebook.

I remember signing up in 2005 because I was taking German for my future trip to the World Cup (pointless as 95%+ will reply in __English __(edit), unlike those darn French!).

As it grew in size and popularity, the limited nature of it really made those that couldn't get in jealous. I remember all the kids screaming about the feed when it went live, how they'd leave. Then once it opened to everyone, they'd leave then.

WhatsApp seems to be the new kid's playground, so facebook buying it was a smart move.

There will be another. Hell, maybe I'll make it :-)

Dropped out of my (still better IMO) Telegram style program after worrying about N$A fallout.

<comment><USER59> The per university rollout of Facebook was genius. Actually keeping people from signing up until there is critical mass is, I suspect, crucial for building a social network.

There's nothing to discourage me from coming back quite like the feeling of signing up and finding out I'm the only one I know.

<comment><USER58> Well it was based off Harvard's yearbook which was called facebook. At least that was my understanding.

<comment><USER60> A "face book" is a generic term for a student directory.

<comment><USER58> Back in my day we just called it the student directory. Didn't have photos in any I'd seen as a kid/college student, those were only in yearbooks.

</comment></comment></comment></comment></comment><comment><USER61> Personally I don't like the current debt-based economy where almost infinite money can be printed in the first place.

</comment><comment><USER62> I hope the posting of this article isn't some insinuation of FB's fate.

<comment><USER63> Why do you hope that? Are you a FB shareholder?

<comment><USER62> Perhaps I should rephrase to what I meant to imply: I find it funny that people think Facebook is going away / will fade into irrelevancy.

<comment><USER25> The whole point of posting this article is that people felt exactly the same about MySpace, Ford, Atari...

<comment><USER64> Ford sells hundreds of thousands of vehicles a month. I wouldn't put them in quite the same boat as MySpace.

<comment><USER65> Cars also get replaced regularly and have practically no network effect (for the typical user).

Every time your Tacoma frame rusts out you're presented with an opportunity to switch to a differen't company's product.

<comment><USER66> They may not have much network effect, but I am quite confident that a lot of people buy the same manufacturer's car (or, hell, even the latest model of the same vehicle) every time they are in the market for a new car. Like, there are people who just buy a new Camry every four or five years.

<comment><USER15> If a $MAKE hasn't given you any problems, then you may well go back to it. If I were to buy a small car I'd buy a nissan micra -- I've owned two and both were really good.

However if $MAKE has given you problems, then you're likely to avoid it.

<comment><USER66> Of course there is a limit, but I feel like many shoppers do not seriously compare very many cars and sometimes brand loyalty trumps even the most negative experiences.

Either way, it means that Ford's position is pretty secure for a while.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER67> many years ago, i had bet a friend that facebook would begin to decline in 2016. seems like i might have been off by two years. _shucks_

my bet was predicated on (1) people realizing the insidiousness of facebook, (2) the cool kids moving on to other platforms, and (3) mobile communications being omnipresent and eclipsing facebook (solid but not earth-shatteringly original reasons).

i'd attribute the demises of friendster and myspace primarily to #2 (with underlying product and marketing issues exacerbating it). but more than that was required to topple the massive network effects moat that facebook built. notice that it wasn't another social network (e.g., snapchat) that will have overtaken it but rather a confluence of other issues striking in concert (some self-inflicted).

<comment><USER68> What exactly is declining? Their MAU, Time Spent, # Advertisers, and Revenue numbers are all increasing ([https://techcrunch.com/2017/06/27/facebook-2-billion- users/](https://techcrunch.com/2017/06/27/facebook-2-billion-users/)). Maybe they're just declining in eyes of SV bubble residents.

<comment><USER69> Well, their widespread acceptability seems to be declining, as indicated by all these articles and quittings lately. Presumably widespread quitting of users would only come after, not before, some high profile upsets and mistakes.

And # of Advertisers and Revenue are proportional to how people think they're doing, not how they're actually doing, and would presumably only decline after a mass exodus.

<comment><USER66> Yes, people are grumbling about them, but how many of them are leaving?</comment></comment></comment></comment>


Show HN: Design workflows, breakdown communication silos, ensure team alignment - <AUTHOR> https://www.youtube.com/watch?v=i87wjjgpqHQ&feature=youtu.be <comment><USER2> Blog posts and videos are off-topic for Show HN. Submit the product URL instead [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

<comment><AUTHOR> Thanks!</comment></comment>


Ask HN: Any Kubernetes Project ideas for solving a real problem? - <AUTHOR> If you're using Kubernetes in production, what's your major issue? For my U.G final year project, I'm thinking of solving a problem in Kubernetes. If you have any suggestions on a particular problem to be solved, please kindly let me know<p>Thank you and have a good life <comment><USER2> Precache the images in use on all nodes of the cluster, so that respawn is faster, especially for large images

<comment><AUTHOR> Thanks for your suggestion</comment></comment>


'No other option': Climate change driving many to flee Guatemala - <AUTHOR> https://www.aljazeera.com/indepth/features/option-climate-change-driving-flee-guatemala-190512174743893.html <comment><USER2> Population quadrupled since 1960 [0]. Going back 100 years, population exploded fourteen times over, from 1.2M in 1919 to 17.5M in 2019 [1]. Still growing strong, estimated to add another 9M by 2050. Pretty sure none of that population explosion was caused by "climate change".

[0] [https://www.populationof.net/guatemala/](https://www.populationof.net/guatemala/) [1] [http://populstat.info/Americas/guatemac.htm](http://populstat.info/Americas/guatemac.htm)

<comment><USER3> I hate to ask, but did you actually read the article or just instinctively recoil at the mention of climate change?

The article itself mentions the issue of droughts and rising temperature affecting the crop yield, which means less work for the able-bodied workers and less food. This in turn exacerbates poverty issues. More extreme weather conditions also has a compounding effect, which means people migrate to regions not as affected by extreme weather shifts.

<comment><USER2> This is not the first time drought brings down Central American civilizations. Around 1000 years ago, the Mayan civilization collapsed under the weight of unsustainable populations combined with severe droughts [0].

[0] [http://www.bbc.com/earth/story/20160222-severe-droughts- expl...](http://www.bbc.com/earth/story/20160222-severe-droughts-explain-the- mysterious-fall-of-the-maya)

<comment><USER3> This is an absurd line of thought and incredibly disengenous to the fact that many first world nation's are heavily contributing to climate change which results in displacing populations.

You're arguing solely from a population problem which is tangential at best. The issue is that even if population growth was controlled climate change is rendering entire regions unfit for sustaining human life. Why is it OK for a Nation to effectively render another unfit for human life, then turn around and tell people looking to escape to go away? Do you actually have anything to say on the issues represented in the article or do you intend on just spreading FUD?

<comment><USER4> He points out some facts, even provides sources, and your sole counterargument is to call it 'absurd', 'disingenous', etc. Because we can't have anyone doubting the Holy Climate Change.

He's not the one spreading FUD here. You and the rest of the 'zomg world ends in 10 years' gang are.</comment></comment></comment></comment></comment>


Show HN: ESLint must-use-await – flags callbacks and .then() in JavaScript - <AUTHOR> https://www.npmjs.com/package/eslint-plugin-must-use-await?a <comment><AUTHOR> Author here. I'm currently flattening a large codebase with a bunch of callbacks and .then() and wanted to see if I could use eslint to help catch them all. Someone suggested I make it into a 'Show HN' so here you go.

I created this using Björn Tegelund's excellent tutorial: [https://medium.com/@btegelund/creating-an-eslint- plugin-87f1...](https://medium.com/@btegelund/creating-an-eslint- plugin-87f1cb42767f)

I hope fellow ES2017 folk find it useful.

</comment><comment><USER2> Does it have a Github repository?

<comment><AUTHOR> Yep. [https://github.com/mikemaccana/eslint-must-use- await](https://github.com/mikemaccana/eslint-must-use-await)

Gotta add it it to the README.md!</comment></comment>


Ask HN: Browser Extension for Multiple "Contexts"? - <AUTHOR> I usually have a few instances of my browser open (firefox) and try to keep each instance with a related group of tabs. In other words, I'll keep all "research" links open in one instance and work-related links in another.<p>Is there any extension that would allow me to: a) "Name" running instances and separate them into different task bar buttons as opposed to group everything into one? b) Save such instances as "presets" so I can quickly launch them? <comment><USER2> Have you tried [https://addons.mozilla.org/en-US/firefox/addon/multi- account...](https://addons.mozilla.org/en-US/firefox/addon/multi-account- containers/)</comment>


Why Java Will Always Be Slower than C++ - <AUTHOR> http://www.jelovic.com/articles/why_java_is_slow.htm

<comment><USER2> This essay has been around since at least August 2001. [http://web.archive.org/web/20010802062551/http://www.jelovic...](http://web.archive.org/web/20010802062551/http://www.jelovic.com/articles/why_java_is_slow.htm)

It is fairly well-known. I wasn't too surprised when I saw it show up on Reddit recently, but I was disappointed to see it show up here. It's getting harder each day to see any kind of difference between Reddit and Hacker News.

</comment><comment><USER3> Java allows you to write better multi-threaded code etc where as C++ lets you fight with all those details therefore losing productivity for some perfomance, which thanks to multi-cores the slowness comparing to C++ will be insignificant

</comment><comment><USER4> More often than not it is not the language that decides the performance of a system, but the ability of the programmer to come up with sensible designs.

This becomes even more important as parallel and computing becomes more important. Designing and implementing systems that run on a single CPU isn't all that hard given all the tools, libraries and abundance of literature developers have access to at little or no cost. Writing software that spans CPUs and even computers is a different matter.

Writing an application like Twitter isn't hard. Making it scale shouldn't be, but apparently still is. Doing twitter in C++ might offset the problems they experience somewhat, but not meaningfully so.

<comment><USER5> "More often than not it is not the language that decides the performance of a system, but the ability of the programmer to come up with sensible designs."

A lot of people forget that. Most of the software I've encountered that displayed performance problems did so because of endemic architectural flaws and bad code. Pointless complexity usually leads to slow software.

In most well-written applications, you wouldn't be able to tell the difference between a version on C++ or a version in Java, because the software is rarely the bottleneck. Obvious exceptions are applications like games and 3D animation systems, where there's a lot of computation going on all the time.

A well-written word processor in Ruby might well feel MORE responsive than a poorly written one in C++, for example.

</comment></comment><comment><USER6> It is much more interesting to know the performance model of a given language than comparing languages. If you know the performance model, you know what costs, so you begin writing programs that avoid doing expensive things.

And it will always be the case that the clever algorithm or data structure is much better at getting some cycles back than switching language.

Part of the article is also wrong. A dynamic lookup can often be avoided if you have a dataflow analysis phase in the compiler for instance. It is almost "the" optimization for OO languages like Java.

</comment><comment><USER7> Besides being very old, as heroev well pointed out, this is a quite obvious article.

Just like C++ is slower than assembly, which is slower than using microcode, which is slower than coding at the logic-gate level.

It's not that writing Java code is easier than writing C++. The fact is that writing memory leaks is a lot harder in Java than it is in C++.

<comment><USER4> The main difference being that finding the memory leaks in Java, or rather: unintentional object retention, is far simpler than in most C++ environments.

<comment><USER7> that's what I said. "Writing the memory leaks" is, after all, a lot harder in Java (or Python, or Ruby, or Lisp) than in C

</comment></comment></comment><comment><USER8> _Speed still maters. I still wait for my laptop to boot up. I wait for my compiler. I wait on Word when I have a long document._

Ummm, yeah, C++ can magically access the disk faster than Java. NOT!!

<comment><USER9> Last year we've built a storage unit for IP surveillance cameras where we've written our own filesystem optimized for continuous writing with zero fragmentation. We had only 4MB of RAM available and the requirement was to never use more than 10% of CPU, which was as powerful as 386DX (remember those?). These things operate 24/7, mounted on telephone poles, for years, without human supervision.

Yes, in C++.

As a side thought: if Apple were dumb enough to embrace Java instead of sticking to Objective-C, I doubt that OSX-powered iPhone (with a full-sized WebKit) would have been possible. Just look at Microsoft and their Vista disaster, this what happens when you start believing into "megahertz and gigabytes are cheap".

<comment><USER4> By today's standards, your surveillance solution would qualify as an embedded solution and a fairly resource constrained one at that. It would make sense to use C or C++ in that situation: you can afford to spent a lot of effort on a fairly minimal set of features.

The same may not apply for other projects. I for one spend most of my time worrying about IO, availability and how to best take advantage of multiple CPUs and cores. In this, C++ isn't exactly giving developers anything for free (concurrency still not even being part of the language).

As for Java on mobile: there are projects that are going that route. I'd wait and see before I postulated whether this is a good idea or not.

I don't really understand how Vista fits into this discussion at all. In my opinion, Vista is the result of developers being paralyzed by the sheer weight of their legacy code and interoperability with legacy code. Completely different issue.

<comment><USER9> _As for Java on mobile: there are projects that are going that route. I'd wait and see before I postulated whether this is a good idea or not._

I'm sure you've seen "Java: Please Wait..." on tiny mobile screens with famous Java logo (cup of coffee). I am yet to run into "Please Wait: Objective-C..." screen on the iPhone.

<comment><USER4> I wasn't talking about J2ME. In my opinion J2ME is utterly pointless.

</comment></comment></comment></comment></comment><comment><USER10> This essay is bullshit, the author doesn't understand anything he is talking about to the point of absurdity (allocating objects on the stack takes 0 time???) and he largely repeats the common-knowledge on slashdot, as geniuses like this are so often caught doing.

<comment><USER11> Allocation on the stack is changing the stack pointer, space efficient heap allocation usually involves tracing through a bunch of tables to find space. It's the initialization that gets you, especially complex object construction, in either case.

<comment><USER12> umm, for stop and copy and compact memory management, heap allocation is just a pointer increment

<comment><USER13> Exactly. In .NET heap allocations are practically as fast as stack allocations, although of course there are other things you need to be aware of when using a compacting generational GC, such as avoiding medium-lived objects at all costs. .NET does also provide value-types that can be allocated on the stack, and you use them for reasons that are better than "heap allocations are slow".

I think the moral of the story is: to get the maximum performance out of your memory management system, you need to know how it works. This applies equally well to C++.</comment></comment></comment></comment>


Would commercializing the moon help us colonize Mars? - <AUTHOR> http://www.newmars.com/forums/viewtopic.php?f=53&t=8405

<comment><AUTHOR> Those interested in this topic should also check out the organization behind this forum: <http://www.marssociety.org/portal></comment>


Review my startup: Akshell, server-side JavaScript platform - <AUTHOR> http://akshell.com/

<comment><USER2> Very nice what you did Anton. I followed your work from the beginning. There are so much additions in version 0.3.

I see you are using bespin now and you have built a nice Cappuccino based ide. Great job.

</comment><comment> clark-kent Great work. You should list it on the Chrome Web store.</comment>