> Just imagine a workflow where you change one model working in the front end and the compiler throws and error that the back-end does not implement what you need.
+1 On Mon, 1 Aug 2016 at 09:57 Peter Damoc <pda...@gmail.com> wrote: > Zach, > > Of course being backend agnostic is an amazing thing. > That being said, I would love to have a backend that could be implemented > in Elm and one full-stack solution that has perfect impedance match. > This way, the data models can be shared between the backend and the > front-end and with a little bit of convention, the whole Json encoding and > decoding could disappear (it could be handled automatically by some > library). > Just imagine a workflow where you change one model working in the front > end and the compiler throws and error that the back-end does not implement > what you need. > A user learning Elm for the front-end could also leverage his/her > knowledge to move from front-end to full-stack. > This could be huge for freelance lone developers. > > > > > On Mon, Aug 1, 2016 at 10:32 AM, Zachary Kessin <zkes...@gmail.com> wrote: > >> I think that being backend agnostic was / is a good choice. When I >> started SquareTarget http://squaretarget.rocks I was able to reach for >> Erlang/OTP and WebMachine on the backend, which is a stack that I know well >> and I know how it performs under stress etc. Others have used Ruby, Elixir >> or Haskell. While getting the benefits of Elm on the frontend. >> >> As for having to context switch between erlang and elm. That is an issue, >> on the plus side, the Elm Architecture and an Erlang gen_server are pretty >> similar in how they do things. But the two languages are quite frankly very >> different, in that they were both built to solve a problem, but two very >> different problems. Elm wants to catch all errors in the type system. >> Erlang was built on the assuption that there are some errors that can only >> be caught in real time and in an external process such as a server hardware >> failure. >> >> Honestly, I think the actual problems being solved by frontend code and >> backend code make the idea of a whole stack language not a really good one. >> >> Zach >> >> >> >> >> >> >> ᐧ >> >> On Mon, Aug 1, 2016 at 9:06 AM, Peter Damoc <pda...@gmail.com> wrote: >> >>> Hi Neil, >>> >>> Few comments on the issues you've raised: >>> >>> 1. Elm plans to go to the server side too. There are already >>> proof-of-concept that allows one to use Elm server-side and with the advent >>> of 0.18 (next version) we might see official support for that. Also, one >>> could use something like Horizon and bypass the server-side completely. >>> 2. Actually, people who had success introducing Elm into production >>> started within a very small corner of the app and gradually implemented >>> more and more in Elm. You can read the latest blog post >>> <http://elm-lang.org/blog/how-to-use-elm-at-work> that talks more about >>> this. >>> 3. What would qualify as a moderately complex example? To me, ToDoMVC is >>> moderately complex. Also, you could find more moderately complex stuff on >>> builtwithelm.co >>> 4. Interop from JS to Elm is beautifully simple through the mechanism of >>> ports. Basically you can push messages into the Elm app. Of course, Elm >>> does not allow direct state mutation of its program because that would >>> defeat some of its purpose. >>> 5. There was a proof of concept for a native version of Elm via >>> react-native but you are right, there is no native-app framework in Elm >>> yet. >>> 6. redux was inspired by Elm Architecture so... if you use that, you are >>> already getting closer to Elm. >>> >>> Elm is not ready for the early-majority yet, I'm not sure it is really >>> in the realm of the early adopter either. Most of us here might be >>> innovators and there are a set of advantages that come with that but also >>> disadvantages. :) >>> >>> So, if you're looking for a full-stack battle proven solution, you have >>> come to the wrong place. >>> If you are looking for something to take some of the pain of web >>> development away, you might be in the right place. >>> >>> >>> >>> >>> On Mon, Aug 1, 2016 at 8:25 AM, nrser <nr...@ztkae.com> wrote: >>> >>>> thanks dude. >>>> >>>> i read a considerable amount more before going sleep last night... >>>> checked out the compiler repo (which has a much more clear description of >>>> elm - "Elm is a type inferred, functional reactive language that compiles >>>> to HTML, CSS, and JavaScript.") and played around with trying to compile >>>> something i could use from js (didn't seem possible). >>>> >>>> i think the conceptual architecture is fantastic. i've been down the >>>> road you talk about... managed large products with javascript / >>>> actionscript UI front ends... the state management was a disaster. constant >>>> source of bugs, which at the scale we were operating translated into very >>>> serious amounts of lost time and money. >>>> >>>> the canonical source of truth and well-defined states and transitions >>>> is *fucking awesome*. revolutionary. and i really like the idea of >>>> using a functional, type-safe language. >>>> >>>> but... >>>> >>>> 1. too narrow of a scope. unless you already know Haskell (and most >>>> people don't) you're learning an unfamiliar language that can only be >>>> used >>>> in exactly one part of the stack and will need to constantly context >>>> switch >>>> in and out of it. in my opinion, the major advantage to universal >>>> javascript is despite js being such a POS language (thought babel has >>>> significantly eased this pain) cutting out this context switch. seems >>>> like >>>> logic would also need to be duplicated in elm and the back-end language >>>> as >>>> well, which has been a source of bugs in my experience. >>>> 2. seem all-or-nothing - my front-end is either in Elm or it's not? >>>> i'm not sure i can ease it in slowly and partially. if you have a rails >>>> app >>>> or other traditional "fat-server" app this is probably not that big of a >>>> deal because you can keep the server portion, serve api end points, and >>>> re-write the client stuff in elm (though that alone is a huge amount of >>>> effort and risk), but everything i'm dealing with is already js on both >>>> sides. >>>> 3. i'm not really sure about any of that though, because i couldn't >>>> find any full-app or moderately complex examples to look at. >>>> 4. it doesn't seem like interop goes the other way. i compiled a >>>> simple module elm and took a look at the source... didn't seem setup to >>>> use >>>> from javascript. i would love to write core libraries in something like >>>> elm >>>> and use them from javascript by also requiring the runtime. >>>> 5. react has a mobile story. >>>> 6. redux (what my company is currently using) might be *good enough*. >>>> redux is also really green and takes considerable work to understand >>>> adapt >>>> to significantly complex apps but it plugs right in besides whatever >>>> you've >>>> already got going. >>>> >>>> >>>> i really wish there was a full-stack started kit. i just don't have the >>>> bandwidth to put the rest together right now to take it for a real spin. if >>>> i find the time to come back to it and put something together i'll def >>>> share it with the community. >>>> >>>> On Sun, Jul 31, 2016, at 20:56, Nathan Schultz wrote: >>>> >>>> Hi Neil, I'm an Elm beginner as well, but I've been enjoying it thus >>>> far. >>>> >>>> Elm is a programming language which currently compiles to JavaScript >>>> (along the lines of TypeScript, CoffeeScript, Dart, ClojureScript, >>>> PureScript, etc). >>>> It is primarily geared towards front-end web-development. >>>> >>>> Like any good programming language, it has a "Framework": a set of core >>>> and optional libraries (called 'packages' in Elm), which aid in >>>> development. React, Angular, etc, are JavaScript frameworks. >>>> >>>> Elm is also a philosophy called 'The Elm Architecture' (TEA). It is a >>>> pattern that naturally evolved out of using Elm, which provides a clear and >>>> succinct way of solving problems and taming complexity. This is similar to >>>> React's Redux. >>>> >>>> So why Elm? Ultimately, it is trying to tame the 'maintainability' >>>> nightmare, which is JavaScript. If you've ever seen enough large JavaScript >>>> projects, without the up-most discipline, you'll understand that JavaScript >>>> code can become almost undecipherable. Even with the aid of JavaScript >>>> frameworks, such as Angular, it can be painful adding new features to a >>>> complex user-interface, as fixing one thing seems to break a dozen. Elm on >>>> the other hand manages complexity by better managing "state" changes (which >>>> is what Redux does for React); which essentially makes even complex >>>> projects easy to reason about, easy to change, and easy to add new features >>>> without fear. Elm goes beyond where Redux does in making your programs >>>> reliable - because it doesn't suffer from many of the 'warts' of the >>>> JavaScript language (such as no type safety, no null-based errors, impure >>>> functions, etc). Essentially Elm programs are reliable - if it compiles, >>>> they usually just work with no 'run-time' bugs. Elm is also designed as an >>>> easy language to learn - and in fact I've seen some projects created by >>>> school children. >>>> >>>> On the down side, Elm is not fully mature yet; there are breaking >>>> changes with each new release. But the language developer, Evan Czaplicki, >>>> is making a concerted effort to fix any mistakes now so it will be a solid >>>> language for years to come. >>>> Elms guarantees around reliability are a blessing and a curse; you >>>> can't just call a useful Javascript library directly, as 'unsafe' code can >>>> potentially 'sink the ship', so rather, you must wrap potentially 'unsafe' >>>> calls behind a 'port', which quarantines your Elm program from problems but >>>> involves a bit more work. >>>> And currently running Elm on the server-side is a "work in progress" - >>>> so it doesn't yet provide an end-to-end solution. >>>> >>>> It's also worth checking out the Elm Slack channel; there's pretty >>>> much always someone on there at all hours who can answer questions: >>>> https://elmlang.slack.com/ >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "Elm Discuss" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/elm-discuss/7LMukS-VXpM/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> elm-discuss+unsubscr...@googlegroups.com. >>>> 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 elm-discuss+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> There is NO FATE, we are the creators. >>> blog: http://damoc.ro/ >>> >>> -- >>> 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 elm-discuss+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Zach Kessin >> SquareTarget <http://squaretarget.rocks?utm_source=email-sig> >> Twitter: @zkessin <https://twitter.com/zkessin> >> Skype: zachkessin >> >> -- >> 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 elm-discuss+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > > -- > 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 elm-discuss+unsubscr...@googlegroups.com. > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
