Live data from Hacker News

SvelteKit 1.0

svelte.dev

261–270 of 296 posts

Re: SvelteKit 1.0

#261
post #253

Is there any option if I want to do traditional (non JS) SSR but also want to share an API endpoint for both browser and other use cases? Seems like a JS frontend framework or a JS SSR is the only option for such use case. If SSR and API force a JS backend that leaves a lot of the benefit that other languages bring to the table and effectively limiting you to 1 (JS) or 2 (TS including) languages. Seems like a sad sta…

You can have any kind of backend with Sveltekit, and call it from client or server (or both). You can even completely bypass sveltekit per request.

Re: SvelteKit 1.0

#262
post #66

There is a plethora of javascript frameworks: React, Vue, Svelte, Remix, etc. If I know nothing about front-end development, and would like to learn one that is: - Intuitive - Suitable for small projects as well as large projects. - That is here to stay, i.e. either adopted by many companies, or its adoption curve is going up. Which one should I pick? Would Svelte be a good choice?

I've used many frameworks and in my opinion Svelte+Sveltekit has the very best simplcity over power ratio. If you don't mind job offers being quite scarce for this stack right now that's about the best choice. You can do the Svelte tutorial for a sneak peek of this.

Re: SvelteKit 1.0

#265
post #143

Earlier quoted context omitted.

complex dashboards like CircleCI or client portals like maybe your bank or health insurance portal many pages and lots of functionality with lots of data floating around like Reddit, Twitter literally everything/anything like Facebook, GitHub, etc For simple apps, I'd go with a PWA if possible. For single, mostly informational, pages you usually just need a static site. For a company blog, some of these tools could b…

Maybe https://beta.music.apple.com/ qualifies? =)

What is apple doing there? They mix ember with svelte? o_O

Re: SvelteKit 1.0

#267

Earlier quoted context omitted.

The src/routes/posts/[slug]/+page.svelte thing is pretty recent, it used to be just src/routes/posts/[slug].svelte. I'm not exactly thrilled with the new naming...

I left the framework for this reason. When I asked about it, I was told "this is what Next will be doing soon". I need more reasoning than that, and it was indicative of the decision making process. Turned me off. Aside from that, Svelte is SUPER fast and easy to use. I may give it another go at some point.

I thought it was weird and couldn't see the reasoning, but personally I just persisted with using it and in the end I've found the new structure perfectly workable and perhaps even marginally prefer it. So yeh, it might seem stupid but maybe just try and use it more to find out if it's really that big of a problem for you. The rest of the gains I've had from SvelteKit were too good to pass up, it's overall just a superb dev experience.

Re: SvelteKit 1.0

#268

Fantastic news! Although I loathe writing libraries [1] in Svelte, I love writing apps and kit is great extension to server side. I like similar to Remix push for Web APIs, like forms for mutations etc. I like nested layouts with data endpoints. I like that most of the internal state is visible as reactive store. [1] Creating complex type definitions for more generic components is hard and require knowledge about int…

>Creating complex type definitions for more generic components is hard and require knowledge about internals. This is what turned me off of Svelte initially. Usually when I make websites I start by defining some primitive components like or . I could not figure out how to type my component so that it takes every single attr and event that a regular takes plus some extra attrs that I want to define (theme, size, etc.)…

Auto-define exports of native properties for a child widget. This should be posted as an issue on the Svelte core repo. It would save a ton of time building components!

Now that Kit 1.0 is out the door the team can turn their attention back to Svelte proper so now is the time.

Re: SvelteKit 1.0

#269
post #143

Earlier quoted context omitted.

What would be an example of large scale for a front-end app or site?

complex dashboards like CircleCI or client portals like maybe your bank or health insurance portal many pages and lots of functionality with lots of data floating around like Reddit, Twitter literally everything/anything like Facebook, GitHub, etc For simple apps, I'd go with a PWA if possible. For single, mostly informational, pages you usually just need a static site. For a company blog, some of these tools could b…

Not huge but couchbase use svelte for their online offering https://cloud.couchbase.com/sign-up

It's got some cool db/sql stuff in there

Re: SvelteKit 1.0

#270

Earlier quoted context omitted.

> With ASP.NET, a React/Angular project is separate, there's a separate model layer, and you have to keep that in sync with the .NET models. The separation of models is indeed inevitable when there is JS on the client and not-JS on the server. That's a 'problem' common to all non-JS back-ends. However there are three points I'd make. 1. That's often a good thing, not a flaw, in that it enforces a mapping boundary bet…

> 1. That's often a good thing, not a flaw, in that it enforces a mapping boundary That just sounds like mandatory busywork that may or may not prevent poor programming practices. I'd rather pick a framework for productivity. > 2. Mapping requirements of this type are much too trivial to base a tech stack choice on. Trivial for large corporations with money to burn, maybe. A huge time-waster for my startup. > 3. If t…

> That just sounds like mandatory busywork that may or may not prevent poor programming practices. I'd rather pick a framework for productivity.

Mandatory busywork implies stuff with no real purpose. I specifically pointed out the purpose. You may not agree with the cost/benefit involved in doing it, but that's a preference and doesn't automatically make someone else's way of working busywork. And personally I find it increases productivity by eliminating a whole range of security concerns.

> Trivial for large corporations with money to burn, maybe. A huge time-waster for my startup.

This largely depends upon if you accept that the work itself is of benefit. If you believe it's just busywork, then whilst my own opinion differs, your conclusion is reasonable for your situation.

> Blazor is cool, but the bundle sizes are still too large right now, and it doesn't have the ecosystem of web components that JavaScript does.

You're right on the sizes and the ecosystem (though that is not Blazor-specific and is something no non-JS client-side tech will ever be able to compete with).

I do ASP.NET and Blazor (alongside Node, Go, Python, Rails etc) and TBH whilst personally I see great value in Blazor it feels like that's mostly for back-office or enterprise applications where you get the incredible productivity (that much is true) and don't need to worry about the sizes or, depending on how you implement it as this is optional, the need for a persistent web-socket connection.

Post reply on HN