241–250 of 296 posts
Is Svelte eating Vue's lunch but not really eating React's?
Svelte is getting traction for sure. Arguably, it is easier for a vue dev to transition to svelte than a react dev, because of heavy similarities in vue and svelte.
However, react has more people. And most of newer devs are on react for job purposes. So svelte will get disproportionately higher react devs than vue devs.
Earlier quoted context omitted.
Same, but with ASP.NET (which produces an OpenAPI specification) + Entity Framework on the server, React + TypeScript on the client (which consume that specification through openapi-generator). https://github.com/OpenAPITools/openapi-generator I chuckle every time I read claims about Go (or whatever) being amazingly productive. I don't think it's possible to beat this stack with regards to both productivity and ease…
I agree with the sentiment--and with most of your comment--except the assertion that "I don't think it's possible to beat this stack". I have something similar: Kotlin on the server-side with my SQL DSL generated by jOOQ and Flyway running my schema migrations. I don't have any experience with LINQ--but it looks to be of a similar idea to jOOQ such that you get an autogenerated, injection-safe, type-safe, compile-tim…
I’ve recently been migrating projects from jOOQ to SQLDelight. While not as feature complete, being able to write queries in sql and then generate type safe code has been amazing. My biggest issue with jOOQ has been joins where you lose some null safety and general issues with the generated POJO (which admittedly has improved over time). With SQLDelight, it has felt like the database just fades away when writing Kotlin.
Earlier quoted context omitted.
I'm not the person you ask, but we use fullstack Typescript in our dev department. We're a weird mix of a green energy company and an investment bank, so inhouse development is very small-scale, and this means you share resources. Using one language for everything helps with this, since the one person who is really good at React can take a vacation or a sickday without being glued to a laptop since everyone else can…
> I'm not the person you ask, but we use fullstack Typescript in our dev department. We're a weird mix of a green energy company and an investment bank, so inhouse development is very small-scale, and this means you share resources. Using one language for everything helps with this, since the one person who is really good at React can take a vacation or a sickday without being glued to a laptop since everyone else ca…
I've wondered about this approach for a while, but have yet to actually try it in any meaningful context. Do you use a framework like React via Scala.js, or are you doing something different?
Earlier quoted context omitted.
If it's for your career: React + (Next or Remix). Maybe Angular or Vue if the specific company you want uses it If it's for yourself: Svelte. Amazing community, very likely to be here in 5 years, but I don't think it's been proven to work at large scales yet. If you want to twist everything upside down and see the full potential of what front-end dev work could be: Qwik or Elm (imho)
Elm hasnt had the momentum for years, its gonna be a long shot for it to go anywhere from here > but I don't think it's been proven to work at large scales i basically have this saved now: notable companies now using svelte not just for internal apps but customer facing, critical stuff: - huggingface (for everything, including gradio) - alaska airlines (entire customer flow) - razorpay (payment dialogs) - schneider e…
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…
Earlier quoted context omitted.
> I'm not the person you ask, but we use fullstack Typescript in our dev department. We're a weird mix of a green energy company and an investment bank, so inhouse development is very small-scale, and this means you share resources. Using one language for everything helps with this, since the one person who is really good at React can take a vacation or a sickday without being glued to a laptop since everyone else ca…
> We do this the other way around, by using Scala.js so we can use Scala on the frontend as well as the backend. I've wondered about this approach for a while, but have yet to actually try it in any meaningful context. Do you use a framework like React via Scala.js, or are you doing something different?
Earlier quoted context omitted.
Same, but with ASP.NET (which produces an OpenAPI specification) + Entity Framework on the server, React + TypeScript on the client (which consume that specification through openapi-generator). https://github.com/OpenAPITools/openapi-generator I chuckle every time I read claims about Go (or whatever) being amazingly productive. I don't think it's possible to beat this stack with regards to both productivity and ease…
> I chuckle every time I read claims about Go (or whatever) being amazingly productive. I don't think it's possible to beat this stack with regards to both productivity and ease of long-term support It's easy to beat Open API, it adds friction, generates ugly code and has a suboptimal UI. If you use https://servicestack.net you don't to rely on an intermediary external tool, you can generate clean TypeScript DTOs dir…
To everybody else reading this - mythz' tone deaf bullshit wasn't my favourite way to be reminded I have a gag reflex but the URLs are well worth a look.
Earlier quoted context omitted.
Except it forces you to use node js, or do I read it wrong? Can we get a streamlined js framework that is just about the frontend and let’s you use whatever backend language you want? I know there is react, vue and angular but they seem so bloated
We are using SvelteKit frontend with Python backend (Pyramid + SQLAlchemy). When I started the project, I considered doing Python backend + templated HTML frontend a la Django, but SvelteKit server-side rendering was so good that I decided against this. Before I have done JSP, PHP, Django, Next, React and everything between, so I have some experience to compare. Despite all progress on Node.js backends, they still ca…
Earlier quoted context omitted.
and before angular was jquery. But I do think there's quite a big difference between React and Angular. Angular never reached the level of marketshare that React has even if it was close. And even when it was close it was only for a few years. React has been the standard for nearly a decade now. And React has been much more explicit about growing its ecosystem whereas Angular has much fewer 3rd party plugins/tools. I…
I'm surprised that 5% of developers have used svelte. That seems like a lot, I was under the impression that webdevs are not the majority of software developers.
In 2019: React.js 31.3%, Angular/Angular.js 30.7%, Vue.js 15.2%
I'm sure those number skew towards a certain kind of dev. Hopefully this gives you a better idea of how skewed it is. Also note: it's an online survey. Devs of niche frameworks can and often do encourage people to rate their framework higher