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.
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:
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.
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.
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.
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.
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!
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.
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.
Fresh looks seriously cool! I'm especially fond of the plugins concept for bringing in compiled assets like Markdown and SCSS. And Getting started with a `deno run` command is very exciting for new-comers too!
Shameless-self promotion: I've been working on a similar web framework built on Deno and Cloudflare Workers. It's called Keywork[1] and it's made for folks who would like to create web apps for the V8 runtime, without getting too attached to a single cloud provider.
Keywork has powered all my projects as of recently, but Fresh looks like a serious contender. I would love to chat with the Deno team if they're floating around this HN thread! You're creating amazing stuff!
Disclosure: I maintain an open source web component library.
This is a strange take on what I think the author is fighting against: a less open web platform. What confuses me is how the adoption of Web Components will somehow make things worse than they already are. Take a look at any contemporary web framework and you'll see there's little overlap in compatibility or portability -- sometimes even between versions of the same library!
I've seen first hand how difficult web components can be, but they're still a better solution than trusting the foundations of the web to the teams at Angular or React. In my opinion we need an API that lets young developers start their web apps with plain HTML/CSS/JS without experiencing into the same decades-old issues that created frameworks in the first place. How should an intermediate developer beging organizing their CSS? Or importing helpful libraries? Or even something as simple as making a reusable HTML template without spending any time in Webpack?
The truth is that we don't have easy answers for these aspiring developers, and we won't get any sympathy from them by demanding the web return to it's document roots. I think Web Components can solve all these issues with some guidance from the community. The platform is ready and so are we.
I think what's more confusing than ASI are the mental gymnastics developers go through to justify typing semicolons daily, rather than installing a linter once, or reading the ASI spec.
Python and Ruby support semicolons for occasional statement termination; why is JavaScript any different? I can't help but think "semicolons by default" would be regarded as ritualistic if the practice was never popularized in the first place.
Nirrius Studio | Front-end developer | New York, NY | INTERNS | PART-TIME | https://nirri.us
WHO WE ARE:
Nirrius is a consultant firm specializing in web development and technical mentorship. Our journey started with training developers with industry standards such as React/Redux and Node.js. Our mission is to perfect the front-end web development experience.
WHAT WE'RE BUILDING:
2018 generated the most buzzwords in web development history. Developers are expected to know React, Redux, Sagas, Webpack, Babel — the list goes on... These tools have served our growing demands of the front-end, but they always have a rise and fall. A library reaches popularity, and the web browser catches up.
We believe browsers have reached another level of maturity. And a simpler, native approach web development is within reach.
We call it: <my-app /> — An open source native web components library and framework.
WHO YOU ARE:
- You are determined, a self-starter, and in active pursuit of new knowledge and experience.
- You have some web development experience and are looking to expand your skill set.
- You're ready for three months of training in front-end, dev-ops, content writing, and developer relations.
Send us your resume and tell us what you'd like to study at teffen @ nirri.us with "Hacker News" in the subject line.
Nirrius Studio | Front-end developer | New York, NY | INTERNS | PART-TIME | https://nirri.us
WHO WE ARE:
Nirrius is a technology firm specializing in web development and technical training. Our team is composed of creative professionals in the pursuit of a more perfect developer experience. We're bent on building simpler tools, and slaying buzzwords.
WHO YOU ARE:
- You are determined, a self-starter, and in active pursuit of new knowledge and experience.
- You have some web development experience and looking to flesh out your skills.
- You're ready for a three month journey through web software fundamentals.
WHAT WE'RE BUILDING:
<my-app />, a new open source native web components library and framework. "My App"[1] is our vision for a simpler experience building web apps. Our team provides training for front-end, dev-ops, content writing, and developer relations.
Reach out and tell us your story at teffen @ nirri.us with "Hacker News" in the subject line.
An experienced web engineer, product strategist, and designer.
After working in several startups I’ve had the opportunity to do a bit of everything. I’m a 10x engineer on the front-end and experienced in video game production. I'm looking for a role that focus on creative vision, marketing -- and some heads down programming when needed.
It’s Tasmanian Syrup, on dry ice…