richeyryan

I've been working with CSS since floating grids were a thing. I've worked on projects with SASS/SCSS doing the whole BEM thing and then using CSS/SCSS modules. I have a good working knowledge of CSS. I like Tailwind. It's system for colours, and spacing is a good sane baseline, and you can customise them to conform to your design system if you want. CSS grid makes layout much easier in general, but their utility classes make it trivial to express your grid layouts.

I can't say I've really had many issues with git diffs or conflicting classes. I'm not entirely sure why you'd replace blanket `p-4` all over your app. Are you making some changes to the spacing in your design system? Why not change it globally and let it propagate?

I'd tend to agree with you that (S)CSS modules are a great improvement over the completely detached styling of the past, but I still think Tailwind has a lot to offer with its prebaked system and dead code elimination.

Both Bun and Deno aim to be batteries included, shipping Typescript and a test runner etc., by default. Deno initially aimed to diverge from Node and conform to the web platform as much as possible, i.e. use ES Modules and Web APIs over custom APIs. They've moved back towards Node over the last while to get more adoption. Bun broadly aims to be Node compatible, but they seem to try to stick to Web APIs too. Bun seems to value performance as a primary concern, with start-up time being an often-discussed metric. The value being improvements to local developer toolchains or fast starts in edge environments. Deno seems to value developer experience, with the goal being an overall better Node. They also benchmark performance against Node and seem to be faster in some places but not others. Finally, Bun uses the JavaScriptCore engine from Webkit, which it seems can be faster than V8 in some situations.

This is the perspective of a relatively detached observer who has played with both a little and kept up with their development somewhat but hasn't done a serious project with either.

The article touches on this but often, just having the appearance of somewhere that is serious about coffee or cocktails is enough. The owners probably don't care, so long as they do enough business to keep things going. People will go somewhere that looks like an excellent cocktail bar, order something called an Aperol Spritz, receive something that is mostly soda water, a bit of prosecco and a tiny dash of Aperol and be pleased because doesn't it look great? And if that represents value for money to them, then that's fine. The whole idea of speciality anything eventually has to overcome the fact it will be commoditised, and there will be an abundance of low to middling quality offerings that are using the signifiers of high-quality offerings to make money.

I believe this is why The Office got a second season. The network and audiences weren't convinced by the first season, but Carell became a star overnight, so the network was willing to keep the show going. Then the writing team found their grove, delivered a second season vastly superior to the first, and the rest is history.

This article, and all the ones like it, remind me of Worse is Better. Specifically, the key point from that essay is:

"The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing."

This post concedes that point in the first couple of paragraphs. Much like C and Unix-like systems, this is why React isn't going anywhere. Indeed not based on the competition it has now. The best its competitors can do is convince React to steal their ideas and keep pushing toward doing 90% of the right thing.

[1] https://www.dreamsongs.com/RiseOfWorseIsBetter.html

Yeah, this example highlights the weakness of conditional expressions in Javascript in general. JSX is expression-based, and so you end up in this situation. DSLs added on top of HTML can add something resembling the conditional statements that many are used to. Still, JSX needs the TC39 proposals for the do expression or pattern matching to pass to improve the situation.

I guess software is like your cutlery drawer. You want to keep your knives, forks and spoons separate.

Svelte absolutely has a runtime, with the two most crucial components being the scheduler and the lifecycle manager. It still comes in a lot lighter than React.

That site seems to exclude Ireland entirely, which would I think would come in ahead of Germany for salaries and is both a European and Eurozone country.

The original Hyperscript still gets talked about, at least in the React and Solid communities and if only in conversations about the relative merits of different rendering methods. I wouldn't feel comfortable naming a project Zepto today. Why muddy the waters unnecessarily?

The naming of this project clashes horribly with https://github.com/hyperhype/hyperscript. It's not like it's in a different ecosystem or something. It is a web project that is guaranteed to cause confusion.

From looking at it, the Svelte integration is actually the framework-agnostic integration. It relies on Svelte stores following the observable interface, which should be relatively easy to integrate with anything else.

