Thanks! Not sure what to do here. We shouldn't have both posts on the front page. This one has more information; the other ones emphasize the announcement.
I guess we'll merge the threads into the earliest submission (the one you linked to) and change the URL to Rich's own post.
In terms of fun I think there's a lot of value to the traditional server side rendered html.
At least for the first MVP you can basically do away with the whole node stack and focus in on the backend storage, the html template and css first. Essentially the basics. It just seems so much nicer. It also adds a forcing function for minimal Javascript which is definitely a good thing. Migration from server side to a single page app once you have that MVP is pretty copy paste-able too. That html template and css is still valid in an SPA. You'll need an API but hey you already have the server side stuff there ready to go!
This is generally my thought too… it’s not a perfect rule but the less libraries/tooling/etc you have on the front end, the better, at least initially. Server tends to be a more sane and controlled environment, especially if you’re using a “boring” tried and true setup instead of whatever is currently trendy.
I kind of agree, but once you need any JavaScript, you basically need it to pull in the entire modern JS tool chain, so adding server side rendering doesn’t replace complexity, it adds to it.
Having a system that would allow you to build server side rendered HTML that could seamlessly integrate client JavaScript seems like it would be a huge advantage. Not sure if there is anything like that though.
This seems like a giant leap forward for Svelte. I'm excited to see where it leads.
I've been using Svelte for the UI on a cross-platform video editor (with the backend in Rust). Svelte has been a joy to use, especially the Stores and Context for sharing state.
I've also been happy to find that its generated code is pretty readable. On one little performance-tuning side quest, I was profiling to figure out why the app was performing a Layout on every video frame, and I was able to step through the compiled Svelte component code and narrow it down to one of my own functions. I also briefly went down a path of trying to manually set the text content on an element, to see if it'd be faster than letting Svelte do it. Turned out the answer was no, but it was nice to know that level of control is available if I need it some day.
There's another post here that links to the actual announcement by Vercel:
https://news.ycombinator.com/item?id=29189144
Thanks! Not sure what to do here. We shouldn't have both posts on the front page. This one has more information; the other ones emphasize the announcement.
I guess we'll merge the threads into the earliest submission (the one you linked to) and change the URL to Rich's own post.
In terms of fun I think there's a lot of value to the traditional server side rendered html.
At least for the first MVP you can basically do away with the whole node stack and focus in on the backend storage, the html template and css first. Essentially the basics. It just seems so much nicer. It also adds a forcing function for minimal Javascript which is definitely a good thing. Migration from server side to a single page app once you have that MVP is pretty copy paste-able too. That html template and css is still valid in an SPA. You'll need an API but hey you already have the server side stuff there ready to go!
This is generally my thought too… it’s not a perfect rule but the less libraries/tooling/etc you have on the front end, the better, at least initially. Server tends to be a more sane and controlled environment, especially if you’re using a “boring” tried and true setup instead of whatever is currently trendy.
I kind of agree, but once you need any JavaScript, you basically need it to pull in the entire modern JS tool chain, so adding server side rendering doesn’t replace complexity, it adds to it.
Having a system that would allow you to build server side rendered HTML that could seamlessly integrate client JavaScript seems like it would be a huge advantage. Not sure if there is anything like that though.
This seems like a giant leap forward for Svelte. I'm excited to see where it leads.
I've been using Svelte for the UI on a cross-platform video editor (with the backend in Rust). Svelte has been a joy to use, especially the Stores and Context for sharing state.
I've also been happy to find that its generated code is pretty readable. On one little performance-tuning side quest, I was profiling to figure out why the app was performing a Layout on every video frame, and I was able to step through the compiled Svelte component code and narrow it down to one of my own functions. I also briefly went down a path of trying to manually set the text content on an element, to see if it'd be faster than letting Svelte do it. Turned out the answer was no, but it was nice to know that level of control is available if I need it some day.
that is what Elm people had been saying for years :)