Live data from Hacker News

Thoughts on Svelte(Kit), one year and 3B requests later

claudioholanda.ch

191–200 of 222 posts

Re: Thoughts on Svelte(Kit), one year and 3B requests later

#191

I like the fact minimalist approaches, like svelte, htmx and alpine.js are getting more and more traction. I felt like fighting this fight alone for years in the golden years of node, webpack and react where everybody was creating crazy stacks and adding GraphQL and so on, to basically get what Django + jquery did 10 years ago in a tenth of the time and code. So far I also survived: - xml is the future - let's use no…

Software itself hasn't "evolved" over the last 40 or 50 years. It only ever gets better because the hardware becomes better. There is no true innovation in software development. Folks that "innovate" either reinvent the wheel or capitalise on hardware improvement.

Look at all the fascinating runtimes that have evolved. Erlang, Haskell, Go, Rust, and include any other. You don’t consider any of these evolution? Back then, programmers were still using threads for everything. Now we have “green threads”. One example of a pretty great evolution. Albeit it does feel like software evolves slower than hardware.

Re: Thoughts on Svelte(Kit), one year and 3B requests later

#192

Earlier quoted context omitted.

Pretty much every library I have tried to use with Next App Router (and therefore RSC) doesn’t work with RSC. I’m sure it will change but we’ll be sticking for Next Pages for a while yet.

I think you may have missed that you can circumvent all of this by declaring your components to be client components.

What's the point of using RSC if you have to mark everything as client components?

At best you're getting SSR support since client components actually run on the sever as well, but there are already cleaner solutions for SSR react components that rehydrate in the browser.

Re: Thoughts on Svelte(Kit), one year and 3B requests later

#193
post #151

Earlier quoted context omitted.

The issue I always run into is that containers don't get maintained. I have never encountered a project where a container "just worked". I absolutely love them when they do, but they have wasted so much of my time when they don't that I just skip them now. It takes me 5 minutes to set up a local env, and with a staging env at parity with production to test on there's never any issues.

Do you mean you skip the project’s container config and set up your own? Or just skip containers entirely?

Skip containers usually, if one isn't provided that works it's unlikely there's time or budget for me to maintain my own.

Re: Thoughts on Svelte(Kit), one year and 3B requests later

#194
post #150

Earlier quoted context omitted.

You can just wait for the network request to finish before continuing. Many actions require it anyway. Asynchronous code should be intentional and deliberate in my opinion, but in modern JS/Node it is the default which leads to all kinds of crazy workarounds, callback hell and race conditions. Node has the same issue PHP had now, where green devs will crank out code without realising they need to be watching out for…

What's not deliberate about marking a function as `async`, and marking calls that need to be awaited with `await`? Callback hell? When was the last time you gave an honest effort into JavaScript?

Most libraries are async and some standard lib stuff is unexpectedly async as well, so you are often handling async concerns even if what you're writing is better syncronous.

My team and I don't write callback hell, it's just a very common pitfall and you still see it all the time. You can't bubble wrap everything I suppose.

Re: Thoughts on Svelte(Kit), one year and 3B requests later

#195

Earlier quoted context omitted.

One of the exact reasons I've been working with Aurelia as my Javascript framework of choice since 2015. Aurelia 1 has served me well and I have apps that have been in production for eight years untouched. They just keep running without fail and they're so simple. Similarly, Aurelia 2 (currently in beta) is even better and as stable (same templating syntax, DI, etc). I tend to avoid all of the hype in the front-end s…

2015 was when I used Aurelia, too. As someone who used the first version of Angular, it was a breath of fresh air, and I agree that you can get results quickly using Aurelia. I left that company so haven't been using it, but I've secretly hoped people would catch on and switch to it somewhere down the road. But as you say, it's fine that it's not popular--quite often, the best things are not the popular things.

Sadly, Aurelia didn't quite catch on like other options. But, it's funny when you look at libraries like Svelte, many of their touted features like reactivity not only existed in Aurelia, but in Durandal before it. I think it comes with age. I'm in my mid-thirties now, so I just use what I want to use that gets results. But I remember being young and hungry as a developer in my twenties, you used what everyone else used because of job prospects.

I think Aurelia 2 still has the potential to make a comeback. Maybe not popular like React or Vue, but still. The beta has been quite good. It just needs more awareness.

Re: Thoughts on Svelte(Kit), one year and 3B requests later

#196

Earlier quoted context omitted.

I think you may have missed that you can circumvent all of this by declaring your components to be client components.

What's the point of using RSC if you have to mark everything as client components? At best you're getting SSR support since client components actually run on the sever as well, but there are already cleaner solutions for SSR react components that rehydrate in the browser.

You're not using RSC if you're marking everything as a client component. The point is that you can do that and continue to use your old components while also able to use the new app router infrastructure.

Re: Thoughts on Svelte(Kit), one year and 3B requests later

#197

Earlier quoted context omitted.

What's the point of using RSC if you have to mark everything as client components? At best you're getting SSR support since client components actually run on the sever as well, but there are already cleaner solutions for SSR react components that rehydrate in the browser.

You're not using RSC if you're marking everything as a client component. The point is that you can do that and continue to use your old components while also able to use the new app router infrastructure.

Is there that much benefit to just the file structure and router?

That feels like a ton of refactoring just to have the same and result for a user, but maybe I'm missing some important gains of the app directory.

Re: Thoughts on Svelte(Kit), one year and 3B requests later

#198
post #59

Earlier quoted context omitted.

I don't want people preaching hooks as the greatest invention since fire talks anyways. Such code if spotted anywhere in a backend would be slammed for being horrendous and violating almost any intuition definition of maintainable code. The svelte documentation is already great. This evengleism is good for commercial products. For technical open source, subjective evaluation is all that is needed. You evaluate whethe…

Rich Harris is definitely not a humble guy. He pretty much can't talk about Svelte without framing it as the savior to modern web. And I would say some of the things he pushes are blatantly false

He’s usually right though. And when he is not, he’s one of the fastest to admit it.

Re: Thoughts on Svelte(Kit), one year and 3B requests later

#199
post #67

Earlier quoted context omitted.

Could you please give a heads up what makes Seveltkit difficult in a larger code base?

Personally, I really missed the larger state management libraries that are well-available for react. Layouts, passing difficult props to components, passing state up and down in the tree (i.e. refs) Feels like SvelteKit has a major - just use whatever SvelteKit offers, which is generally enough for smaller projects.

Svelte Stores and connect api are a simpler and more powerful solution to this than any library I’ve ever used. I’m curious what you would recommend.

Re: Thoughts on Svelte(Kit), one year and 3B requests later

#200

I like the fact minimalist approaches, like svelte, htmx and alpine.js are getting more and more traction. I felt like fighting this fight alone for years in the golden years of node, webpack and react where everybody was creating crazy stacks and adding GraphQL and so on, to basically get what Django + jquery did 10 years ago in a tenth of the time and code. So far I also survived: - xml is the future - let's use no…

Nice list; I am not a primarily front-end dev so I can't say I've lived this but I've been around long enough to remember all of these; sometimes painfully.
Post reply on HN