Live data from Hacker News

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

claudioholanda.ch

201–210 of 222 posts

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

#201

Earlier quoted context omitted.

I like Svelte but I’m not sure I’d describe it as “minimalist”. It’s a new language with its own compiler and reactivity system.

Yeah, I did a project in sveltekit + go and then one in htmx, alpinejs + golang. Sveltekit is quite big and not low maintenance. Not sure what exact use case sveltekit would be good for, that can't be solved with htmx + alpinejs.

> Not sure what exact use case sveltekit would be good for, that can't be solved with htmx + alpinejs.

I mean, reductio ad absurdum:

    s/sveltekit//; s/htmx + alpinejs/assembly/;
Of all of pg's writings, the one with "the blub paradox" in it has proven to me to be the one I see crop up again and again.

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

#202
post #184

Earlier quoted context omitted.

Cool site! I just looked through your repo. I'm still relatively new to SvelteKit and rewriting a similar content based site from React. What led you to use the SSG adapter vs the node adapter (which uses SSR)? How long does the build take to pre-render all of your content pages like the sea life? Was there a particular reason you didn't want to use Form Actions? Not criticizing your decisions by the way, I'm mostly…

Thank you! I've tried to address your questions below. Most of these decisions stem from having the backend written in Rust, & using GraphQL. That decoupling in the end made it a lot easier to port from react. - I am using a rust backend for the static files and didn't want NodeJS part of the request workflow. Most pages aren't changed all that much, like maybe once every few months & so having yet another service as…

Awesome thanks for getting back to me, all of those decisions make sense to me :)

Cheers

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

#203

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…

My org uses serverless to great success. I highly recommend trying it out if you haven't. It's just so nice to create a function and know we don't have to configure any part of the server to know it'll run, and then the true benefit comes from the almost infinite-feeling scale we can get at a super low price.

Of course, serverless is a misnomer. But it does mean you have to think of the server much less.

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

#204

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…

> xml is the future

Isn't that what htmx and alpine.js are essentially based on?

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

#205
post #47

Earlier quoted context omitted.

It's the second, younger generation of devs who are realizing that "complexity kills". Those of us who started in 2000's have already seen this. It's a natural cycle. We are seeing a spring-back to monoliths and away from micro-services and crazy tooling chains. It was completely unnecessary, and most importantly, cost the industry a fortune. If you are older, you have been wondering why you need to work more to achi…

This sounds like a symptom of you falling behind the technology curve more than a problem with the technology curve. Most people are achieving vastly more with newer tech than ever could have been done in the early 2000s. You've gotta be looking through some densely rose colored glasses if you think that that the web in the 2000s was just as powerful as the web of today.

This comment is arrogant and objectively isn't correct.

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

#206

Earlier quoted context omitted.

Well done! From inspecting the html: - sanity for cms - tailwind for css - partytown for running script in web worker - most of the icons on the footer are just unicode emojis, no separate library just for icons....nice! Only feedback I have: - the sticky footer looks like what you would see in a mobile view and looks a little odd in desktop (I am not on a phone atm) - Home page drop down in top left and some footer…

Appreciate you! I'll take the feedback into account. The footer items are redundant yeah, but from an SEO standpoint it works pretty well.

regarding the font issue -- it is very disorienting: https://imgur.com/a/MCG3VZl

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

#207

Earlier quoted context omitted.

Honest question: how is htmx/svelte/alpine any different than other trends? Could it just be that you prefer this particular spot in the trend cycle?

I think that’s parent comments point. They like that the trends are swinging from complexity to simplicity.

But that was the line that noSQL advocates were pushing. You don't need this big complex relational database, just make everything simple JSON and call it good.

Then it turned out that data actually is just complicated, and managing that complexity is off and easier with a relational database.

Sometimes simplicity can be an illusion.

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

#208

Earlier quoted context omitted.

This sounds like a symptom of you falling behind the technology curve more than a problem with the technology curve. Most people are achieving vastly more with newer tech than ever could have been done in the early 2000s. You've gotta be looking through some densely rose colored glasses if you think that that the web in the 2000s was just as powerful as the web of today.

This comment is arrogant and objectively isn't correct.

Your parent comment definitely came off as arrogant, but your reply doesn't come off any better. If it's objectively incorrect, then you can contribute to discussion by explaining how and why. A low effort drive-by dismissal isn't appropriate for HN.

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

#209

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…

Wouah ! Sam&Max, je me demandais bien où vous étiez passé.

En ce moment on s'amuse à générer du hentai avec stable diffusion en Python. Ca aurait fait un bon article pour le blog si il existait encore :)

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

#210

Earlier quoted context omitted.

This comment is arrogant and objectively isn't correct.

Your parent comment definitely came off as arrogant, but your reply doesn't come off any better. If it's objectively incorrect, then you can contribute to discussion by explaining how and why. A low effort drive-by dismissal isn't appropriate for HN.

This is anecdotal, but I have been in the industry > 10 years now and worked for a lot of employers. What they have required of me for the frontend has pretty much been the same more or less throughout. But recently, with the large amount of funding, companies have had a large blow up in payroll and a talent shortage. The talent shortage has resulted in some juniors getting hired that would not have gotten hired during the great recession. These juniors, on average, need to know a lot more now than back then due to the complex stack. This has resulted in a lot of breadth of knowledge but not a lot of depth. Over time , large teams of inexperienced people have turned what could be a simple frontend created by 1-2 developers in a large 15 developer behemoth that is difficult to maintain and keep secure. It is difficult to reason about for most newer developers so a lot of the time is spent handling edge case bugs instead of getting the job done. Usually their needs really aren't different. It's often just an intranet app or b2b. These don't have scaling needs and you can create reactive asynchronous websites without the complexity here and without reinventing the wheel. Sometimes, the complexity introduced by this complex stack is required (i.e. the app being created is complex). Everyone thinks their app is complex. It almost always is not complex, at least on the frontend, and it could have shipped earlier and with less bugs if the complex stack was not introduced.
Post reply on HN