back
122 comments
It seems contradictory to me that author learned to "deliberately assess cutting edge technologies, bias towards conservative choices," yet he regrets not using react-native-web and Next.js.
I find the regret for not using Next.js to be interesting, because I don't think it would have been a particularly good fit anyway.

I've built an relatively high-traffic SSR'd React website from scratch, and I've done the prototype for the rebuild of the website at work (we're moving away from Gatsby). The reason I'm considering Next is precisely because what i'm building isn't a "web app" like Spectrum, but merely a website (with some e-commerce features).

The sweet spot for Next.js seems to be that you're trying to make something that resembles a traditional pre-React-era website in structure, but just happens to be built using React. Once you're building an app, it doesn't feel like the best tool for the job. You can obviously bend Next to your needs, but fighting the framework is the last thing you want to be doing in the first year of a startup's life.

They managed to get an exit, which is a great result. And obviously they've learned a lot in the process which is another great outcome. But I can't help but feel that having just one experienced engineer on the team would have made their road a lot less bumpy.

Wait until the author hears about react-native-web-native, the go-to solution for using your react-native-web components in a native environment!
I do not think author contradicts himself at all.

If they would have used react-native-web, he would have saved some time writing the Android (or IOS) apps. Because he could have reused the code (he said that too).

This is what I have done, anyway. Also react-native-web is very very high quality library. I am just amazed at the quality Nicolas Gallagher is putting out.

My app now runs on web and via browser on android/ios with all the magic of responsive UIs, reshaping all those positions when a user rotates the screen or zooms out.

I am wondering, on occasion why I spent time on native apps (even with React Native) -- at all, as React Native Web (with a bit of React-bootstrap) -- are just amazing.

Wrt next.js, at least when I looked at it mid last year, did not support routing with React-router. And for me it was a big deal, I did not want spend time on learning specifics next-js routing.

Instead I went with https://github.com/jaredpalmer/razzle which supports React Router for routing, which I use Android/react-native and React-native-web, uniformly.

React-router, is also very good and useful library with nice, intuitive architecture for routing.

At the end, I decided for my need the Server Side rendering is a later-stage item. So I have not spend more time on it.

I suspect Spectrum did not loose much traffic because their app is not using SSA routes.

Zulip chat app (may be they are spectrum's competitor, not sure) - uses React Native for mobile (https://github.com/zulip/zulip-mobile ), but something else for web. As a reference.

I wouldn't trust any 'open source' project which has received funding from investors (especially early stages) - These projects are almost always hype-driven. They're popular because the team is good as social networking; they mostly leverage their blogger friends to do writeups and spam tweeter until people believe it.
React has become the most popular way to build front ends that are interactive. Many sites still need rendering on the server side for SEO purposes (CSR and SEO do not mix). So when your content needs to be highly indexable but has many interactive elements SSR react seems like a good choice. In this scenario, Next.js is the most "standardized" choice.
I think that the most important line in this article is "Changing these decisions would not have made Spectrum a better product by itself."

Assuming that you make somewhat reasonable choices in the first place, technology likely won't become a problem for quite a while. At which point you either have succeeded enough to have the resources to fix the issues that come up, or else you have bigger problems than technology and should focus on those instead.

I really love that you pointed this out. This is why things like getting wrapped around the axle deciding between React or Angular for your next project and "which is better?" type of decision-making frameworks that engineers often get stuck in miss the point. More often than we can appreciate, pick something, anything (!), and move forward.
Making mistakes means the author delivered a lot of features to users that they wouldn’t have otherwise.

RethinkDB sounds terrifying though, I’d hate for my DB errors in production to literally have no idea what to do, it makes me feel sick thinking about :-)

I think we should aim for kludgy but boring working solutions first - for example I’m tempted to write a redux middleware that sends dispatched actions to the server and manually sync, order and manage conflicts in these events to build a “perfect” system where front end state management and backend CQRS perfectly marry up. It’s a terrible idea because I know how to build the Podcast app I’m making perfectly well without any of this nonsense.

For me, the fact that "They allow you to listen to live updates on (almost) any query." would've been a huge yellow (red?) flag. If your database tech does this_amazing_thing_that_nobody_else_does, you'd better be goddamn sure you understand the reason why nobody else does it, AND understand what are the compromises that this brand_new_tech did in order to support that. You probably pay somehow for that amazing feature - what is the cost, really?
> I think we should aim for kludgy but boring working solutions first

Nice idea in theory. Can be awful in practice.

For example in enterprises it's very common to see applications last years or even decades. And so that kludgy but boring solution would be the foundation on which you will have hundreds of engineers and years of work built on top of. And because your kludgy but boring solution worked in the beginning you rarely go back and redo it.

Hence why you see a lot of upfront developers built these over-architected monstrosities. It's because they are trying to cater for a decade of possible new features.

