Custom Elements are quickly gaining traction. They're in Chrome and Safari, and will be in Edge/FF soon based on discussions with those teams. The Angular team is toying with using them directly (not sure if this will ever come to fruition or not). We'll work with the React team to get it working with better compatibility. Right now our components work in React use just need to use a tiny "polyfill" wrapper. The experience in React isn't as good as we'd like, but it's pretty darn solid in Preact.
To me, it doesn't seem like too big of a stretch to think that the popular frameworks of today will move to the custom element spec instead of their own proprietary component model.
A simple solution today would be to put the shared, heavy code in it's own component and call methods directly on that component. That's how we're share code across components in Ionic.
They're very similar concepts. Svelte was an inspiration to Stencil. We wanted to take a different approach to developer experience and ship custom elements by default.
There are hundreds of thousands of people using Ionic so we're certainly not throwing in the towel. One of the goals when creating Ionic was to build re-useable components that could be used by anyone. At the time (2013), this wasn't really feasible, so we went all in on Angular. Now that Web Component adoption in browsers is pretty solid, it has enabled us to fulfill the original vision of enabling developers using any web-based toolset to build incredible apps.
We're all in on web tech. We think it's the smarter choice long term.
No, Ionic 2 is a complete rewrite of the framework with all of the lessons learned from Ionic 1. Writing apps with Ionic 2 is an insanely great experience!
Ionic 2 is much more performant and scales much better for app development than Ionic 1. I have yet to meet anyone who has not really enjoyed developing Ionic 2 apps. We take a tremendous amount of pride in the developer experience!
Native apps will always be a little faster but if you can get 60FPS either way, who cares? Ionic is easier to build apps with, and developing in the browser is a joy.
A huge advantage of Ionic is being able to deploy the same code base to the web as a PWA and to a phone natively as a cordova app. Soon Ionic Native will expand to support PWA and Electron, too, so it will truly be a write once run anywhere experience.
I was really very well impressed by the small size of ionic apps. It's in the order of ~3MB which is great.
But the startup times are somewhat big. I'm talking, for the simplest of applications a startup time of ~5.5 seconds in ionic 2 (the beta) vs ~2 seconds in React Native in Android.
For me, that detail has a significant impact in usability.
So start up time is something that we are very focused on at the moment. Especially on the PWA side of things, TTI (time to interactive) is exceedingly important to ensure a good user experience. We are working on a few things at the moment but most likely the first one to hit is gonna be code splitting. So with code splitting, instead of shipping just one big bundle you will be shipping smaller bundles that are lazy loaded based on routes. This means that when the app first loads only the first bundle for the first view in your app will have to be loaded, parsed etc and then the other bundles will be lazy loaded. With this setup the browser (or webview) will never have to parse and load a huge bundle all in once, it will instead only have to deal with smaller bundles. This should give a pretty big improvement as parsing javascript is slow in every browser. From my testing on a moto g each MB of JavaScript in an ideal situation takes about 2 seconds to be parsed, so reducing the amount of JavaScript the browser has to deal with is a very fast way to get better load times.
Well unfortunately ionic2 is super slow to develop..
Ionic1 is nice in the beginning, but if your app grows, you're simply waiting and waiting.
This is a problem with all javascript frameworks.. just 'watch' a directory for changes and restart, recompile everything
This isn't that big an issue if you set your JS build pipeline up properly with modern tools. Webpack can chunk your built files and will only rebuild the ones it needs to upon change. Combine that with hot module reloading and things are snappier than they've been in a long time.
Interesting. A few days ago I stopped receiving pull request emails as well. Granted I routinely delete these after I process them - but I was alarmed when I checked my spam and saw them there.
This is really nice. Great work! Ignore the haters - you're on the right track with this. Most of the people giving you guff are not the type that create things - they're the ones who pretend to create things.
I've already got jobs for software developers delivered to my inbox from the copious amount of recruiters emailing me... So incredibly annoying! I swear, they just spam every potential candidate for every job. The WORST!
Power electronics (troubleshooting and support, but no design), systems engineering[1], real-time embedded software (radar signal processor, so "big" embedded), and NLP. My resume is linked through my website in my profile here.
This is a good skill set for San Jose or Austin, not so great for Dallas unless you want to work for one or two of the local telecom companies that are still investing in engineering here.
I'm not limiting myself to Dallas. My original comment was more about the propensity of recruiters to not look outside the local area of the job they are trying to fill. If you aren't already in the area the recruiters are not beating your door down.
How many of those are CyberCoders? I've heard that their software is setup so that every time a recruiter there does a search, it e-mails every single matching candidate in their database. A single search results in roughly 5000 e-mails. As a result, they dwarf the e-mail volume of every other recruiter out there.
To me, it doesn't seem like too big of a stretch to think that the popular frameworks of today will move to the custom element spec instead of their own proprietary component model.