daliwali

At my work, I have a somewhat clever (or idiotic) technical solution to the problems of feature flags: they are actually implemented as feature modules that monkey-patch the base application in runtime.

There are a few benefits: removing features is dead simple, just delete the whole feature module, and there's no conditional branching in the base application.

There are some drawbacks too: the base application must have entry points for the feature modules to overwrite. Usually the default values are no-op or some default behavior. Features also must implement setup and teardown, which can take longer to write than a conditional.

Really reminds me of Parenscript[0], which is a subset of Common Lisp that transpiles to JS with no runtime. It's basically a thin skin around JS and it feels more like writing JS with a Lisp syntax.

What I feel is missing from Parenscript is runtime macro-expansion, hard to do without using JS to build the AST.

[0] https://parenscript.common-lisp.dev/

If I had to guess, it's because the WebAssembly Text Format is S-Expressions, similar to the target language, Scheme. Also, less tooling involved to build the binary, since the text format is pretty close to the binary format.

In practice though, it looks closer to C/ASM. The author even wrote comments in C. This is the first time I've looked at an actual program written in the wasm text format and it's pretty interesting to see how one would actually use it. Very neat.

I've never actually used Knockout but I guess it looks vaguely similar.

s2 has the advantage of being much smaller (a little over 2kb compressed), and faster on benchmarks[0] and probably real world performance. The API tries to get out of your way as much as possible. The dependency tracking is seamless by using Proxy.get trap. There's no forced separation of models or views, it's all data.

I wrote it because I had to make a complex UI with streaming WebSocket data work smoothly.

[0] https://krausest.github.io/js-framework-benchmark/current.ht...

Open source is not a business model, and I think the expectation to get paid for open source is a bit disingenuous. There is also the ideological aspect of free as in freedom licensing, while it doesn't exclude monetization, often detracts from the incentive to pay for software.

To play the devil's advocate, I would suggest that there is price discovery at play here and people + corporations are willing to pay for what they get value out of. Which is suggesting that many companies don't get much value out of Babel or it is one of many tools utilized in a toolchain. The value proposition is to be able to run new JS in old JS runtime, which may be less valuable now than it was 5 years ago, since evergreen browsers exist and outside of stale corporate environments, most browsers are auto-updating now.

the root template references the other one with data-template=“#countbox”. this allows for composition and re-use of templates.

It is pretty much feature complete already, there are only so many fundamental operations and DOM attributes. besides, I would like to keep it around 2kb ;)

Hahaha this will never work for an obvious reason that isn't socially acceptable to state. As soon as looks get involved, it's over.

I think concurrent mode and fibers are kludgy hacks that arise from the problem that only the main thread has access to the DOM. As far as I know and I may be ignorant but few, if any, other frameworks are scheduling DOM updates as aggressively as React is, and are simpler to understand as a result.

Hopefully the standards folks can come up with a decent DOM API for WebAssembly.

I made something almost exactly like this: https://simulacra.js.org/

This actually uses object getters/setters, has full support for arrays, and nested arrays of objects. There is no API beyond the initial binding, everything beyond that is just mutations on an object.

This is my first time reading about Edsu, it seems very similar to the Solid Platform in one important aspect: it keeps data in the control of the user, separate from applications.

I like how low-level and simplified the protocol is, being limited to only 9 types of messages. Compared to Solid which carries baggage from RDF, this seems far easier for third parties to implement.

The note-taking app is really under-selling the protocol beneath it. What could help sell it better is by doing something better than a centralized platform can.

There is no way this isn’t well done satire. Facebook might as well hire people to work on their open source just to keep them away from being productive at other companies, and that has more value to them than whatever bullshit monetary value their open source may have.

From what I understand, it installs a bunch of opinionated packages and then you're on your own. This isn't the same as "create a useful app in 30 seconds".

REST failed at marketing itself and its primary document is a doctoral thesis, hardly something that an average developer is going to grok, understand and implement.

Hypermedia is a more appropriate term, and emphasizes the actual substance rather than style.

Software seems to actually be progressing at such a slow pace, I don't think more frameworks to do the same old things are helping.