Think about the use-case where you want all your Relational data to be denormalised and written to a S3 bucket and then loaded into something like Redshift for analytical loads.

If you start pushing the data from your application itself then you introduce the problem of dual-writes (what if S3 write failed? what if RDBMS failed?).

If instead you treat your RDBMS as the source of truth and use something like PostgresSQL's logical decoding feature to listen to the replication stream and then push the events from that stream to S3 you can achieve guaranteed-eventual-consistency.

The best way would've obviously been to make your application write to a Message Bus (Kafka etc.) and then some other application would persist that message to your RDBMS. This approach requires more development effort and introduces all the issues that distributed systems face: Read your writes, read follow writes, write follow reads etc.

> front end state management and backend CQRS perfectly marry up.

I am currently researching how to do this properly. What would you think would be the "boring but reliable" way to do it?

I clicked on this hoping this was the "Spectrum" cable ISP. We don't hear too often from ISPs and infrastructure companies on HN.
It would be quite cathartic to read an apology for the shitty software on cable boxes.
Thought that it was about ZX Spectrum by Sinclair.
There’s also an AWS offering called Spectrum and a data enrichment platform called Spectrum. Pretty overloaded name.
For a reason.
I am right now on the train home from work quite late (22:40 local time). The reason I spent so long at work today is because we update after 8 o'clock. However, we found a critical bug in some open software that we use that we do not know why it triggers. We barely even know how it happens! Of course we haven't been able to solve it yet... After personally spending a lot of time with trying to fix the software I can say that I have gotten a much deeper appreciation of tools that are widely used and with an active community, where most bugs have already been solved.

Previously I had believed if you had a tool that solved the exact problems you have, then you should use it. I hope I'll resist such an urge in the future by having a little pragmatic angel on my shoulder reminding me of the danger of underused software. No software is perfect and even tough you might be able to fix software when it is open source, you paint yourself into a corner when you will necessarily have to fix it.

I felt my experience was matching some of the authors woes and I urge anyone that chooses technologies to think one step ahead and learn from our mistakes!

To avoid burning out I suggest:

1. Deploy

2. Test deployment

3. If success, great go home at 8:10pm.

4. If fail, rollback, retest, go home at 8:20pm. Come in next day and fix in source code and schedule new deployment.

5. To avoid #4 in 99% of scenarios, use a staging environment.

> We are building native apps now, but starting from scratch is time consuming. If we had used react-native-web to build the website, we could have reused the base components and built the native apps much faster!

> Optimize for iteration speed and flexibility.

Faster, but not necessarily better. Reusing web technologies for mobile is almost always an optimization for developer time, which might work early but I feel almost always ends up needing to be rethought in the future.

I think it's reasonable.

React-Native uses native widgets and doesn't bring too much Web tech.

You can still replace screens with native modules later if they don't perform well.

If you start, you need to get something usable out of the door quickly before you run out of money.

The phrase "optimize for iteration" feels like something you do when you don't know what you're doing. They say experienced developers spend most of their time thinking, vs. writing code, and so with inexperience you don't have the tools to eliminate iterations in your head.
On the side I'm building a communication app myself and I've started over a few times now. I made some mistakes in early development that caused starting over to be the best choice (I'm not a perennial start-over guy, things weren't very far along when I restarted, this is just a side thing).

Mistakes: I did plenty of backend work (e.g. gRPC services) just to realize it didn't mesh well with the frontend when I started to build it. I over-complicated the feature set and realized I built a foundation for an MVP that would take forever. I abstracted everything because in my head I thought about all the future uses. I worked on an advanced-tech frontend that kept me bogged down in frontend development instead of doing the whole thing. All of these are typical mistakes of pie-in-the-sky side projects sans deadlines.

For the latest iteration I have changed my approach. I am building the dumbest web UI w/ the dumbest in-memory-only-at-first backend with minimal abstractions. The initial web UI doesn't even use any JS which I know can seem like extra work w/ HTML forms and the like, but the raw simplicity is easier to build now and take away later than something more complex. I'm deferring lots of features. Once I reach a web-UI-only MVP, my next step will be to abstract what already isn't on the UI front and make a Qt app that uses the same abstraction. I've found this to be the easiest way to get some UI idea reuse across different paradigms. I can add more UIs including an API, terminal, mobile, etc with this approach. For the backend, simple gRPC backed by a "db" of in-memory data structures for now until I abstract that to allow sqlite to join and then on from there. It is very refreshing to develop a full-stack app without a complex full stack. The major benefit of developing a stupid-web-with-in-memory-db MVP? Testing and quick iteration. I've found you can iterate on core structures/ideas or you can iterate on external tech/features, but you can't do both at the same time.

