Indeed, React is more of a stop-gap before full webcomponent support is out in browsers. And nowadays with webcomponents.js emulating webcomponents on about everything 'fairly' decently (although some slowly, which libraries like Polymer smooth out) it is becoming less interesting. In my opinion Elm really needs to have a smooth integration with webcomponents. A webcomponent is a very small unit, something elm fits fantastically in, has two way data-binding up/down the DOM stack, and getting built-in to browsers (Chrome is about the only one with near-full support though, but it is coming in others). It is something that Elm would fit fantastically in if we could somehow get information *out* of a webcomponent, right now elm can only put information 'in'. A binding to the HTML5 Observer API being transformed into Elm Messages would be about perfect.
On Wednesday, November 9, 2016 at 8:39:15 AM UTC-7, Alexandre Galays wrote: > > So true. Even React is not here to stay. Libs come and go, don't feel > attached to one. Recruit flexible people who won't go on strike because the > stack changes. > > > On Monday, November 7, 2016 at 7:07:06 PM UTC+1, John Orford wrote: >> >> I think *convincing* is besides the point. >> >> Tech comes and goes. >> >> I would rather read through the features of Elm, and make a checklist. >> >> Pure functions >> Immutability >> ADTs >> Explicitness (avoiding type classes and other abstractions) >> User friendliness >> ... >> >> If your team buys into these features, then they should go with Elm or >> any other setup with the same features. >> >> I.e. I suppose, set out what everyone agrees is the basis of good code, >> and then go from there. >> >> Worst case, if Elm vanishes tomorrow, at least you're all on board with >> the same goal of writing code in to this standard, and can code move to >> PureScript or Typescript or whatever else matches in years to come. >> >> On Mon, 7 Nov 2016 at 18:57 Rex van der Spuy <[email protected]> wrote: >> >>> Just a few comments: >>> >>> > The one thing I'm not really sure I'm prepared to answer is how I can >>> be sure that Elm isn't just another CoffeeScript or Dart, and in 2 or 3 >>> years we'll have an impossible time hiring anyone > > who knows how to use >>> it because everyone's going to go back to JavaScript. >>> >>> Don't invest in any single technology or workflow - just invest in your >>> own ability to adapt quickly to constant change. >>> Front-end software for the web is essentially disposable - let's embrace >>> this! >>> If you get a couple of years of mileage out of your front end app before >>> it you need re-write it from scratch using a completely new or different >>> technology, you're doing great! >>> My advice is just grab the best technology you can at the moment, milk >>> it for all its worth, jump to something better when it comes along - and >>> don't look back. >>> The path my career took over the past 25 years was: Basic, Hypercard, >>> Director/Lingo, Java, Flash/AS3, JavaScript, and now Elm. >>> Nothing is forever in this industry, and most things are deliriously >>> short lived. >>> Just relax and enjoy the ride! :) >>> >>> ... However! >>> Until Elm reaches v.1.0 (which could be years from now, nobody knows) >>> every version bump, every six months or so, results in API breaking changes >>> at the language level. >>> Some of those changes, like from 0.16 to 0.17 have been huge and have >>> required quite a painful upgrade. >>> (For example It took me 7 hours to upgrade a 3000 LOC app, making over >>> 200 changes. All of those 7 hours, except the last five minutes, was done >>> blind just following the compiler's messages.) >>> Are you prepared to invest in upgrading your entire Elm codebase with >>> every version bump to keep it current? >>> In that regard, although you can definitely use Elm in production, its >>> still very much an experimental technology - and we are the lab rats. >>> But, it says a lot for the dismal state front end web development even >>> under these conditions Elm is way better than anything else out there! >>> >>> Regarding learning Elm: >>> I'm a non-talented, slow learner who has to do everything about 10 times >>> before it sinks in. >>> And then I have to do it another 10 times just to make sure. >>> It took me about 2 weeks of true beginner-level head-banging to get to >>> grips with Elm, and another 2 weeks of tentative experimentation before I >>> started being productive. >>> But, the time I spent learning Elm has been paid back many times over by >>> the time I've saved debugging my apps. >>> Elm has unquestionably saved me **months** of debugging time. >>> I've had experiences with Elm's compiler that have bordered on the >>> supernatural - it's pointed me to bugs that would have taken me weeks of >>> laborious mine-sweeping if I have had been using pure JS. >>> And, the best part about learning Elm? >>> It makes programming fun again! >>> >>> Regarding hiring: >>> A search for companies hiring Elm programmers will turn up exactly 1: No >>> Red Ink. >>> There is no statistically significant demand for Elm programmers >>> whatsoever. >>> However, the smartest programmers in the world are all here on >>> elm-discuss! >>> Elm users self-select as top talent that you would never find in such >>> high concentrations anywhere else. >>> So, just post your job applications here and I'm sure you'll have dozens >>> of high-quality applications. >>> >>> >>> >>> >>> On Saturday, November 5, 2016 at 6:01:42 PM UTC-4, Zacqary Adam Xeper >>> wrote: >>>> >>>> Hey Elmos, >>>> >>>> I've finally gotten an opportunity to pitch Elm to my fairly large dev >>>> team. I feel like I'm prepared to make the case for it against a lot of >>>> objections: i.e. how will we learn yet another programming language, do we >>>> really need something that never throws exceptions, etc. etc. >>>> >>>> The one thing I'm not really sure I'm prepared to answer is how I can >>>> be sure that Elm isn't just another CoffeeScript or Dart, and in 2 or 3 >>>> years we'll have an impossible time hiring anyone who knows how to use it >>>> because everyone's going to go back to JavaScript. >>>> >>>> How do I convince Elm skeptics that this thing is here to stay? I can >>>> do a great job of incorporating a small bit of Elm code into our stack to >>>> show how great it is, but they won't even let me merge it into prod unless >>>> I can make the case for its longevity. >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Elm Discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
