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.
Trying to expand on a quirky travel website populated by AI content. Working on adding countries, regions, areas (e.g. ski resorts), etc.: https://meoweler.com
The quality of the generated content is surprisingly good, but there are many stereotypes and mistakes that I'm fixing in the next mass generation pass.
As someone used to doing everything with vanilla JS and having troubles with getting deep into any web frameworks (especially React), Svelte has been a godsend. I'm in love with the philosophy and approach and its natural combination of JS/CSS/HTML is, in my personal bubble, second to none. Most recent experiment was https://meoweler.com, but I'm now trying more complex projects and can't sing high enough praises. I sincerely hope the future of Svelte is bright.
Designer News used to be an amazing community I used to visit almost as often as HN nowadays. Then https://twitter.com/awilkinson bought it.
Dribbble is another such site that designers used to aggregate at, discuss, share interesting ideas and engage daily. Then https://twitter.com/awilkinson bought it.
I think most of the original community agrees that the combination of moving from invite only to open registration along with a lack of better moderation is where things started coming apart.
And that’s not to blame the moderators. I think they did the best they could. But with the onslaught of spam, they needed more of them, more dedicated (paid) and better moderation tools. They got none of that though.
You can see how that turned out in the screenshot on my site. That’s the front page with crypto spam.
Can I ask what the goal is here? It's cool to be able to spin up a nicely designed website (and it is nicely designed and has a good aesthetic), but isn't the content going to be semantically empty? I don't want to be negative but it feels like cheap plastic imitation of a real thing, and the web is already full of spammy low quality content. Aren't you in danger of your products having a very short life cycle and ending up as digital landfill, so to speak?
The quality of the GPT4 content for travel is surprisingly good, although there are of course plenty of hallucinations and I've a new pass for the content set up that gets rid of the worst offenders. This is really just a learning experiment, but building something of this content scale by 1 person was absolutely impossible a year ago.
The point was that content generation use cases might be a viable path give OpenAI's thin-wrappers-killing direction.
But does anyone particularly want another travel site full of generic advice? Nothing against your individual project, I'm just saying that the web is already absolutely awash in marketing materials and all-in-one portals. If I'm visiting a place and want to read up on it in advance I tend to look for someone with insider knowledge, otherwise I could just buy a guidebook specifically about that place (might be a bit dated, but the editorial quality in a book is usually orders of magnitude better than the web).
LLMs can quickly extract ideas using search and synthesize fresh articles. Take this conversation thread for example, there are many interesting ideas here, they can be scooped and formatted in a nice style. This gives AI a seed of authenticity, its main role would be to curate the mess.
There is pixel-perfection and 'pixel-perfection'. One is a pointless fight against the nature of the medium while the other is love for the craft, sophistication, and actually giving a fuck that something isn't needlessly 2 pixels off of where it should have been. A certain attitude that will show its mark throughout the UI.
I have had a similar experience using ChatGPT to build https://meoweler.com – a travel website covering 5000+ cities with a surprisingly good content quality created over a long weekend. Something that was unfathomable for me 2 years ago.
I checked the city I live in and three more cities I know quite well, and I have to disagree.
This reads/feels like a content farm, which (if GPT wrote the content, as you seem to imply) is exactly what it is (as I have excessive Adblock I don't know if there are ads, but I don't think they are needed for the definition of a content farm).
Fair enough. Calling it 'good quality' might be a bit of a stretch, at least for now (the bigger cities are generated with GPT4 while the smaller ones are GPT3.5 – perhaps you got the 'bad batch'). I'm playing with a different set of prompting that is producing better results, nevertheless — the point was that creating a travel site by one person like this was not possible before.
And there are no ads. It's really more of an experiment rather than a real product.
The website is beautiful. Thank you for sharing the source code.
I took a look at this source code and could not find where you batch-processed the midjourney API calls. I am interested to learn whether you generated the midjourney images by hands or by scripts.
Midjourney sadly doesn't have public API. The images were prompted manually via Discord. Thanks to permutations [0], I could do 20 images at a time, but it's still a painful process. (The generation of the permutation strings is in the shared code)
Ha! As someone who has been to Naples a few times, I fully support the 'walking hostile' sentiment! The amount of wild traffic through the narrow streets and having to constantly look over your shoulder makes it a horrendous walking experience compared to other European cities.
I see.. bit of a shame I guess, we’re used to narrow streets both for walking and driving, makes sense that one born and raised doesn’t live the same issues/experiences
Don't worry, Seoul and Taipei are the same (shared pedestrian traffic alleys + scooters roaming sidewalks and jump scaring pedestrians) with bonus obstacles like pedestrian hostile traffic lights but they are listed as walkable, if I were you I would not pay serious attention to this garbage
