Michael Klein

@nullvoxpopuli 1. You create temp vars which makes the example more loc for playwright. 2. You are not using the recommended locators like getByText, getByRole etc. 3. Playwright has way more functionality than ember-testing. Isn't this comparing apples to oranges?

These are using vastly different technologies, but, I have to say that QUnit (+ qunit-dom) has such a good API. Sorry playwright. Both files are 18 lines. Playwright's test is 12 lines QUnit's test is 8 lines. Over time, as you write more tests, that per-test savings adds up.

@nullvoxpopuli 5? Barely any app I know has made the switch to 4. What's in 5? Native TS support?

Just got a peerDependency error about Ember VEE FIVE!!! #EmberJS v5 is just around the corner!!!! 🥳🥳🥳🥳

@OllieDolan @FilipeFullStack How do you determine what will hit critical mass, though? Furthermore, why do you care about critical mass? There have been enough job opportunities over the years with #EmberJS. Software dev isn't static, new tech will emerge, and you will need to adapt anyway.

@LevelbossMike @FilipeFullStack i dont care about definition of framework my only point is don’t lose time learning stuff that won’t hit critical mass 🙃

@OllieDolan @FilipeFullStack 5. You can draw graphs all day long, but they don't necessarily represent reality that well. Interest over time doesn't mean companies aren't using it.6. Web dev is hype-driven and people don't learn lessons from the past, but will reinvent the same things over and over again.

@OllieDolan @FilipeFullStack 3. #EmberJS has stood the test of time, as many apps with it have been around for >10 years without a complete rewrite. 4. As a dev, you were able to grow with it and still get an improved new DX every other year without having to throw away your prior investment.

@marcoow @nullvoxpopuli @knownasilya Agree. Wasn't claiming any strategy is wrong, I was just thinking about the 80% use-case and wondered why SSR would be the default for a client-side app. #sveltekit is great and covers all. Doubt #emberjs will make the cut, unfortunately

@LevelbossMike @nullvoxpopuli @knownasilya Other frameworks are better for these scenarios and might not have a great client-side-only story (although that’s clearly the goal – coming up with sth. that works great across the spectrum). I think claiming either of those optimization strategies is wrong misses the point

I'm not a hater, #sveltekit feels cool. Having developed client-side apps for the past decade, it feels weird nobody seems to realize how deep of a hole we have dug ourselves into. Is this supposed to feel productive? SSR for what? You now have to maintain two apps, SSR & CSR.🔥

@marcoow @nullvoxpopuli @knownasilya What are examples of non e-commerce pages that are not behind a login that "need" to be apps? Feels to me, client-side apps are just the default for websites today, but people fail to realize how expensive that is to build.

@LevelbossMike @nullvoxpopuli @knownasilya What I say is most Ember apps are behind login for the above reasons but that’s not necessarily most apps :)

@marcoow @nullvoxpopuli @knownasilya How many people are building an e-commerce site from the ground up? Compared to regular apps behind login? Why is that the scenario these frameworks are optimizing for? Also content-centric pages. Why a with a client-side framework in the first place?

@marcoow @nullvoxpopuli @knownasilya SSR is 100% relevant for e-commerce, that's why I said *most* apps are behind a login. Feels weird that SSR would be the default for client-side, given the complexity it adds. If you need it, great that you have a good story for it, but you probably want to opt-in not opt-out.

@nullvoxpopuli @knownasilya I worked on an app 11 years ago that was rendering an #emberjs frontend and had FB/Twitter previews by serving dedicated crawler pages. SSR to me feels like an over-optimization where nobody is thinking about ROI. Most apps are behind a login anyway. This is not rocket science 🚀

@knownasilya @LevelbossMike Yeah.. i super don't like how expensive SSR can get. Like... As you scale, you need sooo much infra

@gen_nja @triketora As a traditional mechanical engineer myself, I personally believe programmers should just be called programmers only. However, if they earn the title of Professionally Liscensed Engineer in Software Engineering by NCEES then they can have the title of engineer only.

Coming from #emberjs and having heard for the past 10 years that it was hard to pick up for its “magic”, reading the docs for #sveltekit feels comical. It's littered with conventions that are plain weird. It also adds SSR complexity, which you probably don't need. This is fine 🔥

@ChaiWithJai Great thread and cool use of ChatGPT 👏

And that's a wrap! Still so many more questions to ask, but I'll save those questions for the Ember Discord. I'm hoping to continue sharing my learnings. Hoping to share a lesson I got from my mentor @LevelbossMike on "Flow Testing" next week.

Decided to revisit @swyx's Coding Career Handbook today. There's a chapter on Knowing Your Tools. In the chapter he lists out questions that are often omitted from "advanced" workshops about X frontend framework. So... I asked ChatGPT to answer them.

@baaz No surprise there :D! #sveltekit's focus on SSR seems weird to me given the complexity it adds, but so far so cool

@LevelbossMike I think we have a similar taste in JavaScript frameworks :D

Pattern matching URLs with #svelte kit router is pretty cool 🥳 as is #sveltekit in general. whoop whoop kit.svelte.dev/docs/advanced-…

@joegaudet @chriseppstein Or rather, much, harder to reason about your system if you think about it that way.That's the reason all of this breaks down quickly in my experience. Just ignoring the fact that you are dealing with a stateful system won't make that fact go away. You have to model this properly.

@joegaudet @chriseppstein UI as a function of state is mostly a lie. Yes, in theory, rendering the entire state of the system at any time will give you the correct representation of your system. But it's impossible to reason your system in that way.

Having now read about 50 takehome assignments in @reactjs I can confirm my already held belief that @emberjs makes considerably more sense. There's so much functional nonsense for operations as simple as adding or removing from an array. OOP is pretty nice.