I’m a web developer since 2003 and I’ve seen lots of tech stacks come and go. Back then there was no such thing as a JavaScript framework and the l...
For further actions, you may consider blocking this person and/or reporting abuse
This is the exact reason I have been moving to Svelte - because it compiles out to just JS. Everywhere I have worked, we have always run into clashes of frameworks, and trying to shoehorn a certain approach (or even a different version of the same approach) into something incompatible. The technical debt quickly became unmanageable. With Svelte components, we deliver just...Javascript, but we still get a ton of great framework features. Worth a look.
I haven't worked with Svelte intensively, but I hear great stories about it. Must take it for a spin soon.
Yeah, I highly recommend it. We have it setup so that we can build components, and dump them out as simple JS packages.
Something like this is all our teams need to do to consume one:
We have sorted out passing in theming, data API details, and also dumping out bundles that work in IE11.
It was a little trial and error, as everything is new, but it's been more than worth it, because Svelte is so nice to work with.
It's worth a look. (Actually, I should write a post about all the little odds and ends we sorted out to get this thing flying. Might be helpful for others.)
That looks so awesome! That you even made it work with IE11 is really cool. What about polyfills? And do you have a link to a GIT repo or something?
ok, ....Clearly I need to write about this. HAHAHA!
Yes, we got things working in IE11. We use babel for shims and polyfills, and we happened to be using
fetch
which requires a separate polyfill. The downside is that this took a 20k bundle, and bloated it up to about 103k. I kinda hate that, so I am currently R&Ding how to deliver a big fatty IE11 bundle, and a nice sleek bundle for everyone else.You have inspired me to write a big summation post, with links to resources. To solve all these challenges I was on a wild goose chase across the interwebs, and if I can help anyone else avoid that, I would be happy. lol.
I don't have a repo I can share, as this is internal, but I will create something to share soon.
I totally understand that you cannot share an internal repo. I have the same problem as well...I feel blessed that I've inspired you to write your own post. I can't wait to read it!
Please share it once it's ready :)
Totally will!
In the mean time, here's just some silly thing I have been playing with to test out Svelte concepts.
svelte.dev/repl/32f9c97b2c4f4da0a4...
I'm also using this to teach my oldest (7yrs) about programming. ;) But it's so nice to work with. Svelte gets a ton of overhead out of the way.
Interesting read. I've noted down to look into your suggested framework agnostic solution.
I agree there is a cost to using ready to use things especially frameworks. Good points around sharability between teams and also how each framework needs maintenance and would need upgrades.
Looking forward to reading more about framework agnostic. But curious on what the downsides are, how new it is, the developer community presence behind it, and gotchas/things to watch out for.
It's not really new, but web components are currently properly supported by the major browsers. So it's useful now. One of the caveats is global state. For example if you have an application where you have some profile data stored in de backend. And almost all the components need part of that data. But you could have a web component for that. But having dependencies on other components complicates things.
I think managing global state is rather an architectural challenge and not so much about web components. Every application, unregarding the framework used, has to deal with a global state in one way or another and every framework or library has its own solution for it. Just take a look at Redux, RxJs, NgRx or Vuex and all the different patterns (for example the Container Components pattern in React) invented to handle (global) state effectively.
Agreed. Global state is tricky indeed. Then you add in backend and persistence and it becomes more complicated.
there's a promising state management library at sam.js.org. It is inspired and follows the semantics of the Turing Award winner Dr. Leslie Lamport's TLA+. It is also framework agnostic. You should check it out!
Thank you so much! I'm glad that you enjoyed my post and I'm planning to write much more on Framework Agnostic Topics, so keep an eye out on my blog! :)
I completely agree with you. Web Components aren't the holy grail of Web Development but have their own specific purposes and you don't have to ditch all frameworks in favor of framework-agnostic solutions, because they are there for a reason. So I'd say: Make use of the best of both worlds :)
Long live webcomponents! We are doing the same at my company and it saves so much time for the autonomous teams 👍
That sounds awesome! And what about consistency?
I am looking into adopting this approach for our project. I wonder if anyone has experience with setting up the build process for development and production with framework agnostic approach? Ideally, I want to have the build process replaceable meaning that I may use Webpack and then later, switch to Parcel or anything else.
Veni, vidi, vici... similar experience I had :D
Ha ha ha I love your comment! How did you solve it? What where the results?
Nice perspective.. 👍