> It reminds me a bit of the skeuomorphic days, where we went to flat design overnight and thanked the designers goodbye
This didn't happen. Even if you consider only the 'aesthetic' part of design and ignore function (impossible, but for the sake of the argument) — the striving for reduction and removal of unnecessary real-world metaphors was a natural evolution driven by designers, not PMs, not engineers, nor any higher-ups. 'Flat' design was in hindsight inevitable, but you can't just get rid of decorations, ornaments and gradients and call it a day. All major digital products were and are designed by designers. Not by engineers who got tired of waiting for a button sprite.
Sometimes I wonder how I (or generally people of that time) would react to seeing the modern web. At least — the 'good' modern web and design. Awe? Confusion? Understanding that this is the future in the very same way that we understand that 'that' was the past?
The modern web is sleek and polished, but something’s been lost. I still remember how cool it felt seeing a clean CSS layout for the first time — text aligned perfectly without tables, seamless transitions — it was magic.
But now everything feels uniform. Design is so standardized I can’t remember the last time a site genuinely surprised me or made me want to dig into the code or copy it for my own.
It feels like we’re browsing the Walmart music section… efficient, predictable, and totally sterile. I miss the indie record store vibe — quirky, surprising, maybe even a little messy, but full of personality.
Sleek and polished? Where? Not Amazon.com, not any newspaper/periodical site loading a bunch of ads shifting the layout, not Substack or Medium.com with its exhortations to log in or become a member.
With such a strong opinion on designers and design as a discipline, I got curious and had to peek at your other comments and — even though I'd normally hate to do this — the irony was just too strong with this one from only few hours ago:
> ... Lesson: people with grave incompetence at programming feel completely competent to judge what programming is and should be.
Your own lesson applies here perfectly, only substitute programming with design.
Please don't dig up historical comments in order to criticize someone like this. We should be able to respond to the argument presented in a comment or subthread in its standalone context.
Do you think that "being competent at design" is the only requirement for designers?
I would say that it's more important to be competent in determining how design is going to be understood and used by users in their individual workflows. Few are more competent to judge that than the users themselves.
I'm pretty sure most folks have seen and experienced the negative impacts of designers changing things for the sake of change (or to justify their paychecks).
Being competent in determining how design is going to be understood and used by users IS being competent at design.
There is a massive amount of bad design out there — made by designers. There is a large amount of bad software implementations. By programmers. And awful chairs, food, and ...
Designers don't critize Comic Sans's usage when it's appropriate. It's when it's not. Like a funeral service's signage. Or a lawyer. And the massive amount of such objectively wrong usage in the wild is where you see designers crying about it.
It's just the most common example, as thanks to Microsoft it comes preinstalled on just about any computer. Given the typically short list of fonts to pick from, many people will (would?) pick Comic Sans when they want their text to look a bit 'different'.
However, I do agree that making fun of people picking the wrong font is a bit elitist. At least Comic Sans is easy to read, so one could do worse.
I'm not sure if complaining about using a jaunty font on a WWII death row cell door explaining how many Jews passed through that cell is elitist at all. Real example. Using comic sans there is tone deaf at best.
Of course comic sans specifically has turned into a bit of a meme so now you'll see all sorts of people complaining about it getting used anywhere, which is a lot sillier, but still not elitist I don't think.
Kraa can't properly compete with Notion, yet. Not on the feature-set. That being said, if you value simpler interface that still has all the core editor features, give it a try!
We are also not trying to be a Notion clone/alternative, but rather a different kind of text editor that's highly customizable, has unique features (like the writer role) and keeps strong division between writing and styling.
WPM and other attempts at putting a one specific number/metric to point to is imo only mudding the waters. Better way to think about just how awfully slow natural language (on average) is as an interface is to think about interactions with {whatever} in terms of *intents* and *actions*.
Comparing "What's the weather in London" with clicking the weather app icon is misleading and too simplistic. When people imagine a future driven by conversational interfaces, they usually picture use cases like:
1. "When is my next train leaving?"
2. "Show me my photos from the vacation in Italy with yellow flowers on them"
3. "Book a flight from New York to Zurich on {dates}"
...
And a way to highlight what's faster/less-noisy is to compare how natural language vs. mouse/touch maps onto the Intent -> Action. The thing is that interactions like these are generally so much more complex. E.g. Does the machine know what 'my' train is? If it doesn't, can it offer reasonable disambiguation? If it can't, what then? And does it present the information in a way where the next likely action is reachable, or will I need to converse about it?
You could picture a long table listing similar use cases in different contexts and compare various input methods and modalities and their speed. Flicking a finger on a 2d surface or using a mouse and a keyboard is going to be — on average — much faster and with less dead-ends.
Conversational interfaces are not the future. Imo even in the sense of 'augmenting', it's not going to happen. Natural-language driven interface will always play the role of a supporting (still important, though!) role. An accessibility aid when e.g. temporarily, permanently, or contextually not able to use the primary input method to 'encode your intent'.
I can wholeheartedly recommend Svelte. As someone who can only do vanilla HTML/CSS/JS, it lets me build projects quickly and efficiently without having to learn something complex like React. Case in point this silly side project made in Svelte over a weekend: https://meoweler.com
I went with Svelte when I built out the website for my canvas library a few years back[1]. It's proved to be easy to maintain the site, and I particularly like that it supported my vanilla JS library (which I use on the site's landing page) with minimal fuss.
At some point I want to update the site to use Sveltekit, which I'd been experimenting with in personal projects. But then the team announced Svelte 5 and these things called "runes" and ... I don't know. Having just passed my 60th birthday I'm getting to a stage in my life when keeping up with all the New Shiny makes me wonder if it's worth the effort, or if I should be doing more interesting stuff like creating new content for the site instead.
It's funny because very early on the key selling point of Svelte was that you just mutate objects and it compiles to the observable pattern, unlike React's clunky setState syntax. Now, somehow magic symbols in the code is supposed to be an improvement? It doesn't seem that different from React's magic hooks these days.
Is there some mysterious force of nature that binds front-end frameworks to bad decision making?
I haven’t had the chance to use Svelte in even a semi-serious project. From what I’ve tracked, Runes allow for better handling state complexity and allowing finer grained explicit control of reactivity.
Maybe you don’t need that. Seems like a bunch of the Svelte community did. I wouldn’t frame that as a bad decision.
There is probably a reason they did with a ground-up rebuild and partially this is because svelte 4 didn't enable universal reactivity and $ was more confusing than useful.
Furthermore <slot /> had limitations in terms of children which made it difficult to build UI libraries.
Svelte 5 now is actually simpler to learn for new comers despite higher verbosity.
This is also why I chose SvelteKit as my first framework. I was actually pretty fluent in vanilla since my first real web project was a full stack chrome extension, but when it came time to choose a framework for my first true web app, I chose Svelte because it was the only framework I could immediately understand.
Svelte reminded me of how I got my start with coding. I love it. Refusing to learn React has cost me job opportunities but Svelte is just so much more pleasant to use and easy to grok.
I’m currently building a social network with SvelteKit and I couldn’t be happier. Excellent DX.
That website is actually a great way to compare options, thanks for sharing! I did find that it gives a 500 error for Birmingham, AL specifically, if you’re still working on it.
...but that's what Svelte is not. The techniques you adopt won't transfer over to vanilla HTML/CSS/JS without the magic Svelte compiler. These habits will become crutch when Svelte inevitably goes the way of every Javascript frontend framework.
> something complex like React
React is not that complex, certainly not more so than Svelte. It's hard to wrap your head around some behaviors, but at the end of the day, it is really just Javascript/Typescript. It is programming. As a programmer, I want to spend most of my time programming in a programming language, not so much of it configuring the Rube-Goldberg machine that is HTML/CSS. Your mileage may vary, of course.
> this silly side project made in Svelte over a weekend
> As a programmer, I want to spend most of my time programming in a programming language
If your work requires you to use a web stack, this attitude will not serve you well in the long run. If you make the effort to learn these technologies, you'll soon find them to be simple and predictable, but admittedly not without some historical baggage. You may even have an easier time with Svelte, since it has everything working out of the box, unlike React, which requires you to figure out a build toolchain and a separate solution for styling.
Not sure about this. Most JS frameworks only last a few years before the next shiny is mass adopted. The churn in JS land is insane.
React is definitely one of the long beards though, and thats’s because declarative programming is a win for UIs IMO. So much so it had a massive knock on effect in popularizing this approach (what’s old is new again… and again) across languages and problem sets.
IMO we're long past the churn era - Svelte itself is 8 years old. There are occasional bursts of new frameworks and tools, but only when there is a new niche - the last one I remember was a few years ago when suddenly everyone wanted to do a static website generator. And that didn't make existing frameworks obsolete.
In my post I was actually speaking about learning CSS and HTML alongside the "real programming language" that is JS/TS.
> If your work requires you to use a web stack, this attitude will not serve you well in the long run
I disagree. A "web stack" is outdated quickly, but the language remains mostly the same, as does my data. React lets me express most things naturally as forward data transformations, without entangling me too much to peculiar toolchain that will become obsolete and break absolutely everything.
> You may even have an easier time with Svelte, since it has everything working out of the box, unlike React, which requires you to figure out a build toolchain and a separate solution for styling.
Sure, you'll have an easier time making decisions if someone else makes them for you.
I swear every time I use React, every couple of years, I wind up thinking "okay fine, but... why?"
I love JSX. But the React API, for some areas, feels complex and boilerplatey. I dunno why you have to explicitly memoize some stuff. Svelte just magics that shit away.
> But the React API, for some areas, feels complex and boilerplatey
You may or may not have noticed this, but the React API is a bit counterintuitive to how JS or any other code you normally write would work because the component function gets invoked repeatedly so any code in the path of the functional component that's not externalized into a hook or memoized will be invoked again.
That's also why in local dev mode, you'll see the render cycle executed twice so that you can spot any undesired side effects due to this design choice.
So a lot of the complexity is to deal with this specific design choice to determine when code inside of the component function needs to be re-executed. In React, you need to explicitly opt-out of reactivity while in nearly every other framework, you are opting-in to reactivity.
For me, I've always seen this as the weirdest footgun because it's antithetical to the underlying language and runtime behavior so developers need to be explicitly aware of this behavior.
As someone who had to work around the bugs and limitations of IE6 for years in the enterprise, popularity is not a measurement of how good a technology is.
The reason React is "embraced" by the industry is that it is widely used, not because it's the best choice. This lowers the risk for companies that can replace its developers with another easily. I'm not saying it's as bad as beeing stuck with a stale IE (yet), but there are surely good alternatives out there.
"Nobody has been fired for choosing IBM", was a saying that applies to React today
It has reached the "IBM" point where it's so widely used, that it has become the most rational choice for enterprise.
We have to wait for a few years while smaller businesses who don't have (or care about) the same risks uses better alternatives until they reach the point where you are not blamed for choosing something outside the box
> The reason React is "embraced" by the industry is that it is widely used
That looks like tautology to me. What point are you trying to make with this?
Comparing IE6 and React is _hardly_ a fair comparison. One was a Trojan horse injected by corporate policies and ACLs, while React gets explicitly chosen by teams. And... Yes, there _is_ a reason why nobody gets fired for choosing React: it's not a bad choice! Is Svelte a better choice? Not universally. Unfortunately—like with many things in our field—it comes with trade offs and the answer boils down to "it depends" again.
React has its quirks, but "hating" on a library because it was part of a dumpster fire project doesn't mean the library is bad, just that people using it weren't competent with it (not necessarily incompetent in general).
Vue, Svelte, Leptos, Solid, Elm. I've seen all of them used as dumpster fire fuel, and it was hardly the library's fault.
I do not hate React and am not the person who made the dumpster fire argument. The original person complained about React, and another person used popularity as a counter argument. That was what I replied to.
> That looks like tautology to me. What point are you trying to make with this?
React is in a place now, where it is the "safe" default choice for Enterprises. It's not necessarily a bad choice, but I argue that risk management is often an important part of deciding which tech to use.
It got to this point by being backed by Meta and was a genuinely good alternative to other frameworks at the time. But it is my view that enterprises prefer React not because it is the best, but because it is good enough and easy to find workers with experience. This is a self reinforcing feedback loop.
I worked in a sales driven startup some years ago and got to shape the technology as the first hire and only developer for a few months. I chose React because it was easier to recruit for and time to market was important. If I had already a team of developers with experience with another framework, I would have chosen that one even if it had been a less popular framework due. Time to market was our main focus.
More established companies don't have the same time constraints and are often more concerned about scaling up with multiple teams. A less popular framework is a bigger risk. It is "easy" to hire 10 people for any framework, but what about 100?
Vue? Lol. I've been using Vue full-time in multiple large corporate code bases for the past 3½ years and I'd exchange it for React in a heartbeat. Its type checker and build toolchain are so abysmally bad and bug-riddled that I run into new bugs and limitations on the daily. …which is no surprise really if you introduce a new custom file format and make type checking an afterthought.
Meanwhile, React is basically pure TS and the only bugs I run into are the occasional limitations of TSC.
>Its type checker and build toolchain are so abysmally bad and bug-riddled that I run into new bugs and limitations on the daily.
This seems like a setup issue.
Mine catches everything just fine. Both in-editor (I use neovim) and with a make step (just calls vue-tsc) + a precommit hook as a sanity check.
>React is basically pure TS and the only bugs I run into are the occasional limitations of TSC.
React is obscene. It always seemed to me the Java of the FE world, made worse in recent years. By that I mean grotesquely verbose and full of ceremonious value passing through multiple functions just for the tiniest of things. I've had to work with React codebases and these days I outright refuse to do that/turn down jobs with that requirement. I'd rather use angular.
Svelte and Vue are ergonomic and straightforward and they sanely default to SFCs instead of that woeful chimera of languages called JSX/TSX - you can still use it if you so desire though.
> It's hard to wrap your head around some behaviors
I've got a React maintenance and development project coming up in a few weeks. I'd love if you'd expand a bit on these points and maybe point to some relevant docs. You could potentially save me days or more of tail chasing. Thanks.
The biggest thing most people don't understand is that React re-renders recursively by default, regardless of whether any particular child component's props actually changed or not. Most of its behavior patterns follow from that one.
I have an extensive post called "A (Mostly) Complete Guide to React Rendering Behavior) that covers the concepts and nuances in detail:
Primarily the rules of hooks and what does and does not trigger a render or a unmount. If your project still uses class instead of function components, that's a potential target for refactoring.
This didn't happen. Even if you consider only the 'aesthetic' part of design and ignore function (impossible, but for the sake of the argument) — the striving for reduction and removal of unnecessary real-world metaphors was a natural evolution driven by designers, not PMs, not engineers, nor any higher-ups. 'Flat' design was in hindsight inevitable, but you can't just get rid of decorations, ornaments and gradients and call it a day. All major digital products were and are designed by designers. Not by engineers who got tired of waiting for a button sprite.
reply