I like the fact minimalist approaches, like svelte, htmx and alpine.js are getting more and more traction.
I felt like fighting this fight alone for years in the golden years of node, webpack and react where everybody was creating crazy stacks and adding GraphQL and so on, to basically get what Django + jquery did 10 years ago in a tenth of the time and code.
So far I also survived:
- xml is the future
- let's use nosql for all the things
- you must use the same language at the back and front
- yes, you site must have an AMP version (ah, you forgot this one, didn't you? It was sooo imporant, and then pouf, it was gone like tear in the rain)
- yes, your home page must be an SPA
- you can't code anything without async
- you can't live without a message queue
- everything must become a micro service
- of course you need a container for that
- of course you need a orchestrator to organize those containers
- of course you need the cloud, it would be crazy to deal with those containers and orchestrators yourself
- dude, why do you have a server? Use a serveless backend!
- dude, why do you have a backend? Just call saas from the edge!
Every year, some generation of engineers have to learn the concepts of "there is no silver bullet", "use the right tech for the right problem", "your are not google", "rewriting a codebase every 2 years is not a good business decision", "things cost money".
It's the second, younger generation of devs who are realizing that "complexity kills". Those of us who started in 2000's have already seen this. It's a natural cycle. We are seeing a spring-back to monoliths and away from micro-services and crazy tooling chains.
It was completely unnecessary, and most importantly, cost the industry a fortune. If you are older, you have been wondering why you need to work more to achieve less. To me this has been demoralizing, and actually put me through some tough cycles of depression. I no longer enjoy this job. I used to DO things and walk away from my desk every day having a sense of achievement. Now it takes 3 days to set up your microservices locally just to reproduce a bug, apparently because your system with moderate traffic needs to look like Shopify.
There's a HN world of what's gaining traction and what "everybody" is using, and the real world reality. If I search for Django jobs on indeed, I get way more results for Django than if I search for Svelte (183:11). If I ctrl+f on "Who is Hiring?", the ratio gets a lot closer (13:4).
> Every year, some generation of engineers have to learn the concepts of "there is no silver bullet", "use the right tech for the right problem", "your are not google", "rewriting a codebase every 2 years is not a good business decision", "things cost money".
Ah, yes, the wheel of time. I've been through all of the things you've listed and more. My first job programming was in 1996 and involved HTML/JS/CSS and SQL. JS came out in 1995. CSS in 1996.
First it was cgi-bin, ASP, then ASP.Net and ASP.Net MVC, now I work with SPAs. When I hear the term "SSR" it instantly throws me back 20 years, when everything was server-side rendered.
As you mentioned, it's the same with things like SQL. When JavaScript exploded, we got NoSql, because it's easy to toss JSON into a KV store. Then a few years later, you see many more posts about people discovering how powerful relational SQL is, or awesome SQLite is, etc. It's the next generation realizing that things may have been done a particular way for a reason.
On the front-end, I work with enterprise Angular now. I have no desire to move on to the next shiny object/framework, because if it's bleeding-edge, that means the community is small. And if it doesn't explode in popularity, that community will disappear and you'll be left with an application running on something nobody knows. I try to keep pace with Angular's 6 month cadance and so far, so good. My current project has gone from 13-16 without any issues.
And don't get me started on microservices. Get off my lawn.
One of the exact reasons I've been working with Aurelia as my Javascript framework of choice since 2015. Aurelia 1 has served me well and I have apps that have been in production for eight years untouched. They just keep running without fail and they're so simple. Similarly, Aurelia 2 (currently in beta) is even better and as stable (same templating syntax, DI, etc). I tend to avoid all of the hype in the front-end space. The only thing clients and companies care about at the end of the day are results.
- Simple syntax
- Convention over configuration, but gives you the ability to configure it when you need too
- Standards compliance
- Has state management, routing, validation, Fetch client and translation packages
- Completely written in TypeScript, so everything is strongly typed
- Great docs
- HTML templating syntax is standards compliant, so everything looks similar to native HTML. None of this weird curly, banana in a box, square bracket and weird symbol nonsense that is not intuitive.
People always ask, "Why not React?", "Why not Vue?", "Why not Svelte?", etc. People think you need to use the most popular option like it's a popularity contest. I find it laughable to build a React application in 2023 you don't just `npm install react`, people tell you to use something like Next.js which is a framework built on React (the very thing developers tried arguing for years you didn't need to build apps and that libraries were enough). I can guarantee that most of the people in this comments section either tried Aurelia years ago when it was v1 or have never heard of it. Then you would have some that won't use it because it's not big or popular enough.
I can build an app using Aurelia faster than most developers could using React or any other convoluted framework or library. Even Vue used to be nice and basic, before Vue 3 where they decided they would become React Lite and introduce complexity in the way you build things because everyone bought into the myth everything has to be functions and classes are bad.
At the end of the day the safest strategy is to use what works for you and ignore everything else.
This reflects my experience from the 00's onwards. Survived and avoided most of these—except the nosql bandwagon. A worn out and wiser man, ended up switching back to relational DBs several years later.
I never built a web app in my life. I have always been on the server side.
Recently I spent a couple days building the same web app in Next, Nuxt, and SvelteKit just to get a feel of how to build a web app today. The web app was pretty basic. A couple of pages showing data from different apis and auth with user setting page.
My favorite by far was SvelteKit despite being the one with the smaller community. It was actually enjoyable compared to the others. It was very easy to feel like I was actually building something. You feel productive right away. The app automatically felt well organized with how the file layout was. Everything belong in a specific place. Layout goes here, Server stuff goes there, pages go here. Even form processing with nice. Building components was like building components in regular JS.
Next was my least favorite mostly due to the syntax and how you had to build the application. I really didn't like the whole style of Next and React. Just felt dirty.
I would highly suggest people to try SvelteKit. The file names might be a bit weird but it will teach you to use file finder in your IDE.
Ease of building from scratch and long term maintainability are different concerns and maintainability can require higher complexity at first.
Eg. I would say involving TypeScript 100% loses at ease of building something simple quickly but with some experience I would not start a significant project without it anymore.
Just curious why you preferred SvelteKit to Nuxt? Literally every single thing you said of SvelteKit is also true of Nuxt.
I like them both, but tend to lean more toward Nuxt for the modules ecosystem and layers/extends. I also find composing reusable props with typescript to be nicer in Nuxt, but that's more of a Vue vs Svelte thing than Nuxt vs SvelteKit.
> by wrapping a vanilla lib to a component or an action, you’ve essentially created basic Svelte version of that lib
This is the key to making framework churn go away. The DX of using vanilla JavaScript is getting better every day. And is a much better experience than it was a decade ago.
> Islands architecture and partial hydration can help you render static HTML with just a small portion of JavaScript for those components who need it
I'm doing this with Hugo for rendering the static parts, and htmx for loading hydrated partials. The HATEOAS approach simplifies state management in the application. There is no client side "routing", just links and the back button.
In addition to vanilla libs, I include one "app.js" bundle. This file is created with esbuild and linted with deno. My "business logic" can be written in TypeScript in VSCode with the Deno extension and LSP server.
I've moved my little hobby website to SvelteKit[1] from react and I am not regretting it.. yet.
The only main frustrations I have are:
- Library support is pretty lousy. You need to fudge things around to get working. I.e, with leaflet and others I have vendored in the libs and redone them.
- Incremental static refresh with svelte kit is not really there. I'd like a web hook or api callback that allows me to refresh certain static pages as I know that changes are made. Right now I'm doing a janky refresh using a file lock notifier & it's a blemish on an otherwise great framework.
- The URL routing in svelte kit is... a little ugly. It's really hard when you have an editor open with 5 `+page.svelte` files. I wish they re-introduced file name routes, rather than folder name routes. It is entirely a personal preference I know, but I have seen a lot of negative things around it.
Haven't had that refresh issue because I don't use that.
But I'm 100% with you on the routing. It's weird. One thing I had a lot of trouble was with "sub routing", like being in a route, opening a modal and having the url change so it can be linked to.
I had to implement some ugly workaround in the layout to catch hasthag # navigation.
We have recently moved our website[1] to SvelteKit. Previously we were on Sapper. Previous to that we used a custom Webpack + React setup to output a static site.
Our desktop app builder is also built on Svelte (not SvelteKit).
I agree with pretty much everything in this article. I wouldn't put "Reactive declarations and statements" in the "Ugly" section though. They are definitely a bit tougher to fully grok than the rest of Svelte (Svelte is incredibly easy to learn compared to other frameworks) but once you learn how they work they are incredibly powerful and concise.
I also feel like "Svelte’s lack of protagonism" is a bit off the mark. Rich Harris is a great communicator and tends to be pretty public but the focus is more on community. Svelte Society's Youtube channel [2] does a 1 hour long "This week in Svelte" video every week and it is all killer content with no filler.
> After several meetings, we came to the conclusion that the best approach was to simply halt the old website development and build a new one from scratch using the best technologies and practices.
Spoken like a true developer. Trash the old system, reinvent the wheel, prioritize the delight of the devs, leave the client with something that is totally obsolete and nobody else knows how to work on in a couple of years.
If that's not contract development in a nutshell I don't know what is.
They mention that the legacy system was scaled vertically and expensive. Sometimes a complete re-write makes sense.
Some companies spend hundreds of thousands of dollars a year for terrible CMS websites. I've seen this situation 3 times in my career and for all three a re-write was the best long term option when balancing all the pros and cons.
I have used both SvelteKit and React. Dev velocity was great in the beginning with SvelteKit when everything was super simple but decreased drastically as the project grew. Went back to Next. Apart from devs, none really cares if you wrote it in Svelte, React or bare HTML/CSS or if your site loads double digit milliseconds slower.
- most of the icons on the footer are just unicode emojis, no separate library just for icons....nice!
Only feedback I have:
- the sticky footer looks like what you would see in a mobile view and looks a little odd in desktop (I am not on a phone atm)
- Home page drop down in top left and some footer items are redundant, I would nix one (if I had to choose, nix the footer links, keep drop down)
- Super minor, but for the nav drop downs, implement animation for the up/down arrow icons to indicate open state
Overall, very clean. I'm going to follow your twitter and steal the styles from your html to apply to my own projects (bc I am bad at design, so thank you).
As the author states, ... Svelte Stores are rough. Beyond just missing usage patterns and documentation, we found that several features are lacking, especially when used with native reactivity (`$:`). Another area lacking is TypeScript support.
Our frontend codebase at OKcontract is implemented with Svelte, but we had to build some low-level libraries (including a wholly new implementation of Stores) to make it worthwhile. We're very busy with our main launch now, but plan to open source these libs asap.
> Reactive declarations and statements are useful features, just remember not to abuse them, otherwise you may end up switching Svelte’s productivity by headaches and infinite debug sessions
I wish they got into more of that; I've heard of stories but I've never run into this after several years of building Svelte projects, so I'd love to learn so I don't make those mistakes myself
> Svelte’s lack of protagonism
This doesn't look like it reflects on the system itself? I'd rather have something that works well and doesn't focus on flashy-ness. I guess the real downside is that there are such few plugins / tools for Svelte compared to React, but with Rich Harris working with Vercel on Svelte, I can only see things go up from here — like Vercel AI having out of the box Svelte support.
This is the vaguest argument against react I’ve heard. Not the basis for any rational decision making:
>>> But once you leave this path you may (and more likely will) get into trouble at some point. And sometimes there are projects where you don’t want (or can’t) risk getting in trouble because of the tool you’ve chosen for your UI development. There simply isn’t any room for that.
as someone close to the Svelte community, i think the "lack of protagonism" comment is due to the relatively loud voices of those mentioned names.
however the activity in svelte genuinely has picked up year to year. you can follow Svelte Society on Twitter and YouTube to see the many projects going on, in particular https://twitter.com/SvelteSociety/lists for people building and teaching and evangelising Svelte. they're out there! just necessarily smaller because they got started later + have less funding from Facebook.
> Reactive declarations and statements feel like powerful magic, and they are, but it’s very easy to hurt yourself by writing code that is almost impossible to debug,
That's interesting, because one thing I'd discovered in Svelte, which I didn't even dream of seeing ever again was a legible stack trace. It literally goes all the way down to the very change that caused all the mayhem.
> Svelte’s lack of protagonism
I see this as a good thing. My main gripe with React isn't even its design(which I also dislike, but acknowledge the fact that the market decided on a solution), but the social aspect of being a React developer. You have to accept everything Dan Abramov says as gospel, or else you'll be ostracized.
The frontend space would use less celebrities and more focused problem solving.
I remember when hooks came out - everyone jumped on the bandwagon and started rewriting normal, working components to this new paradigm. Net effect of course was unpredictable performance, because hooks are only simple on the surface.
I really appreciated this article. No framework is perfect. Svelte always looked like the right approach for a modern component framework, but modern Vue borrowed a lot of its better ideas and ran with it.
Tangential but is anybody doing SSR using Django or any non-js framework? What is your setup? Wish Django had a library that allows `return SSRResponse(bundlename, context=['foo', 'bar'])`.
[+] [-] sametmax|2 years ago|reply
I felt like fighting this fight alone for years in the golden years of node, webpack and react where everybody was creating crazy stacks and adding GraphQL and so on, to basically get what Django + jquery did 10 years ago in a tenth of the time and code.
So far I also survived:
- xml is the future
- let's use nosql for all the things
- you must use the same language at the back and front
- yes, you site must have an AMP version (ah, you forgot this one, didn't you? It was sooo imporant, and then pouf, it was gone like tear in the rain)
- yes, your home page must be an SPA
- you can't code anything without async
- you can't live without a message queue
- everything must become a micro service
- of course you need a container for that
- of course you need a orchestrator to organize those containers
- of course you need the cloud, it would be crazy to deal with those containers and orchestrators yourself
- dude, why do you have a server? Use a serveless backend!
- dude, why do you have a backend? Just call saas from the edge!
Every year, some generation of engineers have to learn the concepts of "there is no silver bullet", "use the right tech for the right problem", "your are not google", "rewriting a codebase every 2 years is not a good business decision", "things cost money".
[+] [-] papito|2 years ago|reply
It was completely unnecessary, and most importantly, cost the industry a fortune. If you are older, you have been wondering why you need to work more to achieve less. To me this has been demoralizing, and actually put me through some tough cycles of depression. I no longer enjoy this job. I used to DO things and walk away from my desk every day having a sense of achievement. Now it takes 3 days to set up your microservices locally just to reproduce a bug, apparently because your system with moderate traffic needs to look like Shopify.
Bad example - Shopify is a monolith.
[+] [-] jonatron|2 years ago|reply
[+] [-] EMM_386|2 years ago|reply
Ah, yes, the wheel of time. I've been through all of the things you've listed and more. My first job programming was in 1996 and involved HTML/JS/CSS and SQL. JS came out in 1995. CSS in 1996.
First it was cgi-bin, ASP, then ASP.Net and ASP.Net MVC, now I work with SPAs. When I hear the term "SSR" it instantly throws me back 20 years, when everything was server-side rendered.
As you mentioned, it's the same with things like SQL. When JavaScript exploded, we got NoSql, because it's easy to toss JSON into a KV store. Then a few years later, you see many more posts about people discovering how powerful relational SQL is, or awesome SQLite is, etc. It's the next generation realizing that things may have been done a particular way for a reason.
On the front-end, I work with enterprise Angular now. I have no desire to move on to the next shiny object/framework, because if it's bleeding-edge, that means the community is small. And if it doesn't explode in popularity, that community will disappear and you'll be left with an application running on something nobody knows. I try to keep pace with Angular's 6 month cadance and so far, so good. My current project has gone from 13-16 without any issues.
And don't get me started on microservices. Get off my lawn.
[+] [-] cageface|2 years ago|reply
[+] [-] DigitalSea|2 years ago|reply
- Simple syntax
- Convention over configuration, but gives you the ability to configure it when you need too
- Standards compliance
- Has state management, routing, validation, Fetch client and translation packages
- Completely written in TypeScript, so everything is strongly typed
- Great docs
- HTML templating syntax is standards compliant, so everything looks similar to native HTML. None of this weird curly, banana in a box, square bracket and weird symbol nonsense that is not intuitive.
People always ask, "Why not React?", "Why not Vue?", "Why not Svelte?", etc. People think you need to use the most popular option like it's a popularity contest. I find it laughable to build a React application in 2023 you don't just `npm install react`, people tell you to use something like Next.js which is a framework built on React (the very thing developers tried arguing for years you didn't need to build apps and that libraries were enough). I can guarantee that most of the people in this comments section either tried Aurelia years ago when it was v1 or have never heard of it. Then you would have some that won't use it because it's not big or popular enough.
I can build an app using Aurelia faster than most developers could using React or any other convoluted framework or library. Even Vue used to be nice and basic, before Vue 3 where they decided they would become React Lite and introduce complexity in the way you build things because everyone bought into the myth everything has to be functions and classes are bad.
At the end of the day the safest strategy is to use what works for you and ignore everything else.
[+] [-] npsomaratna|2 years ago|reply
[+] [-] impulser_|2 years ago|reply
Recently I spent a couple days building the same web app in Next, Nuxt, and SvelteKit just to get a feel of how to build a web app today. The web app was pretty basic. A couple of pages showing data from different apis and auth with user setting page.
My favorite by far was SvelteKit despite being the one with the smaller community. It was actually enjoyable compared to the others. It was very easy to feel like I was actually building something. You feel productive right away. The app automatically felt well organized with how the file layout was. Everything belong in a specific place. Layout goes here, Server stuff goes there, pages go here. Even form processing with nice. Building components was like building components in regular JS.
Next was my least favorite mostly due to the syntax and how you had to build the application. I really didn't like the whole style of Next and React. Just felt dirty.
I would highly suggest people to try SvelteKit. The file names might be a bit weird but it will teach you to use file finder in your IDE.
[+] [-] Graffur|2 years ago|reply
> I would highly suggest people to try SvelteKit.
I feel like this is a good summary of tech trends these days.
[+] [-] throwaway290|2 years ago|reply
Eg. I would say involving TypeScript 100% loses at ease of building something simple quickly but with some experience I would not start a significant project without it anymore.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] barrongineer|2 years ago|reply
I like them both, but tend to lean more toward Nuxt for the modules ecosystem and layers/extends. I also find composing reusable props with typescript to be nicer in Nuxt, but that's more of a Vue vs Svelte thing than Nuxt vs SvelteKit.
[+] [-] draw_down|2 years ago|reply
[deleted]
[+] [-] mozey|2 years ago|reply
This is the key to making framework churn go away. The DX of using vanilla JavaScript is getting better every day. And is a much better experience than it was a decade ago.
> Islands architecture and partial hydration can help you render static HTML with just a small portion of JavaScript for those components who need it
I'm doing this with Hugo for rendering the static parts, and htmx for loading hydrated partials. The HATEOAS approach simplifies state management in the application. There is no client side "routing", just links and the back button.
In addition to vanilla libs, I include one "app.js" bundle. This file is created with esbuild and linted with deno. My "business logic" can be written in TypeScript in VSCode with the Deno extension and LSP server.
[+] [-] cetra3|2 years ago|reply
The only main frustrations I have are:
- Library support is pretty lousy. You need to fudge things around to get working. I.e, with leaflet and others I have vendored in the libs and redone them.
- Incremental static refresh with svelte kit is not really there. I'd like a web hook or api callback that allows me to refresh certain static pages as I know that changes are made. Right now I'm doing a janky refresh using a file lock notifier & it's a blemish on an otherwise great framework.
- The URL routing in svelte kit is... a little ugly. It's really hard when you have an editor open with 5 `+page.svelte` files. I wish they re-introduced file name routes, rather than folder name routes. It is entirely a personal preference I know, but I have seen a lot of negative things around it.
[1] - https://github.com/cetra3/divedb - deployed at https://divedb.net/
[+] [-] renatofontes|2 years ago|reply
But I'm 100% with you on the routing. It's weird. One thing I had a lot of trouble was with "sub routing", like being in a route, opening a modal and having the url change so it can be linked to.
I had to implement some ugly workaround in the layout to catch hasthag # navigation.
[+] [-] gl-prod|2 years ago|reply
[+] [-] onion2k|2 years ago|reply
Next 13's app directory and React Server Components is killing library support in React, so that's not such a big problem.
[+] [-] madacol|2 years ago|reply
+1. I've been pushed to change tabs using `Ctrl+P` instead (search tab command) and write its route (folder's name). But it's still a bit painful
[+] [-] nop_slide|2 years ago|reply
I just looked through your repo. I'm still relatively new to SvelteKit and rewriting a similar content based site from React.
What led you to use the SSG adapter vs the node adapter (which uses SSR)?
How long does the build take to pre-render all of your content pages like the sea life?
Was there a particular reason you didn't want to use Form Actions?
Not criticizing your decisions by the way, I'm mostly just curious about the decisions others make to learn something myself :)
[+] [-] scosman|2 years ago|reply
[+] [-] davej|2 years ago|reply
Our desktop app builder is also built on Svelte (not SvelteKit).
I agree with pretty much everything in this article. I wouldn't put "Reactive declarations and statements" in the "Ugly" section though. They are definitely a bit tougher to fully grok than the rest of Svelte (Svelte is incredibly easy to learn compared to other frameworks) but once you learn how they work they are incredibly powerful and concise.
I also feel like "Svelte’s lack of protagonism" is a bit off the mark. Rich Harris is a great communicator and tends to be pretty public but the focus is more on community. Svelte Society's Youtube channel [2] does a 1 hour long "This week in Svelte" video every week and it is all killer content with no filler.
[1] https://www.todesktop.com [2] https://www.youtube.com/@SvelteSociety/videos
[+] [-] katzgrau|2 years ago|reply
Spoken like a true developer. Trash the old system, reinvent the wheel, prioritize the delight of the devs, leave the client with something that is totally obsolete and nobody else knows how to work on in a couple of years.
If that's not contract development in a nutshell I don't know what is.
[+] [-] bsaul|2 years ago|reply
Maybe i’m dreaming but i’m starting to feel a new « let’s stop with the fashion addict attitude to tech » vibe on HN, which i really really like :)
[+] [-] ozten|2 years ago|reply
Some companies spend hundreds of thousands of dollars a year for terrible CMS websites. I've seen this situation 3 times in my career and for all three a re-write was the best long term option when balancing all the pros and cons.
[+] [-] zygo|2 years ago|reply
[+] [-] chrisjayden|2 years ago|reply
[+] [-] game_the0ry|2 years ago|reply
From inspecting the html:
- sanity for cms
- tailwind for css
- partytown for running script in web worker
- most of the icons on the footer are just unicode emojis, no separate library just for icons....nice!
Only feedback I have:
- the sticky footer looks like what you would see in a mobile view and looks a little odd in desktop (I am not on a phone atm)
- Home page drop down in top left and some footer items are redundant, I would nix one (if I had to choose, nix the footer links, keep drop down)
- Super minor, but for the nav drop downs, implement animation for the up/down arrow icons to indicate open state
Overall, very clean. I'm going to follow your twitter and steal the styles from your html to apply to my own projects (bc I am bad at design, so thank you).
[+] [-] Dowwie|2 years ago|reply
[+] [-] bavell|2 years ago|reply
[+] [-] troxwalt|2 years ago|reply
[+] [-] jwmoz|2 years ago|reply
[+] [-] hbbio|2 years ago|reply
Our frontend codebase at OKcontract is implemented with Svelte, but we had to build some low-level libraries (including a wholly new implementation of Stores) to make it worthwhile. We're very busy with our main launch now, but plan to open source these libs asap.
PS: We're not using SvelteKit
[+] [-] yawnxyz|2 years ago|reply
I wish they got into more of that; I've heard of stories but I've never run into this after several years of building Svelte projects, so I'd love to learn so I don't make those mistakes myself
> Svelte’s lack of protagonism
This doesn't look like it reflects on the system itself? I'd rather have something that works well and doesn't focus on flashy-ness. I guess the real downside is that there are such few plugins / tools for Svelte compared to React, but with Rich Harris working with Vercel on Svelte, I can only see things go up from here — like Vercel AI having out of the box Svelte support.
[+] [-] andrewstuart|2 years ago|reply
>>> But once you leave this path you may (and more likely will) get into trouble at some point. And sometimes there are projects where you don’t want (or can’t) risk getting in trouble because of the tool you’ve chosen for your UI development. There simply isn’t any room for that.
[+] [-] spyke112|2 years ago|reply
[+] [-] coolgoose|2 years ago|reply
[+] [-] wg0|2 years ago|reply
[+] [-] rizky05|2 years ago|reply
[deleted]
[+] [-] swyx|2 years ago|reply
however the activity in svelte genuinely has picked up year to year. you can follow Svelte Society on Twitter and YouTube to see the many projects going on, in particular https://twitter.com/SvelteSociety/lists for people building and teaching and evangelising Svelte. they're out there! just necessarily smaller because they got started later + have less funding from Facebook.
[+] [-] Tade0|2 years ago|reply
That's interesting, because one thing I'd discovered in Svelte, which I didn't even dream of seeing ever again was a legible stack trace. It literally goes all the way down to the very change that caused all the mayhem.
> Svelte’s lack of protagonism
I see this as a good thing. My main gripe with React isn't even its design(which I also dislike, but acknowledge the fact that the market decided on a solution), but the social aspect of being a React developer. You have to accept everything Dan Abramov says as gospel, or else you'll be ostracized.
The frontend space would use less celebrities and more focused problem solving.
I remember when hooks came out - everyone jumped on the bandwagon and started rewriting normal, working components to this new paradigm. Net effect of course was unpredictable performance, because hooks are only simple on the surface.
[+] [-] efields|2 years ago|reply
[+] [-] andrewstuart|2 years ago|reply
I don’t hear any arguments against react here strong enough to justify not choosing VueJS or React.
It’s not in the interests of your client.
[+] [-] abhishekjha|2 years ago|reply
[1]https://claudioholanda.ch/assets/blog/en/0003/1.svg
[+] [-] Arcanum-XIII|2 years ago|reply
[+] [-] swan_escape|2 years ago|reply
[+] [-] topnde|2 years ago|reply
[+] [-] siquick|2 years ago|reply
This sounds like the opposite of a nice DX for anyone but the engineer who wrote the original code.
[+] [-] aitchnyu|2 years ago|reply
[+] [-] thomasfromcdnjs|2 years ago|reply
Would be more interested in how your work flow was managed.