Hacker News Reader

Comment by mritchie712 | Hacker News Reader

It's a case of "Nobody ever got fired for choosing X"[0]. No one would blame you for choosing React for a major project / new startup, but someone could definitely poke holes in choosing Svelte ("theres no package for X", "it doesn't scale", "we can't find devs that know it", etc.)

0 - https://www.quora.com/What-does-the-phrase-Nobody-ever-got-f...

View on HN

Absolutely. I tried to push us to try Svelte at my last job at BigCo for over four years, to replace an internal templating system. We didn't even use React or Node yet, so not only we had to convince the old guard to adopt something new, but also deal with the React-grown crowd protesting.

You can't imagine the amount of flak I've taken for that. Managed to get it on a back-of-the-house system, while we built a massively complex React app for the main product. Everyone who worked on it loved it, but was still considered risky. Now that it has a gazillion GH stars and is mentioned in 1 out of 3 blog posts, of course things are much easier.

Man, on one hand... evaluating frameworks is just part of the job, right? Same as evaluating a vendor service, or a third-party package, or an architecture or a pattern...

On the other hand, novelty burnout is a real thing. Javascript has mutated so much in a short period of time that it's become impossible to keep up with -- especially once you factor in frameworks and tooling.

Times like this, I wish vanilla JS/ECMAscript was more powerful out of the box. For a language designed to work with the HTML DOM -- the ONLY language that works natively with it -- it is so woefully underpowered. Why do we need a framework at all to do a simple stateful AJAX UI? =/

For many sites and apps, the business logic SHOULD be the focus of dev time, but it's not... it's implementing trivial business logic inside of the ever-growing monster that is the JS ecosystem. There are 1000 ways to do anything in JS, but never just one good way.

And if you haven't been hyper-focused on learning every bit of "modern JavaScript" in the last 5 years, employers definitely love to disqualify you just because you were happily working on "legacy tech" instead of catching up on React and every other JavaScript-heavy approach to Web development.

I'm bitter, and I'm not opposed to moving on and learning this stuff, but it's like employers barely understand the value of HTML/CSS relative to how much React is prioritized/used as a single qualifier.

I have "1-2 years experience" with React & friends if that matters, and I consider myself a 10 year Web development vet.

Four years ago? When Svelte was still in it's infancy? You're absolutely right to have received pushback for that. I would still consider Svelte somewhat risky today.

You're lucky that Svelte has taken off but it could have easily been abandoned and you could be stuck with an outdated framework.

Three years ago, someone at my company made the bad call to use Aurelia. It didn't take off, and we are still stuck with this decision.

I'm not claiming that the success is random - Svelte is clearly a far better framework than Aurelia. But the weaknesses often become apparent only later into development, and so it's safer to bet on established approaches.

Depends on your perspective. Svelte first came out in 2016, and by that time I'd been following Ractive.js, the author's previous framework at The Guardian, for years already.

Aurelia is maintained though, as opposed to being completely dead at least.

However I imagine there isn't alot of community libraries to leverage with such a small ecosystem.

Nope, dude at my job totally got "laid off" for choosing to write a feature in an ecommerce system in React. He had used it before at a previous job and was familiar with it. Problem was:

- No one else in the team was familiar with React.

- React did not play nice with the rest of the app and developer work flow.

- It was huge and slow

- He didn't know React as well as he thought he did and we had endless bugs.

- He spent ages working on it.

We rewrote in vanilla JS in 4 days - one dev.

And, yeah, effing JS.

They didn’t literally mean getting fired for choosing a framework choice and it doesn’t sound like your story does either.

The point is about making safe choices compared to alternatives. Migrating a project without full team buy in and without testing the waters in small incremental experiments is a developer/management problem.

Everyone gets miscorrected for using either a heuristic or an analogy.

This should never happen, the developers should not choose whatever technology stack or components they want for their piece of code, that's how Frankenstein started. But getting fired is reasonable in this case.

Agreed, but there must be more to this story that resulted in firing. You can't easily fire people for the issues listed here, at least in most civilized parts of the world.

I wish. West Coast of USA can fire you for a bad haircut.

Yeah, that's a little bit of the story that I left out - he also chose React without the normal team consensus on tech, so there was that, too.

But, but ... resume driven development!

He didn't get fired for choosing React though, he got fired for not being a good developer. If the task was so small you could write it in 4 days it should be easy for any competent developer to write a fast small React version.

I always find React/Vue comparisons with vanilla JS so curious, as if there's feature parity. No one would say "I rewrote this Flask REST API in vanilla Python".

As for the "can't find devs that know it" problem, I'd suggest anyone reading this that Svelte is incredibly easy to pick up. Like I skimmed the docs in literally a few minutes, and was able to build out a reasonably sophisticated application almost immediately.

I lost a non-trivial amount of time converting a vuejs app to svelte before getting blindsided by svelte not having basic error handling: https://github.com/sveltejs/svelte/issues/1096

Many types of errors that the equivalent vuejs/react app will show an error page and allow reporting to sentry for will result in an uncatchable halting (some may describe this as "freezing") and with no way to report this to a service like sentry.

This is unacceptable for a framework claiming to be production ready.

It's unclear to me if this has been fixed in the last year or two.

I hear you. My comment was mostly addressing the ease of learning the basics. I eventually decided to abandon it once I ran into a couple of very-difficult-to-debug problems, but I also didn't try too hard to resolve them. I did not realize they have no error handling, that's interesting.

Without knowing your background or the app is not that useful of an insight.

Fair enough. I do have a little over a decade of experience, so perhaps that gives my opinion some bias. But regardless of the app, the premise behind Svelte feels as close to native as you can possibly manage. If you know html/css/js, it really shouldn't be hard to pick up the basics.

> No one would blame you for choosing React for a major project / new startup

Oh, I know people who would. Especially if that choice was made mechanically, without proper assessment of project requirements and framework strengths/weaknesses.

"Nobody ever got fired for X" is a rhetorical device which means "in most situations, you generally won't be faulted going with the most main-stream option on the market".

To be fair, as frustrating as it is sometimes for those of us who want to use the best tool, for those who have jobs affected by the risk in their decisions, it's a sound principle to default to.

I think the nuance is that much of the IT world moves much, MUCH slower than the web frontend.

"Nobody ever got fired for choosing IBM/AWS/Google/Microsoft/ESRI" will culturally last a loooooong time (5-10 years? 15?)

"Nobody ever got fired for choosing jQuery? Angular? React? Vue? Svelte? NPM? Yarn? Node? Deno? Next? Gatsby? Netlify? Webpack? Parcel? Babel? Bun? Canvas? WebGL? WASM? Workers? Cloudflare? Fly? Leaflet? OpenLayers? Mapbox?"... that has what, a lifespan of 2-3 years at best?

Nobody ever got fired for choosing standard browser technologies, I would have thought :-) Which, from your list, would include canvas, webgl, wasm, and workers. As for the rest — they may very well have been :-)

Well, there are a lot of abstractions over those. Canvas by itself in the raw isn't very useful without a framework on top of it. Same for the others, except maybe Workers...

I mean this from the perspective of a newly founded startup.

You're right that this doesn't hold true in a large corporation where they may already have a ton of code and preferred frameworks.

I would question the decision maker seriously if he chose a 130.5kb (.min) dom lib instead of sub 10kb alternatives.

The answer is always Ember.js. No doubt. It is just getting better and better and knows everything. The best choice.

Reply on news.ycombinator.com