I’ve been a remote engineer for over a decade, but only recently switched to a hybrid schedule on Tuesdays and Thursdays. IMO, these two days are effectively useless for any kind of productive technical work. There are simply too many visual distractions, interruptions, and a complete lack of comfort in an office.
…But I do enjoy these in-office days for what they make up for in remote work: Face to face chats; Real time human bonding; A sense of place. The office is just a socially accepted excuse to get everyone out of their homes and together for a few hours.
I’m especially grateful that our cofounders understand why we should actually be at the office, and that any expectation of “being more productive” is nothing more but a polite fiction. Ironically, our two days in the office are mostly spent just outside the building. Technical chats over lunch, 1 on 1 meetings as a walk around the neighborhood, and drinks in the evening. That’s what hybrid should be. I’ll send my pull requests at 3 am while in my comfy chair at home.
As for the commercial real estate market, I truly believe they’re fucked in the long run. There aren’t enough jobs like my Montessori arrangement that justify all the buildings in their portfolio. Hell, we couldn’t even go back to full-office because our team is so distributed!
Personally, I think this is commodification coming back to bite short-term economics applied to financial districts. We don’t need a Chipotle on every corner. We don’t need another $20 box salad store.
We need neighborhoods that people want to be in for reasons other than work!
I’m guessing that in the coming months there’s gonna be talks of a real estate bailout. Investors have entwined their holdings into everyone’s retirement plans, and will no doubt appear on the nightly news wearing a vest made out of dynamite. They will threaten to take us all down with them.
Such a shame that they’ve over-leveraged their position. Did they forget that we already have nothing to lose? The irony will be lost on them.
> a Large Kroger or Walmart then expensive food and limited options from a corner NYC style "bodega"
There’s a lot in between those two extremes.
My favorite neighborhood I’ve lived in was on the Northside of Chicago where I had a medium-sized, independent grocery down the block on the local arterial road and a neighborhood of single family homes in the blocks surrounding it. The arterial roads have commerce, and the side streets have homes. You can walk, you can drive, take transit.
> I dont want to walk anywhere but from my front door to my car
Neighborhood stores will not have the volume to support a 100-300,000 sqfoot store, with all the selections I get at my local supermarket that services many many neighborhoods
Grocery stores around the corner do not work in spread out neighborhoods because the Krogers/Costcos/Albertsons/Walmarts will be able to offer lower price due economies of scale, and anyone with a car will choose to drive 10min, or stop on their way home, to save money rather than go to the higher priced grocery store around the corner.
Do you think larger grocery stores don’t exist in city downtowns?
I searched for Whole Foods locations and they seem to have about 13 in Manhattan itself. There’s a Costco in Manhattan. And there are several other major grocery stores some unique to New York. There are also large independent grocery stores and independent online grocery stores that will do hourly deliveries (the 15 mins deliveries thankfully seem to have largely died out).
And that’s before you get to the hundreds of farmers markets.
And how about all the butchers, seafood stores, cheese shops, spice stores, etc.
And then you get the international grocery stores with Korean, Japanese, Indian, Chinese grocery stores.
Ah, and you have 24/7 bodegas on newrly every corner if all those don’t work for you.
They work in Manhatten because of population density, the grand parent clearly said they do not work in "spread out neighborhoods"
So now we are shifting the goal posts from "walk-able neighborhoods" to walkbale high density neighborhoods. Not only do I oppose walkablity I also oppose High Density, I like my Single Family home on .75 acres of land or less.
I do not want to live stacked on top of others, if you want that stay in NYC. thanks
>…But I do enjoy these in-office days for what they make up for in remote work:
>Face to face chats; Real time human bonding; A sense of place. The office is just
>a socially accepted excuse to get everyone out of their homes and together for a >few hours.
>
>I’m especially grateful that our cofounders understand why we should actually be
>at the office, and that any expectation of “being more productive” is nothing more
>but a polite fiction. Ironically, our two days in the office are mostly spent just
>outside the building. Technical chats over lunch, 1 on 1 meetings as a walk around
>the neighborhood, and drinks in the evening. That’s what hybrid should be. I’ll
>send my pull requests at 3 am while in my comfy chair at home.
I feel like these sorts of things are part of "being more productive" though. Having a good rapport with your co-workers, having a chance to talk about side things, having a chance for people whose domains don't normally cross to hear what's going on elsewhere. These are all parts of being a well functioning and productive team. It's a real shame that larger organizations tend to lose sight of that, but it's also a shame in my opinion that this whole fight over remote vs in office work has gotten the workers pretending that nothing but the numbers matter. This really feels like a "be careful what you wish for" moment.
> I feel like these sorts of things are part of "being more productive" though.
Yeah.
There are some things which can be more difficult when you’re remote. Working through a design—it’s so much better when you have two people in a room with a whiteboard or paper. Onboarding. Going through a gnarly code review (where you really want some major changes to the code before it gets shipped). Debriefing after a meeting, where you and your teammate know that the meeting was a complete waste of time, but you need a chance to kvetch about it offline and off the record.
Our company does regular meetups throughout the year. No need for a hybrid schedule really. We are all located throughout the US. The company pays for all expenses for those that choose to visit on site. This is without limits or restrictions. It STILL costs them less than maintaining a large office in a popular metro area. I see my coworkers a total of maybe 4x a year. We also have regular 'shoot the shit' Zoom meets. That is honestly enough interaction for me.
As an autistic person with ADHD, office environments are 'difficult' to say the least. Thankfully I've been fully remote for about a decade as well. Wouldn't go back, and thankfully I don't need to. There are plenty of remote jobs available and I don't see that changing short of some type of short-sighted government regulation.
Smaller companies have realized that office space and the infrastructure to support it is a huge money sink compared to just having employees work from home.
> We don’t need a Chipotle on every corner. We don’t need another $20 box salad store.
These are the only types of business that can afford the rents though. Even if you get another lower cost place in there, they have to cut corners on quality and end up going out of business or just being really bad food. How do you overcome that?
Easier said than done. Limited space == Higher rent.
People are downvoting me, but not really understanding what I'm saying. Even if there is more empty space, what is happening is that landlords are leaving them empty, which keeps the rents higher because there is still limited effective availability. They aren't going to rent to a small business because they don't want to get locked into a 5-10 year lease on a small business when they can potentially wait a bit and rent to a larger business who will pay more and likely survive longer.
Space may be limited but it's not utilized. In my local metro's business district around 60% of storefronts are sitting vacant and yet rent for these spaces is still astronomical. And it's been that way since 2020. The push for a return to the office is a clear cash grab.
It is also because loans are still locked in to ZIRP-era rates. That keeps the cost of capital low and businesses that own those properties have a lot of room for them to be wildly unprofitable. It will take awhile for those loans to roll over to higher rates.
Retail rent will fall because nobody is in the offices. Retail business will close because of less traffic, and thus there will be more space.
But, retail leases are typically 5-10+ years. Why would a landlord lower the rent now to a small business and get stuck in a long lease, when they don't know if the office space will recover and the big businesses will want to come back?
A lot of those five-year contracts were negotiated before Covid and I suspect they will expire in the next year or two. After a certain point, the building owner will have to choose between lowering rents, or having the building foreclosed on due to having no tenants.
Also, at the beginning of Covid, several big businesses just refused to pay retail rent as a negotiating tactic. It would not surprise me if that happens again.
Except that isn't their only choices. It'll depend on their finances as well as the market futures. Many many buildings sit empty for ages for a whole bunch of different reasons. Can't just generalize into a binary like that.
given the choice between no money and money, most will choose money, and no amount of 'it depends' will change that
the fact that some people let some buildings sit empty for some time doesn't mean most will let most sit empty for most of the time
after all, the next best alternative for building owners is foreclosure or abandonment or sale at a loss, the next best alternative for businesses is 1 of a thousand different places, or just a remote workplace
> Nobody is going to rent ground floor retail space in an area with no foot traffic
of course they will, at a low enough rent, obviously, which is the point: lowering rent is indeed a choice, as is going bankrupt, abandoning the property, foreclosure, or selling it at whatever price
One more reason I just came across for you... maybe nobody wants to open a store in Gotham City and no amount of free rent can convince them otherwise...
instead of trying to make the conversation about me or you, and instead of citing maybe-true singular anecdotes which don't prove your case (that space is limited, and lowering rent won't increase rentors), try just presenting the aggregate data showing that commercial landlords en masse have lowered rent to a dollar and still have these vacancies
WAIT!!!
Wait.
I fear what you heard was, "argue about your anecdote some more", but what I said was, show us the data
Well the space is not limited anymore, as the commenters suggest. The natural progression is for rents to go lower.
The problem is that would mean that the valuation of the real estate would need to change, which would imply debt repayment, and given higher interest rates:
default or finance under onerous terms or being cash rich already.
At the end (as the Fed expects): defaults => lower real estate value ^ rents => cheaper food options.
And that is where usually executive is going to come in to save Government Supported Real Estate (GSE), and throw a wrench to Feds approach.
tl;dr: the government supports this situation it will come to make it worse once again /s.
Less people in office buildings means less foot traffic to stores, which means less fewer stores will be enticed to rent.
If nobody's renting, eventually the owners and investors will have to realize some rent is better than no rent, even if it means they are going to take a loss.
That doesn't mean the people will come back to support those businesses though. In the case of SF, since there is only office space downtown and almost zero housing, this is going to be a problem of finding tenants than it is about lowering rents. Who's going to want to open a retail space where there is no foot traffic?
The usual solution to that is that someone (maybe the owner of many buildings in an area) finds several tenants to open at the same time, and thus tries to produce a retail destination. So no one wants to open a bar near 30 empty offices, but if I tell you I am getting 4 restaurants, 3 art galleries, another bar and a theater to all open in the same area than you all can feed off each other. Or instead of a lot of little things, tries to get one big draw to open. You can imagine that opening a bar next to a movie theater is better than not near one.
I opened a night club on a block in SF that had lots of other bars. Unfortunately, we also picked the one spot on the block that was also next door to a liquor store.
I can't tell you how much that cost us because people would just go next door, get a small bottle of something for cheap, down it while they were out on their smoke break and then come back to the show in my place.
I can see how that's bad placement. Did you try a cover with no-reentry to at least cut down on that?
But, yeah, it can be harmful like that or positive in that maybe there are restaurants next door where people eat before they come to your bar for drinks and a show.
> I’m especially grateful that our cofounders understand why we should actually be at the office, and that any expectation of “being more productive” is nothing more but a polite fiction.
They sound like great leaders. I also work for a great company which is very pro-remote work.
I have been working from home for several years before pandemic. I lived near office, so every once in awhile I would go in to take a break from programming and socialize. It is great for those purposes especially once you are out of college, it is really hard to make new friends. And this is the one aspect about office work that I miss. But it is not a company's job to provide friends.
Also I realized people who lacked real skills but were good at socializing were the ones who went to office often and they were the ones who were climbing corporate ladders faster.
And I have tried hard to understand why return to office is good for business but don’t see any point. Only explanation that makes sense to me is that people who are good at politics are having hard time playing politics in remote world. They have no other skills, technical or business. But they have already climbed corporate ladder and feeling powerless. Now they need people in offices for their personal benefits, not for company’s.
Not being forced into an office n times per week has allowed me to work from different parts of the country including Hawaii for over a month. This beats face to face small talk and $25 food court lunches beyond measure.
I make sure to socialize on zoom in every call, my focus is through the roof as well as my productivity.
When I ran a remote team on the opposite coast, I'd visit once every 3-4 weeks for a week at a time.
While we'd spend time working, we'd also plan things like field trips (hiking, kayaking, museum visits), we'd go out and get lunch and dinner, bring our Switch consoles and have Mario Kart tournaments in the conference room, and other things like celebrating birthdays, births, anniversaries, and so on.
For remote teams, using the together time to focus on productivity and work is a broken model. Glad that your founders get it!
> Hell, we couldn’t even go back to full-office because our team is so distributed!
Isn't this a problem even for coming into the office 2 days a week?
My experience is that I work on a team which is really distributed. We have people in nearly every continent (including Africa and South America, but not Antarctica), so getting to an office 2 days a week is not an option. We have regular video conferences though.
>>But I do enjoy these in-office days for what they make up for in remote work: Face to face chats; Real time human bonding; A sense of place.
Every-time I am in the office I remember a scene from the west wing where the quote is "He thinks decisions are made in meetings...." expressing that most decisions are made in informal discussions in hallways, or impromptu mini-meetings standing in someones office door. Meetings are where we tell everyone the decisions that were already made
It is hard to replicate that in a remote work environment, maybe that is better I dont know, but for I see the advantage of both
> I’ve been a remote engineer for over a decade, but only recently switched to a hybrid schedule on Tuesdays and Thursdays. IMO, these two days are effectively useless for any kind of productive technical work. There are simply too many visual distractions, interruptions, and a complete lack of comfort in an office.
>
> …But I do enjoy these in-office days for what they make up for in remote work: Face to face chats; Real time human bonding; A sense of place. The office is just a socially accepted excuse to get everyone out of their homes and together for a few hours.
This is why we've switched to a full week every month, which amounts to 1 - 1.2 days per week of presence. This week is used for planning, discussions, more complex knowledge sharing. We've just found it more effective to plan some things with post-its and a whiteboard. Sure, things like Miro exist, but if you combine the friction from the wonderful video call solution teams, miro, microphones, internet uplinks and such, it becomes a real distraction.
But yeah, during these weeks, we don't do much technical work beyond keeping the lights on and pushing the simple service requests through the queue.
> I’m especially grateful that our cofounders understand why we should actually be at the office, and that any expectation of “being more productive” is nothing more but a polite fiction.
I presume the interactions and such you describe increase your net productivity, much as taking the time to study something does. Neither show up directly in Taylorist metrics like “PRs closed”
I'd say it's productive it the sense that creating in person relationships has a direct effect on getting things done that require large amounts of people.
Controversial but brave take: I think adding this to JavaScript is a bad idea. It’s not that observables are inherently bad. It’s just that they produce some of the least intuitive code imaginable. I’ve never seen a codebase with observables where I didn’t question the engineering team’s technical motivations. The three horsemen of unmaintainable JavaScript have always been generators, RxJS, and Redux.
I can’t quite find an accurate metaphor to describe my experience with these data design patterns, but the first that comes to mind is “Hollywood accounting.” It’s always the same hat trick. Take a straightforward task of single directional data flow and subdivide it up into a Haskellian map/reduce game of musical chairs.
Don’t get me wrong, I understand the importance of having observability in data streams. But we already have them via the ReadableStream and TransformStream APIs. Combined with native proxies and we’re just about covered on the use-cases described in the examples section.
I’m also suspect of the lack of insight in this explainer on why the two previous proposals were rejected. We need more concrete evidence of why an additional API should be the answer to the question of whether there are too many competing observable frameworks. This isn’t a jQuery or Bluebird Promises scenario where the observerable paradigm is so entrenched in contemporary engineering, or even that a sizable amount of software development would require a third-party library to fill in the gap.
JavaScript has many missing features. This is not one of them.
As someone who has been using rx since 2014 (with a heavy heart) I must agree with you here. 9 out of 10 times there’s a simple, more boring way of solving the problem. I want boring in my life. Boring is good.
The idea that reading code is harder than writing it can take an extreme form with this style of coding imho.
(My other issue is that for me FRP style code, esp. with rx, is just so much fun to write.)
> It’s just that they produce some of the least intuitive code imaginable. The three horsemen of JavaScript have always been generators, RxJS, and Redux.
It took the author of RxJava months to understand the concepts. And he had the author of Rx.Net to explain them to him [1]
It's also strange is that what we realy want is Excel-like reativity. But instead we're always getting Rx-like reactivity.
A time ago I had a project where we had an intense tree-like data structure where at any given level there may be a finite async-stream. Basically recursively needed to await streams until they finished.
I was using for RxDB based on RxJS, so after a couple nights of banging my head I went into the RxJS chat and asked for help. One of the maintainers of the library who worked at MS said it was a perfect problem and I think I nerd-baited him into helping out...
... we ended up spending like a week on it going back and forth, and neither of us could figure it out. The code we ended up with was frightening.
I don't think that the problem is that JavaScript may or may not have this feature, it's not even that the language is large and all-encompassing; it's that mixing and matching features is highly appealing and very rarely works out well in practice.
JavaScript is not really a single language built around a single specific style or set of needs any more. In this day and age it's an amalgamation of different techniques and styles. You've got classic inheritance and composition for your OOP crowd; you've got your map and reduce for your functional crowd; you've even got your observables for your reactive crowd.
This is all well and good, but I've found that it's hard to write some practical code that blends styles. At some point it's tempting to start adding types, generics and dependency management into a functional project, but it's my experience that this blending ends up getting in the way of itself. Similar story for wanting to do things like having a service that listens to queues in an async way with sync rest APIs. It seems like having a common set of middleware would make it easy to support both layers; however this is easier said than done. These things sort of work but it feels deeply unsatisfying, requiring constant switching between observable and async/await styles with error handling being a constant concern.
I tend to agree. Observables are incredibly powerful, so they seem like they _might_ be a good fit for some use cases where you're dealing with streams of events. And even then, you have to be really determined to not make a mess. For day-to-day event handling, they usually feel like overkill and become really difficult to understand. Like, I don't _want_ to use map, filter, etc to handle non-iterable stuff. It feels clever and cool on the surface but weird and brain-knot-inducing once you look more deeply at it.
The way they show off observables here is solves a lot of problems, but despite offering up Svelte as an example of observables, it doesn't seem to aim to solve the problem that Svelte stores do.
What I really want is a trivial way to say "fire this callback whenever this variable changes."
Mobx actually enables this w/o too much work, and Svelte stores are a really nice syntaxical wrapper around the concept.
Heck just give me what C# had back in 2002 and I'd be happy.
> fire this callback whenever this variable changes
Ouch, welcome to callback hell :(
Futures would be slightly better. The least painful approach to things like that. to my mind, is an explicit event loop, and posting events on a change.
Been there, helped design an entire embedded runtime based[1] around it, didn't mind it.
FWIW Eventing systems are not the same as callback hell. "Tell me when this variable changes" is the heart of a lot of really well engineered systems, including high performance hardware IO. (Fill this buffer w/o bothering the CPU, when the buffer is full, call this function to process its contents).
Eventing systems are nice.
> The least painful approach to things like that. to my mind, is an explicit event loop, and posting events on a change.
That is how Windows works under the covers.
Events are just syntactic sugar on top if that, in replacement of a giant switch/case statement.
My experience has been a total opposite. I've been able to deliver quite complex features in a couple of lines of vert readable code thanks Observables. Of course, you can write terrible code with it, but the same goes for every technology.
I think that this presentation from Netflix engineering team is still the best demonstration of how productive you can be wit RxJS: https://youtu.be/FAZJsxcykPs
Maybe it's because I work on embedded system where I only have to worry about a single process, but I find observables really ergonomic.
"If/else" are a core construct in programming languages. Observables add "when", which I think is just as essential. Whenever someone describes an autonomous system, they will use "when X, do Y". So it makes sense to me that code follows that.
A lot of the time I just want to write a piece of code that and plug it into the system without having to worry about coupling or its effect on other parts of the code. Most of the time I don't have clear requirements, and need to stay flexible.
For example, new requirement to turn off the LCD after X minutes of inactivity, and turn it back on when the user presses a button? I just create a new component (instanced based on a configuration flag), plug it into the event bus reacting to ButtonPress events, and call it a day, without having to worry about something else breaking, often without even having to read existing code (except how to get notified of the event).
Even when modifying existing code, it's easier to replace an event, easy to find which components are depending on that event, etc.
> It’s just that they produce some of the least intuitive code imaginable.
I agree because I have seen this a lot.
> JavaScript has many missing features. This is not one of them.
While I do agree that abusing Observable might leads to messy code, it's very valuable in highly interactive apps. It provides proper abstraction/algebra which letting you tackle problems like tripple click, which might be extremely tedious to solve otherwise.
And interactivity is one of the natrual thing modern browser should empower developer to achieve (at least for non-die-hard no-JS person).
> But we already have them via the ReadableStream and TransformStream APIs.
I do appreciate that you appreciate simplicity and this sentiment in general. But I feel similar sentiments that led JavaScript to stagnent for a long time (ES6 is just ES4 but more than a decade later).
People like Douglas Crockford found the parity in JavaScript and Lisp, and summarized the beauty in his works. While his book is one of my favorite programming book, the sentiment (JavaScript don't need features because of closure, Lisp-like and all that) was so popular at time, which probably contributes to the stagnant.
(Microsoft and friends was probably happy about this that the web wasn't taking over so fast and they can shit everybody with IE6 for years, and then the mobile and their walled gardens were taking over. In other word, the web had even greater potential in between IE6 and mobile era)
People could really try re-implement their React apps without modern tooling to feel the pain: No ES6 module and abuse closure then cat the all files into one giant ball, only to mess up the order and dependencies. Or without reactivity, updating states everywhere which leads to confusing bugs that making apps out of sync., etc
> The three horsemen of unmaintainable JavaScript have always been generators, RxJS, and Redux.
Redux produces the easiest to follow code when following best practices. It’s boring and works extremely well for its purpose.
Generators may get a bad wrap but async/await are just generators with a different syntax — at least in js land. Would you argue the same for async/await?
I’ve seen this comparison to async/await a few times and I’m not sure how accurate it actually is. It’s true that async functions can be polyfilled via generators, but from what I understand that’s more of a conceptual transpilation by tools like Babel, rather than a runtime implementation.
IMO the `await` keyword is clever abstraction that can make asynchronous code easier to understand in a synchronous way. And unlike the collection-oriented ceremony of generators, calling await on an expression doesn’t imply anything more than the presence of a `then` method on an object.
Anything with a `then` method can be awaited, and so native Promises aren’t actually all the special or sacred. Invoking await on an expression involves no extra machinery, only that a Promise-like object is returned.
And the `async` keyword is even better. It’s completely optional! This keyword only has two effects: allowing the `await` keyword in a function scope, and implicitly returning a promise.
There’s a secret pleasure in all this too. A series of awaited Promises can be wrapped into a single async function. And there’s no need for multiple error checking steps either. All async functions return a promise, so we can wrap the function single try/catch block, or even daisy-chain another promise on the `catch` method. All the pieces fit into each other, and most of them are optional.
Meanwhile in generator land, we’ve got cognitive overload in spades. Yield can only be called from inside a generator, yes that little asterisk next to the function name you might at first glance mistake for an errant multiplication symbol. Sorry, there’s these things called Symbols too. Any object can be made yieldable…or was it iterable…by placing the special symbol on an object class as an interpolated method which returns an iterable. I’m not making this up.
Imagine teaching this to a junior developer who’s spent over a year programming asynchronous code and never once needing a generator. The tide-level for problems solved with generators is always waist-deep, always introduced as a secondary step to achieving another goal.
Generators are almost always hints of a design-flaw introduced much earlier in development, usually by an engineer with enough experience to write code, but not nearly enough to understand how it works.
> Anything with a `then` method can be awaited, and so native Promises aren’t actually all the special or sacred. Invoking await on an expression involves no extra machinery, only that a Promise-like object is returned.
Huh wow! I did not know that! I think TypeScript always kept this hidden from me, but it makes sense. Another perk of `await` is that it collapses all promises into their final value, regardless of how many nested pending promises are expressed:
Personally, I love redux-saga. It took me a little while to wrap my head around it (but 1/10th the amount of time as RxJS), but it is _really_ nice to be able to write complex async logic in synchronous-looking code that's also readable. (At least it was readable for me and the people on my team.) Whenever I had some weird async coordination problem that I needed to solve, I was _always_ able to solve it with redux-saga. I wish more people would use it.
I feel the same way which is why I decided to help maintain the project. Async flow control is very tricky even in js–land. Having watchers live inside of a while-loop is a powerful construct that lends itself to interest flow control patterns.
It’s a great question, and for the folks who knows the answer of why generators misunderstood, they surely discovered this feature in the most unpleasant circumstances.
Generators were introduced during JavaScript’s awkward adolescence, where the cutting edge of ES6 was only possible through Babel (which was then called 6to5). They’re fantastic for turning array like classes into iterable collections. But that’s not what makes them bad.
For a time you had a perfect storm of JavaScript Hell. Promises were polyfilled and rewritten as generators to take advantage of the `yield` keyword. You’ll most likely find out about this trick at the least opportune time: while debugging an async redux action. Now every single stack trace is a high-stakes game of “detangle the Christmas lights!
This was truly a horrible time to be a front end developer. Not only did you have to transpile your code, you had to debug it through a source map wrung through Webpack’s module system. And while you’re picking through this mud ball of a web app, there’s a Super Senior Software Engineer giving a talk on the virtues of observable data management!
I’ve always suspected that these galaxy brain engineers are more like window washers on an ivory tower. And as for the rest of us, we’re just the code gnomes who are shrug when given triangular bricks until told how round bricks are actually better.
I know this is all hyperbole but the emotion is real. For every productive hour of work gained through a new and necessary features, engineers have lost 10-fold on the lesser well-thought out JavaScript. I’m not so sure that native observables will be any different.
Is this an issue with observables or an issue with RxJS allowing you to shoot yourself in the foot?
A saner API (as shown in the proposal) has some obvious benefits in handling certain use cases without necessarily devolving into the crazy streams one sees with RxJS.
I've never understood why redux gets implemented so badly... I feel that the folks who build wacky redux implementations would still write spaghetti managing state without redux.
The biggest issue is that for the first few years there was no single standardized way to write Redux code. Everyone came up with their own patterns, and wrote their own helper libraries. It also required a lot of "boilerplate" code for things like defining action type strings, action creator functions, and hand-written immutable updates.
That's why we published our official Redux Toolkit package in 2019. It standardizes Redux usage, and includes methods that build in our recommended approaches for things like store setup, writing reducers, simpler immutable updates with Immer, and even a complete server data fetching and caching solution called RTK Query:
Having used RTK and RTKQ, I cannot believe they come from the same authors. RTK is mostly serviceable, though for most projects, not using Redux is better. I’ve never seen a case when RTKQ was an improvement over fetch().
Obviously, deleting Redux from the internet to prevent incompetent engineering leads / managers from forcing it on people would be preferable.
If you can't understand the benefits of using RTK Query over fetch I'm not sure you're credible.
They're not even substitutes; RTK Query by default wraps fetch or can be configured to use your preferred http client. So it's an entirely additional layer of cacheing and refetching logic with a standardized interface around common loading and error states.
It is considerably easier to write performant web applications with a library like RTK Query or TanStack Query than to just use fetch and try to roll your own cacheing solution. I say this as someone who has done all of the above professionally.
In my experience it was due to backend devs (like myself) being asked to or volunteering for some front end projects. At least that is how our current frontend turned into a redux mess and is currently being rewritten.
It is a completely different skillset and I think more often than not people assume that they can write front end code just because they know Javascript.
Seconding for for ADHD and narcolepsy. I had a sleep study done a few years back that came up borderline positive. Doctor had me try a few meds out but the one that really stuck was Vyvanse (basically a slow release pro-drug of Adderall). Suddenly I’m not having sleep attacks every time I sit down, or even feeling like my head is made of bricks.
I grew up in a family that didn’t believe in ADHD so I would cope with excessive amounts of caffeine. It’s definitely worth looking into if you have the slightest suspicion.
Also don’t get too caught up in passing the MSLT. Personally, I think it’s barely medical science, but it’s a part of getting a diagnosis and some insights into how your brain is (or isn’t) sleeping.
Same for me. Chronically tired all the time since I can remember. Tried everything. Exercise, diet, probiotics, meditation, sleep training. Got diagnosed for depression ten years ago. No medication helped. Finally got prescribed “off label” treatment for narcolepsy and ADHD called Modafinil.
Completely changed my life!
Turns out there is some connection to narcolepsy and ADHD (Huberman talks about this on his podcast), and it makes sense.
Anecdotally, other people I know who’ve been diagnosed with CFS or ME tend to exhibit similar ADHD-like patterns. Maybe there’s something to that. Certainly worth exploring further.
I’ve managed several open source projects through their transition from CommonJS to ES modules and the least interesting part was the server-side of the equation. More often, the most exciting, and most excruciating aspect is wrangling TypeScript to emit browser friendly module paths. Anything short of relative paths everywhere won’t cut it, and TypeScript really doesn’t like to emit file extensions when TSX is involved.
There’s also some unsolved mysteries surrounding the path resolution defined by a package.json file, but at least there’s now a proper way to have a package use project root relative imports. Things usually go well until you get back to the browser, which now needs an Import Map to bridge the two worlds. I still haven’t figured out how to wean off NPM either since all the magic compiling CDNs use its namespace to create browser friendly bundles…sort of where we started from.
There’s a few foot guns on bundles now too, like deduping React so hooks work, along with some surprises about modules being stateful. And while Deno is pushing the dream forward, I can’t help but feel they compromised the vision too far for Node compatibility. At this rate, I could see Node v30 being a merge of the two projects.
I’m honestly happy it’s all coming along. It seems like this is JavaScript’s Python 3 moment, where everyone has to rewrite code to slightly new paradigm for the next generation of apps to fully appreciate. I’m most thankful for async imports operating like ordinary Promises!
I think React really was revolutionary when your choices were jQuery, Backbone, or even Angular 1. I remember trying to convince my team that React was the next best thing when it first came out. Skepticism was everywhere — especially around JSX. So we compromised and wrote our components with CoffeeScript…
The sheer number of flux frameworks were a testament to how underserved the state model was at the time. And without consistent support for async/await to make Promises work well in an app, data fetching and state was the worst part of React.
I’ve always despised Redux and the circus that came with thunk generators. MobX made things a little bit easier. And Baobab was a fun concept to bring Clojure-style cursors to JavaScript. It wasn’t until React shipped the context API and hooks that I felt the problem of, “how do I get this state from up here to down there?” was truly solved.
Personally, I’ve wished I could quit React for something like native Web components, but I feel like I’d be back at square one with state management and stringly-typed templates. Maybe Lit-HTML will get there one day!
Out of interest why did you despise Redux and Redux Thunk? Imo Redux did solve the problem of state management and I always thought it was quite an elegant solution personally.
Hooks and the context API are just different ways to manage state (and many would argue better). Do you disagree?
This is very clever! I found out about the canvas composite modes far too late in an animated ASCII art project.
IMO, the canvas APIs are a little too esoteric for their own good. It’s almost like a stateful object, but all the commands are executed as side effects. Isn’t front end fun?
Please have a look at my project and let me know what you think! The source code is fully annotated for another brave soul who’s working with the dark arts of high performance canvas rendering.
The rumors are true! Luxury housing is in development, and it’s taking place in Hell’s most gentrified neighborhood. Sources close to the project are calling it ES Modules, and everybody who’s anybody wants in on this high-end horror show.
Honestly, I love the new module syntax compared to the old `require` song and dance. They fit nicely with promises and ensure some level of behavioral consistency in the browser and other runtimes. We could even drop the need for bundling for small enough projects, and get back to the simpler times of dropping a script tag in your HTML. I just don’t understand why Node.js is building a haunted house out of JavaScript.
Can we talk about the file extension thing first?
The brain trust at the lab decided that ES module files should have a .mjs extension to indicate the contents of the file. Fair enough. But .js also works sometimes, depending on the configuration set in the package.json file? We’ll chock this up to gradual adoption. There’s also some fun caveats about module resolution to keep things interesting. ES Modules need either a fully qualified path, or a relative path — both must include file extensions. Again, that’s also fine. I actually prefer it! So there’s the mystery factor of what happens to all the current NPM packages that aren’t compliant. Simple...we just have a special flag to make those work, and let me tell you, the flags are accumulating faster than a Civil War battlefield.
But look, if you’re nostalgic for the DMV, I recommend that you visit the TypeScript repo and check out how this Swiss tunnel coming along. You see...there are two developers at Microsoft. One tells truths, and the other plugs their ears and shouts, “LALALALALALA! TypeScript doesn’t and won’t ever rewrite modules!”
So how do we get this ball of tape running in the browser exactly? A bundler…the very thing we were trying to avoid in the first place! Remember the dream of isomorphic code? Not debugging a Webpack build with shoddy source maps? We’re right back where we started but with a whole new set of meta problems.
The most entertaining part of this game is explaining to your coworkers the difference between an import map and a package.json exports declaration. And God help you if have TypeScript holding up this paper shack. Try building a ES module compatible library that includes TSX files just using the TypeScript compiler. Remember that it’s gotta be .mjs files that get output, and all your imports have to be fully qualified.
It’s been like this for years and will take some additional years to complete. And don’t get me wrong, I’m sympathetic to the difficulties of this affair. But it’s becoming more like a sudden urge to vomit when the someone in the room starts heaving at your table.
And finally, I’m not so spoiled that I expect free stuff from the community. I built a tool to make ES modules and TypeScript play nice. It’s my greatest wish that it gets deprecated before I’m sent to live on a farm upstate…
That’s a very interesting read. I’m definitely biased towards LLMs being more than what the naysayers think of their capabilities. It’s no doubt that these systems are not thinking or performing cognition. They are autocomplete systems based off of tremendous amounts of weighted data.
IMO the problem here is that we have two camps of thought arguing for the extreme end of an undefined claim. The tech companies market their LLM products as intelligent because they can perform text completions that are currently useful for simple tasks.
For example, I used ChatGPT to draft an email to my landlord asking to remove a late fee that occurred because my auto payment authorization expired. I ran the output through Grammarly and ended up with a polite but curt email that would’ve taken me 45 minutes to compose — time I’d rather spend on something else.
I feel like these articles minimize the immediate use of LLMs because of a subconscious implication: most interactions between people don’t require intelligence. And their jobs are next on the chopping block.
The other part is less understood by both parties. Getting an LLM to perform something that looks like cognitive behavior isn’t impossible, but it sure is expensive. As we speak, there are tools in development that can take a user’s prompt and compose it into what superficially looks like a human’s train of thought. The results are significantly more accurate than an off the shelf LLM.
In my opinion, academics are struggling to define why this phenomenon occurs in the first place. And with such a focus on how LLMs don’t work like humans, they miss the point.
We understand that non-human life can be intelligent in ways that we don’t fully understand. Elephants, dolphins, and Octopi are intelligent and don’t require them have human-like cognitive abilities. I think the same goes for LLMs. They will achieve a form of intelligence that is uniquely their own and will adapt to accommodate us. Not the other way around.
>I think the same goes for LLMs. They will achieve a form of intelligence that is uniquely their own and will adapt to accommodate us. Not the other way around.
And I say this somewhat jokingly, this is only true if they maintain subhumanlike intelligence. If actual intelligence far in excess of the human mind is possible, I am afraid it is us that will be adapting to our new living conditions.
Asciify’s origin story begins with my attempts to use SVG’s more esoteric features like lighting effects and animations. If you’ve ever tried to make an animated SVG, you’re unfortunately familiar with just how slow they can perform even under modest designs.
Three.js to the rescue! Somehow their demos always ran at a smooth 60 FPS, and could render actual 3D graphics unlike the perspective-trickery I so often used in SVGs.
Despite the promise of a better tool, I was quickly humbled by a new domain of mysterious terminologies and fractals of OpenGL APIs. I still haven’t found a definition for a “normal” that feels intuitive. But I pressed on until I felt confident enough to put some simple scenes together. I tried some of the examples in their API documentation and discovered their ASCII effect.
It was pretty! And slow!
Maybe it was a feeling of gratitude or a sense of pride, but I knew it could be faster…and it only took me 3 weeks to crack the code.
It was simple at first. Their version used string concatenation. Could I use DOM nodes? Yes, but they’re slow to initialize. Could I use the same nodes and update their values? Okay that’s a bit faster. Maybe CSS grid could help with the layout. A marginally better FPS but what happens when I enable color? Slow! What if I make a diff from the previous frame buffer and do selective updates? Okay, now it’s fast but only on mostly static scenes.
The game changed when I moved my efforts to a canvas renderer. I discovered how I could pre-calculate each cell coordinate to optimize my frame rate, skipping the unchanged values. I could rethink how I perceived an array of RGBA values — height is just a derivative of width! And why are we using these expensive math operations when a bit shift could do the same thing? Let’s get rid of these string arrays and use 8 bit integers while we’re at it!
Did you know that Chrome’s Turbofan only optimizes `String.fromCharCode` when you use a 16 bit integer? Oh, the things I could tell you…
Eventually my efforts plateaued at a humble 30 FPS. The canvas `fillText` method is slow slow slow. This would’ve been the end, but I found a new inspiration while making the image upload demo. Drawing a single character is a lot like drawing an image buffer, so why don’t we pre-draw the ASCII characters to individual canvases? We could then call the much more performant `drawImage` method and consistently hit 60 FPS!
There’s more to this story that you can find in the Asciify source code, including the horrifying tales of reimplementing the color blending with alpha masks. The truth is that there are still optimizations to be found for someone brave enough to port this to WebGL. But I’m happy with the results and proud to share them with you.
I think that great artists can change how we see the world. Does that make coding an art? I certainly think so.
It’s Tasmanian Syrup, on dry ice…