[HN Gopher] My Evaluation of SvelteKit for Full-Stack Web App De...
___________________________________________________________________
My Evaluation of SvelteKit for Full-Stack Web App Development
Author : todsacerdoti
Score : 181 points
Date : 2022-01-05 08:05 UTC (14 hours ago)
(HTM) web link (cprimozic.net)
(TXT) w3m dump (cprimozic.net)
| pier25 wrote:
| I've been using Svelte as my main framework for the past two
| years. I'm still very happy with it and will continue to use it.
|
| It has many advantages but the main reason for me is that it
| simplifies your front end code. It's not perfect by any means,
| but overall its cons are worth it IMO.
| newsbinator wrote:
| What do you use for UI components? I recently built my first
| SvelteKit project and using Tailwind to compose UI components
| vs. Vue+Vuetify was like writing binary by hand instead of
| using an expressive modern language that abstracts away 99% of
| plumbing.
|
| What takes 10 seconds and 20 chars in Vuetify takes 10~100
| minutes and multiple components/sub-components written by hand
| in Tailwind in Svelte.
|
| Of course talking about Tailwind isn't Svelte/SvelteKit
| specific: I just couldn't find a remotely comparable UI library
| for Svelte so I gave up and stuck with Tailwind to get the
| project done.
| swyx wrote:
| > The entire frontend was only ~75KB, and ~32KB after gzip!
|
| i think this is the pull quote. the whole app (https://sveltekit-
| todo.ameo.dev/) with complete with drag and drop and crud, comes
| in at 59-75% the size of the _base_ runtime of React (7k, 3k
| gzip) + React-Dom (121k, 39.4k gzip).
|
| and js bundle size isnt everything - Svelte wins on other
| developer experience factors as well, and is just missing
| ecosystem as OP noted.
| kirso wrote:
| As a beginner, I can't really emphasize how frustrating
| learning React is... at least compared to Svelte which is
| really just easy to understand and learning curve is less
| steep.
| richeyryan wrote:
| One thing to be very mindful of is that is a very limited
| application. The footprint of the various frameworks changes
| based on how big your application gets as shown here[1]. Swyx,
| I think you are probably aware of Ryan's article but it's worth
| contextualising for others who might not be familiar. The more
| components you have the more Svelte loses its edge.
|
| [1]https://dev.to/this-is-learning/javascript-framework-
| todomvc...
| swyx wrote:
| yes am aware, but also in any realistic scenario, code
| splitting comes in well before the crossover point where that
| even remotely comes into question. this has been
| independently verified twice now:
|
| https://twitter.com/sveltesociety/status/1301168598988107776.
| ..
|
| https://svelte-scaling.acmion.com/
|
| https://github.com/halfnelson/svelte-it-will-scale
|
| sveltekit has further opportunities for whole-app
| optimization but honestly given this research i lost interest
| bc its more than good enough
| sandreas wrote:
| Some time ago I created a svelte app with routify and scss[1] and
| it felt great, looks like sveltekit is the official successor of
| this stack.
|
| I still love the fact that svelte is "compile time" and not
| "runtime" JavaScript.
|
| What I'm missing a bit on all these reviews unfortunately
| automatic component testing (e.g. with Jest[2] or Jasmine)...
|
| [1] https://pilabor.com/blog/2021/07/svelte-spa-with-
| typescript-... [2] https://koenvg.medium.com/setting-up-jest-
| with-sveltekit-4f0...
| fruit2020 wrote:
| Why do people prefer full stack for these sort of frameworks.
| Doesn't it create more lock in? What's the problem with frontend
| + backend api, the api can even be javascript if people only know
| one language.
| [deleted]
| newlisp wrote:
| SSR. It turns out most devs can write reliable SPAs so you need
| some sort of hybrid.
| capableweb wrote:
| Same reasons some people like their frontend or backend
| frameworks to have everything in one place, to have everything
| in one place.
|
| I prefer to compose libraries that carry exactly the
| functionality I need, and pipe them together myself. But I'd be
| a fool if I didn't realize that most people start projects
| today via some sort of framework that promises (and probably
| does) a "battery-included" sort of solution, where most of the
| pieces you'll use have already been put together for you, and
| you just need to write models, controllers and views (but your
| framework might call them something else).
| pier25 wrote:
| Because SSR has a couple of advantages depending on the use
| case.
|
| The most obvious is SEO and being able to send HTML without any
| JavaScript.
|
| Doing SSR is also simpler than a well made SPA, generally
| speaking. Your api can be reduced to post requests, or removed
| entirely. The routing and navigation is much simpler. Etc.
| tarjei_huse wrote:
| I love Svelte and find it refreshing.
|
| The only thing I react to is the part about "It feels much like
| Rust vs. C++. Rather than adding layers upon layers to existing
| infinitely backwards-compatible software, it takes the best
| patterns and features and builds them from the ground up.".
|
| Svelte bungled this in one place and that is in the html coding.
| For example Svelte has different syntax for if ({#if}, else
| ({:else}) and endif ({/if}. I end up looking this up in the
| documentation way too often - especially when not doing Svelte
| fulltime.
| pier25 wrote:
| Why not use a snippet that will write it for you?
| tumblen wrote:
| I use Svelte full-time and absolutely love it, but I do have to
| admit I sometimes wonder what lead to the decision of
| {#if}{:else}{/if}, {#each}{/each}, etc syntax. Seems like there
| had to be less verbose, more consistent approach... But, I'm
| probably not fully-aware of the constraints and missing
| something.
|
| I sometimes miss the brevity of the React way (which can also
| be good and bad) for handling conditional code-blocks {visible
| && <Component>} or {visible ? <Component1 /> : <Component2 />}
| licyeus wrote:
| I initially preferred JSX ("it's just Javascript"), esp. with
| Svelte oddities like `$$props`, but after working with Svelte
| templating for a while I now prefer it due to things like
| property shorthand and event forwarding.
|
| Re: `:else` syntax, I also made mistakes (`#` and `/` were
| familiar having worked with Handlebars/Mustache) until I
| internalized that `:` meant block continuation (also used with
| await/then/catch).
| FL33TW00D wrote:
| I've been looking at doing a Desktop GUI POC with something like
| Tauri and Svelte - has anyone had any success?
| square_usual wrote:
| It's come up more than a few times on the svelte discord - you
| should join and check out the projects that've been posted in
| the past. I don't think anybody ran into any major issues with
| Tauri + Svelte yet.
| square_usual wrote:
| In contrast, I had a not-so-great experience attempting to use
| SvelteKit for a not-full-stack SPA. I wanted an SPA "app" for a
| side project I'd already written in Elixir/Phoenix and kit turned
| out to be super immature for that. There's a lot of issues with
| building a "true" SPA in kit - it is built first and foremost for
| full stack and will throw up a hundred ways if you try to make an
| SPA, chiefly by making it inconvenient to use client-only
| libraries even though you're _never_ running on a server. Svelte
| is pretty cool but if you want to make an SPA I would recommend
| vanilla Svelte + Routify instead of Kit.
|
| (Or just React. React is pretty good, and vite comes with a React
| starter that's super good! You don't have to throw something out
| just because it's "old"!)
| djKianoosh wrote:
| How does Routify compare with svelte-spa-router[1]? I really
| like svelte-spa-router for a simple SPA, though I think a lot
| of SPA routers don't always handle state well.
|
| [1] https://github.com/ItalyPaleAle/svelte-spa-router
| hdra wrote:
| Had the similar experience, and as it happens, I was also
| looking to build something with Elixir/Phoenix backend..
|
| Its nice that it comes with a proxy `fetch` implementation that
| you can use to make requests to your API backend from the
| svelekit "backend", but there are many leaky API surfaces
| around it, esp when dealing with cookies.
|
| The docs is also rather lacking regarding the many callbacks
| that can run on both server/client, though it is somewhat
| understandable given everything is still very much in flux...
| whiddershins wrote:
| We used sveltekit for the front end of our most recent project,
| and had pretty much zero problems.
|
| If you want to do _true_ front end though, I hear your pain.
| The biggest issue I had was I never could figure out how to
| make all my resource paths work with the static adapter, so I
| was put in the position of having to redo every image reference
| (for example) if I wanted to build static files. Pretty
| frustrating.
|
| But if you are just doing SPA deploying to vercel for
| development I think sveltekit is just brilliant and just works.
| Ameo wrote:
| SvelteKit now has a static adapter[1] which is designed for
| those kinds of scenarios, defaulting to pre-rendering all pages
| and not requiring a server I think. I've not tried it out
| myself though, but it might be good for that if you want to
| bring your own API.
|
| > I would recommend vanilla Svelte + Routify instead of Kit.
|
| That sounds like a solid way to go as well. SvelteKit has some
| nice tools for 100% static sites that do stuff like generate
| pages at build time from markdown and stuff like that. But if
| your site is really simple, then that works fine.
|
| [1] https://www.npmjs.com/package/@sveltejs/adapter-
| static/v/nex...
| square_usual wrote:
| I tried the static adpater, but it still has issues as
| acknowledged here:
| https://github.com/sveltejs/kit/issues/1650
|
| In that thread, you can see some of the ugly workarounds
| people have to go through to make purely client-side apps: ht
| tps://github.com/sveltejs/kit/issues/1650#issuecomment-984...
| uxcolumbo wrote:
| Why did you want to rewrite your Phoenix app as a SPA?
|
| Just to learn new things or because Phoenix is lacking? Have
| you tried LiveView?
|
| And can't you use React with Phoenix?
| slantyyz wrote:
| Sounds like SvelteJS is a better option for you than Sveltekit.
| stepbeek wrote:
| Great write up, but I'm surprised by SvelteKit being described as
| full stack. It doesn't seem to offer anything around normal back-
| end functionality. I've normally understood full-stack to refer
| to a framework like Ruby on Rails.
| qbasic_forever wrote:
| It has a backend component, you use an adapter to run it on
| edge/lambda services like cloudflare, or plain old nodejs. In
| usage it's kind of murky (by design) where the exact
| delineation is between code running on the frontend and code
| running on the backend.
| l-lousy wrote:
| He mentions using Rust/Rocket and SQLite in the article, I
| think it was just focusing on the front end library
| Ameo wrote:
| It's definitely full stack; it has endpoints[1] which are just
| arbitrary API endpoints where you can implement any logic you
| want (talk to a database, perform conditional logic, etc.).
|
| It may not be a fully-loaded solution like rails, but
| minimalism can have its own benefits.
|
| [1] https://kit.svelte.dev/docs#routing-endpoints
| mathnmusic wrote:
| How do you run background jobs (either schedule-based or one-
| off like sending emails)?
|
| How do you hold a websocket channel with the client to push
| real-time updates?
|
| IMHO, "Full stack" means a lot more than "can talk to the
| database".
| slantyyz wrote:
| For the background jobs, you can implement that in the
| hooks file using your node scheduling library of choice.
| nicoburns wrote:
| Perhaps it means something different to the Ruby community.
| But I've most commonly seen "full stack" used to simply
| mean "both frontend and backend". So if it's running code
| on the server and the client then it's full-stack.
| xcambar wrote:
| SvelteKit enables the BFF (backend for frontend) pattern
| nicely, meaning it can proxy and stitch together your actual
| API, exposing SPA-specific endpoints.
|
| In the other hand, I don't see how you could use it as a
| primary backend, it just does not support anything beyond
| routing. Which is nice, not every tool should do everything
| (on the contrary) but it is important that the developers are
| not mistaken with regards to what SvelteKit is fit for as a
| backend.
| midrus wrote:
| Because for some folks being able to execute JavaScript in the
| backend is enough to consider it a backend framework.
|
| That gives you an idea of how deep the backend knowledge is
| some times. Scary.
| square_usual wrote:
| It's "full-stack" in the sense that it's not _only_ client-side
| - it 's more like next in that you have code that lives on a
| server and can respond to client invocations, which is useful
| if you want to do server-side rendering and so on. It has some
| neat payoffs - you can use cookies for auth even if your
| frontend lives on a different domain, because the frontend
| server can read those - but IME it's a pain if you just want an
| SPA, and despite what most of the Kit community thinks, those
| are still pretty useful. You can't SSG an E2EE chat app.
| Glench wrote:
| Man, Svelte / SvelteKit is amazing.
|
| Svelte components run super fast (no virtual DOM), have tiny
| build sizes, stellar interactive documentation, and the developer
| experience is fire. Svelte was also just voted the #1 most loved
| web framework in the 2021 Stack Overflow developer survey (it
| beat out React, Rails, Django, Spring, Laravel, etc ):
| https://insights.stackoverflow.com/survey/2021#section-most-...
|
| I've also really been loving SvelteKit which isn't even out of
| beta yet.
|
| Things I like about SvelteKit: - It removes all
| the annoying front-end/back-end plumbing you have to do in every
| app. Backend APIs, JS/TS, HTML, and CSS just work together with
| no configuration. - I can use JS/Typescript
| throughout the entire stack - File-based routing is
| a dream -- I never have to search through code to figure out how
| to edit a page! - SEO-friendly and performant
| server-rendered routes with client-side hydration -
| Static generated pages you can specify individually (you can
| include the marketing site and app in the same bundle!)
| - Optional client-side routing for really fast app-like UIs
| - Tiny bundles and fast performance thanks to Svelte
| - The dev experience is an absolute delight
|
| I love it so much I decided to package up and release a template
| with all the stuff most apps these days typically need: user
| auth, admin dashboards, etc: https://www.sveltesaas.com/
|
| Can't wait till SvelteKit hits 1.0!
| throwaway675309 wrote:
| You've worded this message to give the impression that you've
| already created a template that is available for consumption
| _now_ , so spamming a link that just wants to collect our email
| addresses seems slightly disingenuous.
| bufferoverflow wrote:
| When I go to your link, it just says "coming soon".
| Glench wrote:
| Yep, it's not quite ready yet. Put in your email if you want
| to know when it's out -- I won't spam you :)
| midrus wrote:
| I'm really surprised at how easy anything is considered "full
| stack". Where is the ORM/data access library? The validation
| framework? The background jobs? The caching system? The
| translations/i18n system? And the other 1000 things you do need
| for a full stack real life application? I definitely do have
| those things in Laravel, Django and rails. Next.js, nuxt.js,
| sveltekit etc are far, far from full stack. They can certainly
| run js in the backend, but that's not full stack, you still need
| 10s of other packages.
| besil wrote:
| I really feel your point. Django is my favourite framework but,
| as for Rails or Laravel, sometimes you need more reactivity to
| build an app.
|
| The two worlds can live together: I use Django and it's
| features (including templating) along with Svelte, served from
| Django itself.
|
| I wrote a post, if you are interested https://dev.to/besil/my-
| django-svelte-setup-for-fullstack-de...
| lars_francke wrote:
| I recently started a side project for our company in SvelteKit
| (I have zero Frontend experience) and while I really enjoyed
| the Frontend bits I found the backend bits lacking.
|
| I know it's not GA yet so I don't want to complain and I'm
| happy to wait for the final release. The documentation is
| severly lacking (e.g. routing) and best practices are missing.
| I found the same as you: Most articles about SvelteKit don't
| talk about the backend/storage part at all. There is the
| template example app which has a bit of structure but that
| doesn't go very far, there are a few articles here and there
| but they mostly mock interactions with any further services.
|
| So my verdict was: Fullstack, maybe-ish, but not for newcomers
| (which they also don't advertise for). You need to know what
| your're doing and which additional tools to use. And, as you
| point out, that's different in Django et. al.
| slantyyz wrote:
| > Most articles about SvelteKit don't talk about the
| backend/storage part at all.
|
| That's because a lot of Sveltekit users appear to prefer
| serverless and don't use the back end.
|
| Personally, I like that Sveltekit's back end doesn't have
| batteries included.
|
| Coming from Express, I was able to pick up Sveltekit pretty
| easily (although I have some quibbles with the
| documentation). I would have preferred that Sveltekit's back
| end use Express' Request and Response, but the Sveltekit devs
| have their reasons for not doing that.
| Glench wrote:
| > Where is the ORM/data access library? The validation
| framework? The background jobs? The caching system? The
| translations/i18n system? And the other 1000 things you do need
| for a full stack real life application?
|
| Right here! https://www.sveltesaas.com/ :)
|
| I love using SvelteKit for full-stack apps so much that I
| decided to package up and release a template with all the stuff
| that most apps these days typically need.
| bufferoverflow wrote:
| When I go to your link, it just says "coming soon".
| Glench wrote:
| Not sure why you made this same comment twice, but yep,
| it's not quite ready yet. Put in your email if you want to
| be notified when it's out -- I promise I won't spam you :)
| bufferoverflow wrote:
| Because you keep spamming the link that doesn't have what
| you promised.
| l-lousy wrote:
| Did nobody read he was using rust/rocket and SQlite for the
| backend?
| capableweb wrote:
| Gatekeeping what should be called "full stack" based on your
| own requirements seems futile at best. Believe it or not, there
| are businesses built without using those things, even though
| you've never come across that in your life.
|
| Besides that, I think the things you're looking for are listed
| here: https://sveltesociety.dev/components/
|
| Never used Svelte/SvelteKit myself, but seems the framework
| takes a "some batteries included, others available" approach to
| the whole thing, which is one way to about it as well.
| aeze wrote:
| I don't consider what he said gatekeeping, they were valid
| questions IMO.
| csmpltn wrote:
| [deleted]
| tobr wrote:
| The _top comment_ in the thread has been "cancelled"? Do
| you feel like that usage of "cancelled" is stable ground we
| can all stand on?
| csmpltn wrote:
| slantyyz wrote:
| Who is shunning that person? Nobody's trying to get them
| fired or boycotted, so where is this "cancelling"
| happening?
| detaro wrote:
| By the same standard, you are "cancelling" capableweb
| because you accuse them of doing something you find
| unacceptable (in a worse way, since most people would
| consider "cancelling" to be a worse accusation than
| "gate-keeping"). Not really a useful level for the word.
| newsbinator wrote:
| > Shunning an individual by accusing them of acting in an
| unacceptable manner is "cancelling" them isn't it?
|
| Yes. But replying to an individual and telling them why
| they are incorrect and what you believe correct to be
| isn't shunning and isn't canceling. It's dialog. Reading
| interesting discussions is the reason I come here and
| participate. Echo chambers aren't interesting.
| midrus wrote:
| Yes, precisely because I've been involved in maintaining
| codebases built without real full stack frameworks is why I
| say what I said.
|
| The problem we have in this industry, is that somebody reads
| these blog posts, and the next day at work they ditch the
| "legacy rails" and starts rewriting the monolith in
| sveltekit/nextjs/whatever because that's what he/she has been
| told is the modern way to do full stack.
|
| No need to say those engineers will quit 1 year later after
| they realize the mess they've created with their lightweight
| and simple modern framework.
|
| I've seen this too many times already.
|
| It is not about gatekeeping. It is about engineers being
| humble and assume it is very likely that their code is very
| unlikely to be better tested, documented, cohesive and
| maintained than what you're given in the real full stack
| frameworks.
|
| Of course you can build anything even in assembler if you
| want. The question is if that's the most useful thing to do
| with your company's money.
| nesarkvechnep wrote:
| I'm 100% with you on this. I've worked with many people who
| thought they're full-stack developers just because they use
| these "full-stack" frameworks. Some of the guys didn't know
| what a foreign key is but wanted to use reactive
| programming. Some of them didn't know what's a REST API but
| bashed the pattern and praised GraphQL. You get what I
| mean.
| andrew_ wrote:
| This word play isn't worth the time or effort. Shall we try
| to apply the meaning of full stack based on my own entry
| into web development in 1998 when N-Tier development was
| all the rage? I think not.
| slibhb wrote:
| You're arguing about configuration vs convention. You can
| prefer batteries-included frameworks (convention). Other
| people can prefer a barebones approach (configuration).
| Either way, it's full stack if you can write code that runs
| on the server and code that runs on the client.
| midrus wrote:
| Convention is what you have in rails. Configuration is
| what you have in Django. What you have when you need to
| take 1k decisions per second and tie things together to
| kind of reproduce something usable as a whole is
| something totally different.
| newlisp wrote:
| _Either way, it 's full stack if you can write code that
| runs on the server and code that runs on the client._
|
| I wouldn't call it full stack without a database.
| capableweb wrote:
| Clearly, we're not gonna reach any conclusion in this
| debate of what it means. So what's more fun than stop
| arguing over definitions? Polls, of course! Here is one:
| https://news.ycombinator.com/item?id=29811603
|
| Once completed, we have our answer :)
| xboxnolifes wrote:
| While I all generally think of a database being a part of
| _full-stack_ , I'm not so sure that it makes sense to be
| a prerequisite. A database is just a tool for storing
| data. If all you need is in-memory data, flat file, or
| even no long-term data at all, I see no reason the
| requirement of _long-lasting data_ to be a requirement
| for full-stack.
|
| That being said, the more I keep thinking about it, the
| less useful the term full-stack even feels. Why is front-
| end + back-end + database (+ other?) the full-stack? Why
| not also require third-party integrations? What about the
| hardware? Should the definition of full-stack expand as
| the options do, or should it stay static at whatever it's
| original usage was?
| mgkimsal wrote:
| "Why not also require third-party integrations" - it
| almost has to include that anyway, but.. the skill set
| required to understand and work with third-party
| integrations is almost certainly going to be a subset of
| 'front-end' or 'back-end' anyway. Mastery of client side
| and mastery of server side are distinct enough that those
| sort of 'what abouts' you raised seem to fall under the
| broad 'front/back' domains already, no?
|
| There's enough virtualization that 'hardware' itself is a
| somewhat elastic term. However, I've had to deal with 4
| different devs in the last few months, all trying to get
| set up with one of two projects. Both are docker-based.
| But... "well, I'm on windows... I'm on WSL... I'm on Mac,
| but M1... I'm on Mac, but Mojave, and this doesn't
| work..., oh, I can't have 2 things running on the same
| port?" Unless every single person is on the exact same
| hardware/OS combinations, having some understanding of
| 'hardware and OS diffs' and how they may impact you may
| still be necessary.
| [deleted]
| adamors wrote:
| Some gatekeeping is necessary because soon JS frameworks will
| have redefined everything making it impossible to converse.
| capableweb wrote:
| Guess what, language evolves :) With setting up context
| before jumping into the nitty gritty details, even you can
| make sense of what others are saying.
| foobarbecue wrote:
| Yes, and we have a responsibly to guide that evolution.
| midrus said he was "surprised" that the meaning of full
| stack is changing to mean all the frontend and a few bits
| of the backend. I'm also surprised, and disappointed. To
| me, Django is full-stack. Meteor was full-stack.
| SvelteKit is not.
| midrus wrote:
| Language does not matter. What matters are frameworks,
| tools, ecosystem, libraries and developers availability.
| All langues are good enough and shit at different things.
| davedx wrote:
| I really don't think it's fair to call it gatekeeping. The
| blog title is about using "Sveltekit for full-stack web app
| development" but if you want to make a full-stack web app,
| you need more than Sveltekit.
|
| Words mean things.
| detaro wrote:
| > _Words mean things._
|
| And as the reaction here shows, for lots of people "Full-
| Stack Web App development" means "spanning frontend and
| backend", not "frontend and backend and everything you
| could need for a complex product". And that seems to be
| shared by many other sources.
| MadcapJake wrote:
| Interesting note: the Sveltekit home page never says
| "full stack" and describes itself as "framework for
| building web applications of all sizes, with a beautiful
| development experience and flexible filesystem-based
| routing". Almost like the SvelteKit folks are aware of
| the potential gotcha from calling it a "full stack"
| frameworks.
|
| That being said, I am in the "this is full stack" camp
| due to prior art in the JS community. RoR/Django and
| their language communities have always been more about
| including all the parts (one could call it a "complete
| stack" style) and the JS community has always been about
| modularity. EmberJS strikes me as the last bastion of
| complete stack framework in JS (curious if there are
| others that are lesser known)
| capableweb wrote:
| > but if you want to make a full-stack web app, you need
| more than Sveltekit.
|
| To create a full-stack web app you need a frontend and a
| backend. That's it. You can build a full-stack web app with
| just NodeJS and HTML files if you so wish (or even write
| HTML templates in your http handlers from the backend).
| Nothing in "full-stack" requires having a validation
| library in order for it to be full-stack, that would more
| be leaning towards the "batteries included" approach to a
| framework instead of strictly being about "full-stack".
|
| When you frame your argument in a way that implies "it's
| not a _real_ framework /tool for _real life_ applications
| unless it has X " is almost exactly how I'd write an
| example of gatekeeping if I had to.
| mirzap wrote:
| No it's not just it. That's small part of it. If you need
| to pull 30 other packages to your backend or frontend,
| then your "full stack framework" is not full stack. Check
| .NET, SpringBoot or even Laravel to some degree to see
| how "full stack" really looks like. It's entire
| ecosystem. You rarely go outside of that. Can you develop
| modern app (with db access, caching, queues, messaging
| etc.) with just SvelteKit or just Next.js (and their
| official packages) as dependency? No, you can't. Not
| without pulling 20 other 3rd party packages. Thus, those
| are not full stack frameworks. They are nice and
| convinient opinionated frameworks, that speed up
| development, but you always relay on other packages to
| complete the stack.
| capableweb wrote:
| Yeah, I guess we have different definitions for them.
| What you're talking about is what I'd call a "batteries-
| included" framework, which exists both as frontend,
| backend and full-stack frameworks. Full-stack just means
| that you can write your frontend and backend with it, not
| the amount of functionality it has within.
| tacker2000 wrote:
| But backend means precisely these things. ORM, DB
| migrations, caching, etc. You need that for a solid
| backend. Of course not everybody needs messaging queues
| for example , but some frameworks support this out of the
| box and/or have years of integration with popular queues
| like rabbitmq to look back onto. Imagine how many
| integration bugs were already solved in that time, which
| this new framework still has to iron out. Time and
| experience mean something.
| capableweb wrote:
| Well, for you, apparently, it does mean those things. But
| for plenty of us, it doesn't. Why would I need an ORM/DB
| migrations if everything lives on disk? Why'd I need
| caching when I already run Varnish in front of the
| backend?
|
| Point being (again), definitions seem to differ, and what
| you call "full stack" is what I call "batteries-included
| framework". Full stack simply means (for me) that it
| gives you a way of building frontend and backend code,
| but implies nothing about what functionality is included
| in either part.
| slantyyz wrote:
| You make it sound like none of these things exist.
| Sveltekit is part of the NodeJS ecosystem, and there are
| mature libraries that do many of those things.
|
| The only thing is that Sveltekit isn't force feeding any
| particular library down your throat. When I moved over
| from Express, I pretty much just continued using the
| libraries I was already using.
|
| If you look at how a lot of people actually use
| Sveltekit, it seems like they're outsourcing a lot of
| things like data storage and authentication to third
| party services. What benefit is provided to those users
| by baking in functions they don't need?
| jf22 wrote:
| >What benefit is provided to those users by baking in
| functions they don't need?
|
| A full-stack experience...
| slantyyz wrote:
| > A full-stack experience...
|
| Which clearly doesn't have the same meaning to all
| people.
| capableweb wrote:
| > Which clearly doesn't have the same meaning to all
| people.
|
| Evidently :)
|
| To maybe be able to consolidate the definition, I created
| a Poll: https://news.ycombinator.com/item?id=29811603
| jf22 wrote:
| Of course it's gatekeeping. You need certain feature to
| be considered a full-stack framework.
|
| There are plenty of examples of full-stack apps out
| there. SveltKit has almost none of the features you need
| to build a full app.
|
| It should be noted in my limited experience I found
| SveltKit to be really great, but it's barely 1.0 yet, let
| alone "full stack".
| timeon wrote:
| That is why the title is not "Sveltekit as full-stack web
| app development"
| pc86 wrote:
| How is "Sveltekit as full-stack web app development"
| meaningfully different from "SvelteKit for Full-Stack Web
| App Development"?
| sigzero wrote:
| It's not in the context of the content of the article.
| fullstackchris wrote:
| I disagree, I think it is a fair argument here. Sure, "full
| stack" as a pure definition would probably only mean at least
| one part display layer, one part backend layer... but in a
| framework sense, it's fair to include all these other
| important capabilities (translation, background jobs, etc.).
| cpfohl wrote:
| I'm not sure the Svelte Kit team considers it fully full
| stack... I've answered people's questions in the discord
| channel and usually suggest a separate API backend project or
| directory and that has never gotten corrected by maintainers.
|
| The idea I usually promote is to use SK to wrap other APIs (in
| your control or otherwise) returning the payloads your UI code
| wants.
|
| All that to say: You're not wrong I think you've identified a
| new category of tool, the full stack UI, perhaps?
| duxup wrote:
| If it is front to back, that's full stack as far as I'm
| concerned.
|
| Everything else is a question of what else is involved, but
| that's always what you want to know anyway right? Layers and
| complexity are a whole other topic IMO.
| mgkimsal wrote:
| And someone with 3 years of experience is labelled "senior
| developer".
|
| I agree with your sentiment. I've run in to more than a few
| people who self-identify as "full stack" developers who do not
| understand what a database is, nor have ever set one up. Half-
| joking, but I think they're meaning because they do both
| javascript _and_ css.
| [deleted]
| davedx wrote:
| Yes, I was pulled in by this being a "full stack" technology
| and half-read, half-skimmed the article looking for how the
| back-end parts work. I came away with the impression that
| sveltekit provides some kind of thin layer on top of express to
| do things like server-side rendering, so still very view-level
| focused.
|
| I have the same issue with all these fancy "JAM-stack-ish"
| technologies like next, nuxt, vercel, etc, etc, etc. They are
| constantly iterating on the front end and its associated DX,
| which overall is a net good I think, but almost completely
| ignoring the back-end concerns.
|
| Contrast with, say, meteor. Meteor came out in what, 2014 or
| something? And gave you a genuine full-stack development
| experience. There's not really been anything like it ever
| since. Weird.
| nefitty wrote:
| I just want to take a second to share that Next.js is the
| worst thing I've ever used in my life. I am a react dev. They
| somehow managed to make Next.js harder for me to use than
| Django, which is in Python, which I've barely ever touched!
|
| Imagine that react is like an airplane dashboard. Next.js is
| like adding a faceplate to the dashboard, jumbling up the
| buttons, then hiding some buttons because "best practice" and
| "optimization".
| ylyn wrote:
| Next.js is an opinionated React framework.
|
| If you don't agree with the choices it makes, don't use it.
| nefitty wrote:
| It's an amalgamation of opinions, yeah, and they somehow
| all result in slightly worse and worse dx.
| true_religion wrote:
| Like what for example?
| nefitty wrote:
| Whitelists for network requests. Config files. Favoring a
| server even for a simple SPA. Hidden documentation pages:
| "Theres some stuff that no one ever uses but I guess
| click here if you want to see it."
| kirso wrote:
| There must be a reason though why a lot of companies are
| actually using this stack these days with SPAs and it seems
| like front-end is kind of merging with back-end by using the
| server-side rendering and server-less DBs with Prisma for
| instance?
|
| Its actually just interesting to observe.
|
| I am a complete newbie but curious what are the seniors here
| think about this trend overall.
|
| Meteor had to be sold in the end since they didn't get the
| adoption. But the "JAM-stack-ish" frameworks do get that
| adoption recently at least based on the funding rounds (kind
| of half serious here).
| dham wrote:
| I just take that as a difference in the times. Meteor was
| from another era in development. We mainly did server side
| stuff and used backbone, knockout etc to do more complex
| interactions. Or just used javascript/jquery. Why would I
| use Meteor when I had Rails, Django, etc that was much more
| mature. It's different now because developers like more
| pain these days.
|
| A lot of developers say that it's because the customer
| demands more, the interactions need to be better. None of
| that is the case in reality. The customer doesn't really
| care and at the end of the day most of these frontend
| framework users produce a worse experience unfortunately.
| High CPU, uncaught errors, poor messages, optimistic update
| bugginess, etc.
| danjac wrote:
| IIRC Meteor also shot itself in the foot by using MongoDB
| as the default storage, at a time when there was deep
| (deserved) scepticism about the reliability of MongoDB.
| lovasoa wrote:
| > sveltekit provides some kind of thin layer on top of
| express
|
| It doesn't use express, but something named polka [1], which
| is much less mature. Bugs in polka have caused downtime and
| remote DOS vulnerabilities in my sveltekit app multiple
| times.
|
| [1] https://github.com/lukeed/polka
| andrew_ wrote:
| _lukeed_ has several extremely popular npm packages /libs
| which share a lot in common:
|
| - their twitter following is used to boost newly released
| packages
|
| - they were released as alternatives to existing
| packages/libs with the flashy promise of being smaller,
| less complicated, faster
|
| - negative feedback is rebuffed as "an attack"
|
| - they're all very green
|
| - they lack features and stability of the more mature
| packages they aim to supplant
|
| - once released and popular, they cease getting frequent
| updates
|
| Now, yes this is a generalization. It doesn't apply to all
| of their packages, and not at the same point in time. But
| there is a pattern there. Some quick diving into the
| author's Github account, and their more popular repos shows
| the pattern. It's also clear that this was a choice made by
| a Svelte contributor to use their own package for
| "official" support in Svelte Kit.
|
| When it comes to polka itself, I just don't get why a
| maturing framework like Svelte would choose something whose
| only real advantage lies in micro-benchmarking porn [1].
| Speculation aside, I'm surprised the Svelte team didn't
| look at that choice through a lens of higher scrutiny. Koa
| would have been an infinitely better choice in my personal
| opinion, and there are several community-driven setups
| [2][3] for it.
|
| [1] https://github.com/lukeed/polka#benchmarks
|
| [2] https://github.com/kaladivo/svelte-kit-koa-boilerplate
|
| [3] https://blog.logrocket.com/sapper-svelte-tutorial-2021/
| zffr wrote:
| Well actually SvelteKit has a concept of "adapters" which
| can bundle your app for different targets (ex: netlify,
| vercel, or node). If you target running your app on a node
| server, polka might be the default but it is trivial to
| replace with express
| andrew_ wrote:
| The issue lies more with the fact that _most_ users will
| use what 's shipped as default. You see that habit in
| every large framework out there. And that's why it's
| important to ship reliable, stable defaults.
| slantyyz wrote:
| If the Svelte subreddit is any indicator, a lot of
| Sveltekit devs don't use the Sveltekit back end. Most
| like to use serverless and 3rd party services for things
| like authentication and data storage.
| lovasoa wrote:
| No, the "node" adapter only allows using polka. Unless
| you develop your own adapter, you are stuck with it.
| zffr wrote:
| Check out the docs: https://github.com/sveltejs/kit/tree/
| master/packages/adapter...
|
| They even show you how to set up an express server
| lovasoa wrote:
| You are right, I didn't know that it exported a raw
| handler you could use from another server.
| samuelstros wrote:
| I am using SvelteKit in "production" (smallish) for multiple
| projects. Aside from the small ecosystem (where in reality I am
| only really missing a UI lib other than IBM Carbon), Svelte has
| no error boundaries yet. If an error is not caught, the whole app
| crashes with no way to recover, or even show the user to refresh
| the tab. See https://github.com/sveltejs/svelte/issues/1096.
|
| Other than that, Svelte + SvelteKit is awesome. I would not
| choose React or Vue for small(er) projects.
| zapt02 wrote:
| I agree with you error boundaries are a huge omission. You can
| do basic error boundaries using one of these two packages:
|
| * https://github.com/crownframework/svelte-error-boundary *
| https://github.com/denisstasyev/svelte-error-boundary
|
| They only protect from component initialization errors but it's
| better than nothing. I think Svelte v4 will have more coherent
| error handling.
| coretx wrote:
| Stop feeding the "full stack" trolls
| powerlogic31 wrote:
| jraph wrote:
| > Additionally, vite-plugin-svelte pulls in esbuild, "an
| extremely fast JavaScript bundler" written in go, as a
| dependency. I couldn't find exactly where it was used in the code
| or what it was doing, but it's what shows up in my terminal tab
| when I run yarn dev so it must be running down there somewhere.
|
| And then:
|
| > Even after a good bit of docs searching and code diving, I
| really couldn't figure out what library was actually performing
| that transpilation or how to configure it.
|
| I smiled reading that and then this. Here you go, it's esbuild,
| which replaces babel. :-)
|
| It was nice to follow the exploration while reading this article.
| As someone who is a future-ex React developer who uses Svelte in
| a personal project, I fully agree with the author on how Svelte
| feels.
| Zababa wrote:
| > SvelteKit is still in beta, and hasn't reached its big 1.0
| milestone yet. It is the successor to Sapper, which isn't
| extremely popular itself with ~25k monthly downloads on
| StackOverflow and never hit 1.0 itself.
|
| I've used Svelte a lot for personal projects, but this quote
| right here is why I'm still waiting to use it in more
| professional contexts. I like that they are not rushing an
| incomplete 1.0, but I'm not sure about using beta software in
| production.
| wccrawford wrote:
| >I'm not sure about using beta software in production.
|
| It used to be unthinkable that you'd use beta software in
| production. I think that change says a lot about the state of
| things, and why people are always complaining about framework
| churn in the industry.
| Zababa wrote:
| > I think that change says a lot about the state of things
|
| I don't think it does. It could mean that people ship broken
| things all the time, or that beta software is way more stable
| than it used to be, or that deploying things is cheap, or
| that people really need new features
|
| > why people are always complaining about framework churn in
| the industry.
|
| Because they are parroting opinions based on a reality that
| doesn't exist anymore. For frontend frameworks, the state
| hasn't changed in the last 5 years at least. React is
| dominant, Angular is used by legacy/more conservative people.
| That's already most of the market. Add Vue in the mix
| (usually for smaller shops) and you're basically done. Svelte
| is still very small, SvelteKit even more. The situation is
| the same with backend. Java? Spring. Python? Django, Flask.
| Ruby? Rails. PHP? Laravel, Symfony. JS? Express.
|
| People are complaining about churn because they're exposed to
| the bleeding edge of what's made. A lot of it will not stick
| and be forgotten. We're on a website called "Hacker News".
| The "News" means that it will be biased for new and shiny
| things. You want to do compile-time DI in Java and deploy it
| on k8s? That's bleeding edge, there are choices to make, and
| they're not obvious. In a few years the choice will probably
| be as obvious as Spring is today as these things become more
| and more popular. But not for now. Right now you're trying to
| predict the future, which is very hard. Especially since at
| the same time you're running a business, writing code,
| solving problems.
| canyonero wrote:
| Long time React and Angular dev here. I've tried Svelte a few
| times now, hoping it feels better and something clicks with me
| each time I try it. But, I just don't get it and give up every
| time. I end up spending more time trying to understand the design
| decisions and patterns of the framework, and discovering Svelte
| packages that aren't abandoned/outdated instead of building
| anything cool or useful. There is nothing you can't accomplish
| with React or Vue based frameworks IMO, so it then comes down to
| taste/preferences/goals.
|
| I do think building a meta-framework is the right call for
| adoption, though. The only way to survive and thrive in the
| frontend-framework landscape in 2022 is to provide first class
| support for batteries-included full-stack offerings. The
| community seems to be in a return to server-side rendering
| approaches and client-only SPA is moving out of fashion.
| rk06 wrote:
| > This is a pretty tall stack compared to what I'm used to of
| just running webpack build or similar, and I'd never used any of
| its components before this.
|
| really? I remember webpack and co bringing 200mbs in node
| modules. while vite and esbuild bring around 40mb.
|
| > Even after a good bit of docs searching and code diving, I
| really couldn't figure out what library was actually performing
| that transpilation or how to configure it.
|
| Esbuild is doing it.
___________________________________________________________________
(page generated 2022-01-05 23:02 UTC)