Hacker News Reader

Comment by midrus | Hacker News Reader

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.

View on HN

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.

Some gatekeeping is necessary because soon JS frameworks will have redefined everything making it impossible to converse.

Language does not matter. What matters are frameworks, tools, ecosystem, libraries and developers availability. All langues are good enough and shit at different things.

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.

> 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.

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.

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.

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.

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.

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?

>What benefit is provided to those users by baking in functions they don't need?

A full-stack experience...

> A full-stack experience...

Which clearly doesn't have the same meaning to all people.

> 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

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".

> 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.

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)

That is why the title is not "Sveltekit as full-stack web app development"

How is "Sveltekit as full-stack web app development" meaningfully different from "SvelteKit for Full-Stack Web App Development"?

It's not in the context of the content of the article.

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.

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.

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.

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.

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 :)

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?

"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.

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.

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.

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.).

I don't consider what he said gatekeeping, they were valid questions IMO.

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.

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".

Next.js is an opinionated React framework.

If you don't agree with the choices it makes, don't use it.

It's an amalgamation of opinions, yeah, and they somehow all result in slightly worse and worse dx.

Like what for example?

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."

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).

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.

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.

> 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

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

No, the "node" adapter only allows using polka. Unless you develop your own adapter, you are stuck with it.

Check out the docs: https://github.com/sveltejs/kit/tree/master/packages/adapter...

They even show you how to set up an express server

You are right, I didn't know that it exported a raw handler you could use from another server.

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.

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.

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/

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.

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?

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.

> 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.

Did nobody read he was using rust/rocket and SQlite for the backend?

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...

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.

> 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.

When I go to your link, it just says "coming soon".

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 :)

Because you keep spamming the link that doesn't have what you promised.

Reply on news.ycombinator.com