I feel like they missed a couple of critical takeaways: First, build on technologies you already understand, if possible. Don't build from scratch on something you know nothing about. And second, make sure you have some backend expertise on your team. He says up-front the three person team was heavy on design and front-end expertise. So it's not surprising at all to me that they had big problems managing and troubleshooting their poorly chosen backend tech.
A great mobile experience on desktop is bearable and only needs tweaking to work well.

That depends on your product and your audience! Many (probably most) B2B apps work poorly in the constraints of mobile. If your users spend their 9-5 hours buried in your app at the office, they probably value things like hotkeys, multicolumn layouts, and high-information-density pages.

Great point and I can confirm this. Working on enterprise apps in the past and seeing design teams choosing something like Material Design for those web apps, even though it's not suitable for those apps, especially because the information density is poor when using MD.
That is a great point, thanks for making it. You are absolutely right, I was overgeneralising with that lesson!
RethinkDB, an ironic name in this context.
Regrets: not using cool new frontend things while using cool new backend thing.
Not using something seems like a hard case to make. The author doesn't know what would have happened had he used another tool. However, I do believe it's possible to properly evaluate a tool after having used it, so... 2/4?
I admit I'm hoping (although not remotely expecting) that now that Spectrum is part of the GitHub/Microsoft nexus, they'll contribute some development time to getting RethinkDB going again, even if it requires another fork -- there was a brief "RebirthDB" fork that was, theoretically, going to become the official release, but that seems to have stalled, too. The 2.4 release has been "nearly ready" for over two years now, and I'm kind of afraid that the lost momentum will be unrecoverable very soon, assuming we're not already past that point.
RethinkDB was so promising and still is in a way. It just didn't take off as an open source, openly government project (yet). It's still early though. I hope it forms a great community around itself and becomes a major open-source database offering. Apache or CNCF adopting it wouldn't be the worse thing ever even though not a super CNCF like product.
I worked at a startup that used RethinkDB too.

Change feeds sounded cool, but we never used them in the end, because of the latency.

I didn't use react-native-web, because back in the days it was alpha and later there was react-native-dom, which seemed like a better approach, but I have the feeling it doesn't have much pace to get anywhere any time soon :(

This is tangential/possibly off-topic. I was wondering if anyone could educate me as to why this site needs to use next.js in the first place (the site of the blog, not spectrum). It's mentioned in this blog post and I followed the link. The full tech stack is given here -> https://github.com/mxstbr/mxstbr.com#tech-stack

I went through the codebase, and the content itself is static. I'm not attempting to bash the decision to use next at all. I'm only looking to grow my understanding of the usage of next since I see it being mentioned a lot.

The question I have is, why use next/react for what appears to be a static site. Or, why not use static html + markdown?

Again, not bashing. Just looking for reasons that I might have missed due to my lack of understanding/context.

Some of these seem difficult to predict. If you knew in advance that Github would acquire, WYSIWYG over markdown wouldn't have been a priority. You couldn't have known that, however. Developers know markdown, web creatives know markdown, but does anyone else?
Summary: "computers are hard, getting the software written correctly even harder". Yeah, that's right! If you're struggling with this, it time to seriously consider another profession.

Barrier to entry being low is really misleading. It never was low and because of how generic and complex computer systems are, it isn't low now. It will only get more complex as time goes on, unless everybody pulls together and fights tooth and nail to go back to writing small, fast software. Anybody considering "I just want to program and not worry about low level details! Which framework can I use?" should stop dead in their tracks and seriously consider what they are doing with their life.

I ran into similar issues with Draft.js, but Trix has been amazing:

https://github.com/basecamp/trix

It's not that hard to wrap it as a React component and get going with it

Kind of impressive that they built Spectrum with just three people. Nice write up.
I created a public community for Hacker News itself: https://spectrum.chat/hackernews

Something that I have always disliked about HN is the lack of the ability to delete comments and accounts. OTOH, Slack etc are private and lock up good content/discourse away from search engines. Hopefully, spectrum will offer a better balance.

The name "Spectrum" has regrettably been ruined by Charter, which has the same poor and indifferent customer service for last mile cable internet customers as other competing giants like Comcast.
Was using node over another language/ecosystem a baked-in requirement?
Seems like some pretty domain-specific(frontend)choices about which $jsThing to use, and one pretty bad operational miss on choosing a DB tech correctly.
Interesting read, as always the business value is the one that should be assessed for technology adoption, not coolness factor.
What would you replace Draft.js with? Slate?
Rethinkdb was complete trash. A bane to run and pathetic at scaling.

Small backups took hours. It was extremely difficult to tune.

The examples are quite interesting but the insights / conclusions are far too simplistic and overreaching
Seems like bad choices and lack of research.
Way too many developers are shocked to learn that Postgres has an existing Pub/Sub system using LISTEN and NOTIFY. Kind of makes some people rethink their stack.