
Tech Choices I Regret at Spectrum - theBashShell
https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum/
======
stockkid
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.

~~~
j2kun
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!

~~~
sephoric
I honestly can't tell from your comment if that really exists or is satire.

~~~
kbenson
Neither can I. I'm I'm leaning towards it existing but being used as a vehicle
of satire, because that's just how crazy the world is now.

~~~
navs
[https://github.com/necolas/react-native-
web](https://github.com/necolas/react-native-web)

~~~
stronglikedan
I don't know why I find it so funny that the browser's back button doesn't
work in the examples[0].

[0] [https://necolas.github.io/react-native-
web/examples/](https://necolas.github.io/react-native-web/examples/)

~~~
ollerac
Because re-implementing native browser features that are core to an
application's usability is a hard problem that "cutting edge" web frameworks
open you up to?

~~~
ksec
My hope is that LiveView from Phoenix, ( along with some form of Mobile Apps
Default Solution ) would finally fix 90% of what we need without ever touching
/ resorting to what we are doing on the client side right now.

Finger crossed.

------
dlevine
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.

~~~
speby
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.

------
andy_ppp
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.

~~~
threeseed
> 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.

~~~
Swizec
You either die a startup or live long enough for everyone to hate the madman
who picked the stack.

~~~
WrtCdEvrydy
In my case, you either die a startup or end up having to rewrite the whole
thing in React... all 30 years of technical debt.

~~~
fiddlerwoaroof
This is always the best because you get to reimplement misfeatures in your
shiny new codebase because “we don’t want to change how customers are used to
working”

~~~
Swizec
Bug for bug rewrites are best because “You never know what system out there is
relying on current behavior”

------
TimTheTinker
I clicked on this hoping this was the "Spectrum" cable ISP. We don't hear too
often from ISPs and infrastructure companies on HN.

~~~
teej
There’s also an AWS offering called Spectrum and a data enrichment platform
called Spectrum. Pretty overloaded name.

~~~
Junk_Collector
There's also an engineering trade magazine called Spectrum. It's everywhere.

~~~
4thaccount
IEEE Spectrum has been around for a long time and is one of the reasons I
became an engineer. I can still remember tearing into the article on the DARPA
Autonomous Robot challenge.

------
catears
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!

~~~
quickthrower2
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.

~~~
opportune
In my experience staging environments only work in a few (very common) use
cases. When I do big data work I certainly use a test environment but we can't
just replicate all the data in two clusters because that would be absurdly
expensive - and this makes testing performance basically only possible in
prod. I'm sure basically any database system with a non-trivial amount of data
has the exact same issue. But staging definitely works for something like a
web server

------
saagarjha
> 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.

~~~
rhizome
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.

~~~
nostrademons
In a startup, by definition you don't know what you're doing. Once you know
what you're doing, it's not a startup, it's an established business. Once
everybody knows what you're doing, it's called an industry. It's usually
fruitless for a startup to chase after problems that everybody knows how to
solve, because somebody has already solved them, probably better than a small
team of junior developers can.

Experienced developers spend most of their time thinking because experienced
developers tend to work in fields where at least the _problems_ are known, as
well as some best practices for solutions. That's how they got to be
experienced, after all. But this is also why experienced developers, when they
choose to found startups, often end up with B2B startups that slot into an
existing industry structure, not startups that end up defining the industry.

(Source: experienced developer now founding a startup and wrestling with just
how little all that experience matters when it's not even clear what problems
will dominate the industry or if the industry will even come to exist.)

~~~
saagarjha
The tools for making a mobile application is something that I consider to be
"solved", except in some very specific cases. If you are a startup, you are
likely innovating in something that is not making apps, so I do not agree that
you "don't know what you're doing" in this area.

~~~
nostrademons
The article states that the product was initially solely web-based, and for a
good reason: they expected the majority of their traffic to come from content-
based SEO. That's the kind of product insight that can and should drive
technology choices and might drive it away from "solved" mobile development
practices.

(Having used react-native-web for a project once, I also question whether it
actually would've improved things: the HTML generated by react-native-web is
_terrible_ for SEO, and they might never have gotten to the point where they
had users asking for a mobile app if they'd gone this route. Hindsight is
20/20 and often forgets about obstacles on the path.)

------
kodablah
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.

------
skywhopper
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.

------
stickfigure
_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.

~~~
uxcolumbo
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.

------
quickthrower2
RethinkDB, an ironic name in this context.

~~~
smacktoward
At least you can't say they didn't warn you!

------
lxe
Regrets: not using cool new frontend things while using cool new backend
thing.

~~~
k__
It's just a question of risk assessment.

Will the new tech give you leverage over companies who don't use it or will it
be discontinued and leave you with unmaintained crap?

Will the old tech give you a stable base to build upon or will people with new
tech overtake you with less effort?

etc.

------
ppeetteerr
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?

------
chipotle_coyote
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.

------
owaislone
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.

------
k__
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 :(

------
nstart
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](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.

~~~
sisk
Same reason why some folks like Gatsby. Navigate around his site and you'll
see it loads in very quickly and with push state instead of full reloads. It's
been done many times over for every stack and client side tool (pJax!) but
that includes the next.js router.

~~~
jefftk
It's fast, but for a simple site like this I suspect plain HTML + cacheable
CSS would be just as fast.

~~~
kkarakk
who among us who uses react is a css master tho?

------
jessaustin
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?

~~~
mxstbr
You are inverting the reasoning. GitHub bought us because our main audience is
developers. We should have stuck with markdown, because our main audience is
developers, not because GitHub also saw that and acquired the company.

------
Annatar
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.

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

[https://github.com/basecamp/trix](https://github.com/basecamp/trix)

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

~~~
mr_toad
I would have gone with markdown and/or some other markup language. It’s so
much easier to leaverage other tooling (e.g Git), when your source text is a
widely used text format.

~~~
shay_ker
Definitely. Our users aren't as tech-savvy, so we wanted to have some basic
WYSIWYG functionality instead of educating them on markdown.

------
mxxx
Kind of impressive that they built Spectrum with just three people. Nice write
up.

------
wavicle
I created a public community for Hacker News itself:
[https://spectrum.chat/hackernews](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.

------
walrus01
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.

------
andonisus
Was using node over another language/ecosystem a baked-in requirement?

~~~
mhd
A chat application is to node.js what a blog was to Ruby on Rails or PHP --
it's basically the default example of every framework and library. Low
complexity, high throughput. So you'd have no trouble finding good examples
and libraries.

For a while, Erlang was quite popular in that area, but as some orgs only used
it for that and thus didn't get too deep in the tech stack, they were eager to
switch to something they imagine they know a bit better.

~~~
k__
Erlang had the problem that it got more popular at the same time as the rise
of Go happened, which also played the back-end-concurrency game.

------
Tehchops
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.

------
pjmlp
Interesting read, as always the business value is the one that should be
assessed for technology adoption, not coolness factor.

------
fourstar
What would you replace Draft.js with? Slate?

~~~
wes-k
We went with ProseMirror for [https://wikiful.com](https://wikiful.com). It's
probably the most powerful but is also not a plug-and-play setup and required
a handful of tweaks.

If I wanted a lighter solution, I'd probably give [https://trix-
editor.org/](https://trix-editor.org/) (made by basecamp) a try.

------
honkycat
Rethinkdb was complete trash. A bane to run and pathetic at scaling.

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

~~~
habitue
A bane to run? Like what happened when you ran it?

~~~
honkycat
Constant slowness and down times. Bad logging that did not provide enough
information. Database backups would take an ETERNITY to dump, and even longer
to restore.

We once had a 5 machine cluster. We decided we needed to re-balance the
cluster. The thing COMPLETELY CRASHED and went up in flames, caused us to have
to stay up all night fixing it.

It was the same day we decided to rewrite our application to not use
rethinkdb. Best decision we could have made.

------
aboutruby
The examples are quite interesting but the insights / conclusions are far too
simplistic and overreaching

------
dirtylowprofile
Seems like bad choices and lack of research.

------
matte_black
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.