It seems to be harder to retrofit a new format onto an existing framework, than to write a new framework altogether. Once the new framework is out, it will be replaced by another shiny framework that offers a brand new feature that is actually a rehash of something old.

I'm optimistic that there will be something next that will replace framework churn, but what?

Funny how the advice to hire people smarter than you, doesn't work out in real life. Meritocracies are rare, and only seem to emerge out of necessity. That applies for tech companies as well.

As long as your employers are not acting in good faith, then I don't think they are worth any extra effort. When most employees are doing just enough work to get by, it says more about the employer than employee.

You don't have to be 35 to start hating your job, I did at 25. It begins with the realization that you're a loser in the corporate hierarchy, and do as little work as you can possibly do without getting fired.

Software developers tend to complain that their job is tedious, repetitive, and that they aren't learning anything. Most jobs are like that. I believe that a large portion of repetitive software development can be automated, and this is a largely unexplored area.

Consider facts: React is over 40k lines of code, there are 30+ classes/methods to be aware of though maybe 10 of them are commonly used. Would you call it "minimal"? There is still a lot more that could be done with a smaller API surface and much less code.

Compared to Angular, it might as well be a micro-framework, but by objective measures it's not so simple.

npm downloads seem to exaggerate how many actual people are downloading packages rather than bots.

A funny pattern that emerges in the above chart is that downloads drop sharply on weekends. I have seen packages that exhibit the opposite pattern (downloads spike on weekends). And this pattern is correlated with popularity, the most popular packages are downloaded largely by 9-5 industry coders, and mostly via continuous integration bots.

Regardless of technical merit, I don't think it stands any chance of adoption without major users. Specifications and standards are only really valuable as a contract between two or more parties, otherwise they might as well not exist.

On the tech side:

- RegExps open yourself up to RegExp-based DoS attacks.

- The nested/denormalized results anti-pattern seems to be copied from GraphQL. Unless this is intended to be a faithful reproduction, don't copy mistakes.

Care to explain how your product has been around for 6 years and you're just beginning to push it?

It was clearly not my intention to judge programming competency by appearance. But it is also undeniable that the industry does select for young, good looking people.

I'm a millenial myself, not older than the people I am critiquing. (after looking up your profile I realize that I am much younger than you)

My comment was made in jest, pointing out how incongruent technical interviews can be to the job they're interviewing for, which I think doesn't imply any arrogance. Maybe you are reading it differently.

I'm not too worried. There are Indians who will do my job for $15/hr. The fact that they haven't undercut the whole industry doesn't surprise me.

I wasn't suggesting that a 4 year degree confers any advantage. I think it's merely status signalling to potential employers. Practically speaking, my degree only helped me at one point in my life: moving to a foreign country.

There's nothing wrong with software that only needs code monkeys to write. It doesn't have to be technical masterpiece to be useful, or valuable to business. Just think of all the code monkeys with jobs.

Is this a personal attack on me? :^)

The projection in your comment is unreal: a just world fallacy where only unattractive people can be smart, attractive people are mindless, which was definitely not the point.

I got an impression who their target audience is, based on the examples used, drinking kombucha and listening to Spotify.

All the young, beautiful people who wouldn't have ever taken a computer science course if it weren't such a lucrative industry to be in right now.

Maybe with this guide they can pass an interview at a big company where they just twiddle with bits all day. I won't be holding my breath until they can produce something useful.

>A number of "engineering" posts are not written as a thoughtful engineer might, and are in many ways marketing for the products sold (like a training program).

I think this is a great insight that is often overlooked in tech marketing. When any vendor comes up with a product that claims "[industry standard] is dead, use [our product]", there should be alarm bells ringing already.

There is a lot of FUD from the GraphQL side of this debate, and even overlapping goals with REST. From the article:

>With GraphQL, the client speaks a request language which decouples clients from servers. This means we can maintain and improve clients separately from servers.

This is actually how the web works right now. Browsers (clients) evolve independently from web pages (servers). Even the author of REST said it is "intended to promote software longevity and independent evolution". Standards are governed by standards bodies such as IETF, IANA, W3C, WHATWG, etc., not a single corporation like Facebook.

I think only time will tell if this is just another fad that took off but didn't age well, like SOAP.