6 ms·

Pretty clear signal that there's low appetite for full stack development in Swift. What are other promising future "end-to-end" (i.e. Web / Server / Mobile) de

• stock_toaster 7y ago
  For better or worse, I assume Rust and Go (and other future languages) will begin to start taking advantage of js VMs and js toolkits (frontend) via targeting (compilation) WASM at some point.
• nicoburns 7y ago
  People are actually already building stuff in Rust / <native code) / Rust (compiled to WASM running in a browser). The frontend frameworks in Rust are surprisingly good, and I wouldn't be too surprised if this becomes a mainstream option at some point. That said, I generally find there isn't all that much advantage to sharing a frontend and backend language.
  • mythz 7y ago
    Yeah they're mentions because it's being done in small niches (there's also Ruby/Haxe + many other transpile to JS languages), I just think they'll always lag behind the other popular and well supported contenders listed. I could be wrong but that's my impression after having worked on all of them which all provide decent development development experiences and end results - though they vary in strength amongst the different categories.
    • mhd 7y ago
      So you list Dart as being well supported on the server side? Did I miss some killer app/framework recently?
      • thosakwe 7y ago
        Self-plug: https://angel-dart.dev https://angel-dart.dev
      • mythz 7y ago
        It may not have the popularity but it has a well resourced technical team behind its development resulting in the Dart VM being a highly tuned technically brilliant piece of engineering. It has great support for server scenarios like gRPC [1] which I'd imagine is a popular back-end for Flutter iOS/Android Apps which is my personal #1 pick atm for native cross-plat iOS/Android development. I was an early adopter and saw promise in Dart based on the strength of its technical team (originally led by Lars Bak, Kasper Lund, Gilad Bracha, Bob Nystrom, etc) so invested a lot of time in developing a express-like web framework [2], Jade View Engine [3], Redis Client [4], JSON Client, etc. It had a nice/clean development experience, well-designed / fast libraries and APIs even back then, but abandoned it 6 years ago after going to work full-time on my own Startup and have been out of the loop of Dart VM/Server since then. Here's a short list of Dart web server frameworks I could find after a quick Google Search: https://medium.com/@suragch/web-server-frameworks-for-dart-197a073299eb https://medium.com/@suragch/web-server-frameworks-for-dart-1... Looks like Aqueduct [6] is the most popular at 1.4k stars, though I'd expect Dart Server is not going to see a major uptick until Google commits to a major project initiative like they're doing with Flutter & Angular Dart. So it might only see traction as a Dart gRPC server which can still provide an end-to-end development experience with SPA development with Angular Dart / gRPC Web / gRPC Dart and Flutter / gRPC Dart which I'll also add after having gone through a comparison of gRPC clients in different languages [6], Dart has basically the nicest async development experience [7]. [1] https://grpc.io/docs/quickstart/dart/ https://grpc.io/docs/quickstart/dart/ [2] https://github.com/dartist/express https://github.com/dartist/express [3] https://github.com/dartist/jaded https://github.com/dartist/jaded [4] https://github.com/dartist/redis_client https://github.com/dartist/redis_client [5] https://github.com/stablekernel/aqueduct https://github.com/stablekernel/aqueduct [6] https://github.com/NetCoreApps/todo-world/tree/master/src/clients https://github.com/NetCoreApps/todo-world/tree/master/src/cl... [7] https://github.com/NetCoreApps/todo-world/blob/master/src/clients/dart/bin/main.dart https://github.com/NetCoreApps/todo-world/blob/master/src/cl...
• paulddraper 7y ago
  More niche, but Scala is high quality for web/server/Android. (iOS is possible but not as good) Scala.js / Scala JVM / RoboVM
  • virtualwhys 7y ago
    Pretty niche indeed. Have you actually pulled off a PWA + Android + iOS in Scala? PWA is easy enough with Scala/Scala.js but I assumed that Android + iOS was a sufficiently painful process to warrant avoiding the attempt. Thought about mixing in Cordova or perhaps Ionic via the excellent ScalablyTyped typings library, but the path of least resistance is to just use TS on the frontend.
    • paulddraper 7y ago
      Not iOS, but Android. Coworker's article: https://dzone.com/articles/why-i-dont-regret-moving-our-android-app-to-scala https://dzone.com/articles/why-i-dont-regret-moving-our-andr... The parent post counted "Kotlin Native" as iOS. If you're willing to do that, you might consider "Scala Native" for iOS.
• sansnomme 7y ago
  Dart, if you consider Flutter an alternative to JS.
  • thosakwe 7y ago
    +1 for this, from a technical standpoint. Unfortunately there's just not a lot of interest in it (for end-to-end use, not just mobile). But some people who use it swear by it.
    • K0SM0S 7y ago
      I think the "recent" move to web apps by Flutter may spark interest up quite a bit. It's effectively native performance for the web, Android and iOS in one codebase. Combine that with a language that's easy to pick up from Js, and I would assume the business benefits would quickly make it a strong contender.
      • bsaul 7y ago
        Except last time i checked, flutter for web renders everything in a 2D canvas, which for some reasons doesn’t feel that great.
        • stoicShell 7y ago
          Would you care to educate me on why that is bad thing? (I'm a Jr web dev, it's not that obvious to me, although I suspect such a 'graphics-first' approach on the web leads to difficulties with resizing, responsive design, etc?)
          • bsaul 7y ago
            We’ll see how it works out, but my guess is the end result is going to be the same as with every other platform flutter has integrated: it needs to perfectly replicate the behavior of every native UI component on every mobile os / browser otherwise it’ll feel something’s wrong. For example scrolling, right clicking, resizing, zooming, button click, link colors, css animations, are all behaviors that could have various subtle behavior variations depending on the browser and its content (not to mention extensions such as ad blockers). Also, integrating with other js components will likely be impossible as well ( try to integrate the google maps js component into your layout... good luck) And browsers update way way more often than mobile os.
• Klonoar 7y ago
  Rust actually seems to have significant backing from both Mozilla and Microsoft (in varying forms, but it's there). I mean, if you asked me today to spit out a backend + web frontend + native app, I'd actually have no qualms about committing to Rust as an option. It's nowhere near perfect, but not as far off as people think either.
  • favorited 7y ago
    I think Rust is a great language, but until I see a successful app ecosystem start there's no way I'd consider it for a mobile app. I think Kenny Kerr's Rust/WinRT project is going to be great on Windows (and Kerr already proved he can accomplish this kind of project with C++/WinRT), but Rust's language model is so fundamentally different from iOS and Android's that I can't imagine it being feasible any time soon.
    • therockhead 7y ago
      I think it will eat into the C++ market share on mobile, which is a common strategy for larger apps that need to share business logic with native UI.
• crymer11 7y ago
  ClojureScript / Clojure / React Native
  • iLemming 7y ago
    It's too sad that majority of devs don't even realize how nice, stable and pragmatic Clojure ecosystem has become.
• bob1029 7y ago
  I would also note that there are Blazor experiments going on right now for purposes of targeting things like Xamarin and WinUI (both official and unofficial), so one could potentially see Blazor as a single unified framework for all deployment targets on the Microsoft-side of the house in the not-too-distant future. The class partial support offered by the latest version of Razor Components would make it really easy to separate view logic depending on platform (you can use media queries & js interop to discover platform type on web). I.e. you could have MyComponent.razor w/ all the logic, and then MyComponent.Xamarin.razor, MyComponent.WinUI.razor, etc. E.g.: https://github.com/Daddoon/BlazorMobile https://github.com/Daddoon/BlazorMobile and some initial discussion https://github.com/aspnet/AspNetCore/issues/11471 https://github.com/aspnet/AspNetCore/issues/11471
• k__ 7y ago
  Maybe OCaml/Reason?
  • thomasfortes 7y ago
    I love ocaml/reason and write a fair amount of code in both (both native and to javascript with bucklescript), but as a backend server the ocaml native ecosystem is far from ideal. If I was asked to do a full stack project with reason today I would write node bindings and use them.
    • brobinson 7y ago
      May I ask what your dev setup is? I've tried to get vscode + Reason language server working a few times (following the disparate sets of instructions on the site and Github repos) and was never successful.
      • thomasfortes 7y ago
        I mostly use linux and emacs, but I have the reason language server working everywhere, emacs, vscode, sublime and neovim. IIRC, the vscode only needed the extension from the store...
      • k__ 7y ago
        I had issues too. I installed the Reason extension from Jared, I think, and started a new project. My main problem was that I needed bs-platform installed globally AND locally in the repository. Otherwise the extension would display some errors that the bs-platform could not be found, which didn't help first, because I already installed it, haha.
• tessting 7y ago
  Is Kotlin Native any good?
  • mrits 7y ago
    I just started looking into and according to a few of my sources it isn't ready for primetime due to crashing issues and other problems with linux kernel versions
  • ptx 7y ago
    The threading model is not quite decided and the compiler is currently quite slow, but these things are being worked on and I think it looks very promising. The Objective-C interoperability doesn't fully support generics, so writing iOS apps entirely in Kotlin is inconvenient, but some companies are apparently (it was said at KotlinConf) already using it to share business logic on iOS.
• yangikan 7y ago
  How about Python based frameworks? Django/Flask? I know they are not suitable for Mobile..
  • mythz 7y ago
    Yeah Python is a clear powerhouse on the server, but as its weak a target in browsers & mobiles I didn't list it as a candidate for end-to-end development.
• briandear 7y ago
  Except all the people doing full stack swift tended to have gravitated towards Vapor. This IBM thing is a signal of nothing.
  • bsaul 7y ago
    Ibm is a strong brand in the enterprise sector. Such a big name pulling off is at least the sign that the tech didn’t catch up in their world. I don’t think server side swift has any chance against the other contender, it just has nothing special to offer and it’s often not even on par with competing technologies (go simplicity and concurrency, java ecosystem, python dynamic nature, rust safety, etc.). It doesn’t even have async... I would be surprised if anyone but iOS devs use it. Ps: and don’t get me wrong,i absolutely love its syntax and type system. But it’s not immediately obvious to someone already familiar with another PL.
• banachtarski 7y ago
  Prediction: React Native will be dead in 3 years.
  • lucasmullens 7y ago
    Why? It's already been around for 5 years and has certainly grown in popularity.
    • banachtarski 7y ago
      Frankly, it's awful. Measuring performance apples to apples, React Native is nearly strictly slower than a web application on mobile. As PWAs gain feature parity, I think there will be little to no point to React Native. Because of a lack of JIT capabilities, React Native JS just can't run nearly as fast as React on the web for example. That, coupled with bad architecture. Too much is deferred - you have deferred batching in react, followed by more deferred batching to create native layouts. This results in poor responsiveness. For toy applications you may not notice, but the architecture simply doesn't scale.
      • lucasmullens 7y ago
        > As PWAs gain feature parity, I think there will be little to no point to React Native I absolutely agree, but it'll take Apple more than a few years to be willing to make iPhones have native app/PWA feature parity. > Because of a lack of JIT capabilities There's the new Hermes engine which should speed things up The main reason React Native will stick around is that it lets React developers more easily transition to native, and there's a ton of React developers.
        • banachtarski 7y ago
          My point is that React on web is already faster than React Native today (and it feels perfectly natural, in fact, better). The entire point of going to React Native in the first place was ostensibly for responsiveness/performance, and given that it gives neither, I don't see what purpose React developers have to switch (except that it gives the illusion of "speed").
• IAmEveryone 7y ago
  I've been extremely impressed by Crystal. Coming from Ruby, I had very little trouble picking it up. And performance is simply phenomenal. The other day, I noticed a slow-running python data transformation job, mostly string comparisons. It was on pace to take 18h to finish. Within half an hour, I had a Crystal version, ported line-by-line, that took 3 minutes(!) to finish.
• akama 7y ago
  ReasonML is also a strong contender. Facebook's Messenger website is written in ReasonML [0] and compiling ReasonML for server work is pretty good. You can share a lot between the two codebases. People even write desktop applications using it, checkout Revery [1]. The applications that it produces are so fast, they are a delight to use. It's also very compatible with OCaml so you can get advantages from that ecosystem as well. [0] https://twitter.com/jordwalke/status/1177373197517221888?s=20 https://twitter.com/jordwalke/status/1177373197517221888?s=2... [1] https://github.com/revery-ui/revery https://github.com/revery-ui/revery
• fulafel 7y ago
  There's also web-native in "end-to-end" solutions space, which drops the requirement for mobile-native support.