React went from v0.14 to v15. The rationale was the library was stable at that point so they could switch to major versions. Why they went directly to version 15 rather than 1.0 is admittedly a bit odd. I guess it was marketing in the same vein of Java 1.4 to Java 5.

I have used it on production projections and it's seamless. It works with third party React packages with no problems whatsoever and is much lighter. For a stock standard SPA with no need for the upcoming server rendering stuff in React, it's excellent!

We can't say definitively how it would have turned out if Kubrick did finish it but apparently AI is much closer to what Kubrick intended than many people give it credit for. I personally really like the movie but I know it's quite divisive.

I think A Single Man is a good example of an ok to good book being made into a great film.

Something I've experimented a bit with in the past is having something like Storybook for API modules. Rather than jumping out to postman, you could just have your notebook that calls your API functions. So far the stumbling block is always ES Modules. Usually the client code uses them and Node always makes them a pain to deal with. Hopefully the situation will be better in another couple of years.

Facebook, Bloomberg, Citrix, Docker and a handful of others featured on their website[1]. I'm sure there are others that are quietly using it.

[1]https://ocaml.org/learn/companies.html

One thing to be very mindful of is that is a very limited application. The footprint of the various frameworks changes based on how big your application gets as shown here[1]. Swyx, I think you are probably aware of Ryan's article but it's worth contextualising for others who might not be familiar. The more components you have the more Svelte loses its edge.

[1]https://dev.to/this-is-learning/javascript-framework-todomvc...

Absolutely agree, the developments in flex and grid have done wonders for reusable components.

You're right, I think I meant something more like proxy style mutation. It does of course compile down to functions operating on stores which is even more like Solid

I think you need to take a second look at Solid. It isn't subject to the same "rules of hooks" as React so hooks are really just functions that return reactive units. You could argue writable and readable are just hooks for creating stores. It's reactivity is fairly similar to Svelte from there. There are stylistic choices with Solid choosing a function style and Svelte abstracting that with proxies and allowing a mutation style but otherwise how the reactivity works is close.

I do agree that Marko is quite promising. I think quite a few sites that need server rendered markup and progressively enhanced features could be implemented more simply in Marko than the equivalent solutions with React, Svelte or anything else.

Typescript is definitely eagerly evaluated unless you were to use a first class function to defer execution

I feel like the AWS CDK is a great example of this working well. Rather than puzzling over what config options are valid, I get autocomplete and compiler errors when I insist on using an incorrect option. You also get stuff like deprecation warnings showing up in your editor.

It also becomes trivial to parameterise config so I can setup the same general Cloudfront distribution once and tweak it based on the individual application. It's open to abuse but it's better than interpolating values into Cloudformation templates.

I trialed Snowpack earlier this year and found I ran into quite a lot of hard to debug issues. Around the same time I saw that Rich Harris, creator of Svelte and Sveltekit, opted to use Vite over Snowpack for Sveltekit because more things, like CSS and and SASS, just worked out of the box.

I tried out Vite and it was a much smoother transition. As you said it seems to have more mindshare now and I would guess that is because the out of the box experience is better.

SolidJS[https://www.solidjs.com/] does exactly that. That ability is more about fine grained reactivity than it is about templates. The use of templates and single file components is a stylistic choice by the Svelte team. You could argue Solid has poor ergonomic compared to Svelte I guess.

This is a really cool idea. This has always been my biggest beef with single file components. It never occurred to me that you could do this with Vue. Thanks for the tip

There's a proposal for immutable records and tuples: https://github.com/tc39/proposal-record-tuple

Theoretically they would use structural sharing for their implementation which should reduce the overhead of creating a whole new array of objects like that

I think The Movies That Made Us on Netflix is great. The general premise is exploring a classic film and the arduous journey to make it happen. The films and their directors are household names now but at the time they really had to push to make it happen with some directors being complete unknowns. Sometimes they were basically establishing their genres as with Toy Story and Halloween. With others, like Elf, they were using techniques like forced perspective and stop motion animation when they were under tremendous pressure to use CGI. I think it's a really great illustration of how the obvious classics were, at one stage, a long shot like everything else.

You don't update OSX before March in my experience. There are always teething issues.