What is Elm and what are its top alternatives?
Top Alternatives to Elm
Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. ...
It is a general purpose language that can be used in any domain and use case, it is ideally suited for proprietary business logic and data analysis, fast prototyping and enhancing existing software environments with correct code, performance and scalability. ...
Elixir leverages the Erlang VM, known for running low-latency, distributed and fault-tolerant systems, while also being successfully used in web development and the embedded software domain. ...
Elm alternatives & related posts
- Type safe97
- The best AltJS ever46
- Best AltJS for BackEnd27
- Powerful type system, including generics & JS features14
- Nice and seamless hybrid of static and dynamic typing10
- Aligned with ES development for compatibility9
- Compile time errors9
- Structural, rather than nominal, subtyping6
- Code may look heavy and confusing4
related TypeScript posts
Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.
After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...
I needed to choose a full stack of tools for cross platform mobile application design & development. After much research and trying different tools, these are what I came up with that work for me today:
For the client coding I chose Framework7 because of its performance, easy learning curve, and very well designed, beautiful UI widgets. I think it's perfect for solo development or small teams. I didn't like React Native. It felt heavy to me and rigid. Framework7 allows the use of #CSS3, which I think is the best technology to come out of the #WWW movement. No other tech has been able to allow designers and developers to develop such flexible, high performance, customisable user interface elements that are highly responsive and hardware accelerated before. Now #CSS3 includes variables and flexboxes it is truly a powerful language and there is no longer a need for preprocessors such as #SCSS / #Sass / #less. React Native contains a very limited interpretation of #CSS3 which I found very frustrating after using #CSS3 for some years already and knowing its powerful features. The other very nice feature of Framework7 is that you can even build for the browser if you want your app to be available for desktop web browsers. The latest release also includes the ability to build for #Electron so you can have MacOS, Windows and Linux desktop apps. This is not possible with React Native yet.
Framework7 runs on top of Apache Cordova. Cordova and webviews have been slated as being slow in the past. Having a game developer background I found the tweeks to make it run as smooth as silk. One of those tweeks is to use WKWebView. Another important one was using srcset on images.
I configured TypeScript to work with the latest version of Framework7. I consider TypeScript to be one of the best creations to come out of Microsoft in some time. They must have an amazing team working on it. It's very powerful and flexible. It helps you catch a lot of bugs and also provides code completion in supporting IDEs. So for my IDE I use Visual Studio Code which is a blazingly fast and silky smooth editor that integrates seamlessly with TypeScript for the ultimate type checking setup (both products are produced by Microsoft).
I use some Ruby scripts to process images with ImageMagick and pngquant to optimise for size and even auto insert responsive image code into the HTML5. Ruby is the ultimate cross platform scripting language. Even as your scripts become large, Ruby allows you to refactor your code easily and make it Object Oriented if necessary. I find it the quickest and easiest way to maintain certain aspects of my build process.
For the user interface design and prototyping I use Figma. Figma has an almost identical user interface to #Sketch but has the added advantage of being cross platform (MacOS and Windows). Its real-time collaboration features are outstanding and I use them a often as I work mostly on remote projects. Clients can collaborate in real-time and see changes I make as I make them. The clickable prototyping features in Figma are also very well designed and mean I can send clickable prototypes to clients to try user interface updates as they are made and get immediate feedback. I'm currently also evaluating the latest version of #AdobeXD as an alternative to Figma as it has the very cool auto-animate feature. It doesn't have real-time collaboration yet, but I heard it is proposed for 2019.
For the UI icons I use Font Awesome Pro. They have the largest selection and best looking icons you can find on the internet with several variations in styles so you can find most of the icons you want for standard projects.
For the backend I was using the #GraphCool Framework. As I later found out, #GraphQL still has some way to go in order to provide the full power of a mature graph query language so later in my project I ripped out #GraphCool and replaced it with CouchDB and Pouchdb. Primarily so I could provide good offline app support. CouchDB with Pouchdb is very flexible and efficient combination and overcomes some of the restrictions I found in #GraphQL and hence #GraphCool also. The most impressive and important feature of CouchDB is its replication. You can configure it in various ways for backups, fault tolerance, caching or conditional merging of databases. CouchDB and Pouchdb even supports storing, retrieving and serving binary or image data or other mime types. This removes a level of complexity usually present in database implementations where binary or image data is usually referenced through an #HTML5 link. With CouchDB and Pouchdb apps can operate offline and sync later, very efficiently, when the network connection is good.
I use PhoneGap when testing the app. It auto-reloads your app when its code is changed and you can also install it on Android phones to preview your app instantly. iOS is a bit more tricky cause of Apple's policies so it's not available on the App Store, but you can build it and install it yourself to your device.
So that's my latest mobile stack. What tools do you use? Have you tried these ones?
- Virtual dom651
- Data flow174
- Isn't an mvc framework123
- Reactive updates113
- Explicit app state110
- Learn once, write everywhere23
- Uni-directional data flow18
- Easy to Use16
- Works great with Flux Architecture14
- Great perfomance10
- Built by Facebook8
- TypeScript support5
- Easy to start4
- Feels like the 90s4
- Fancy third party tools3
- Server side views3
- Great migration pathway for older systems2
- Server Side Rendering2
- Fast evolving2
- Simple, easy to reason about and makes you productive2
- Rich ecosystem2
- Has functional components2
- Has arrow functions2
- Strong Community2
- Very gentle learning curve2
- Excellent Documentation2
- Super easy2
- Scales super well2
- Just the View of MVC2
- Start simple1
- Split your UI into components with one true state1
- Every decision architecture wise makes sense1
- Beautiful and Neat Component Management1
- Allows creating single page applications1
- Requires discipline to keep architecture organized33
- No predefined way to structure your app21
- Need to be familiar with lots of third party packages20
- Not enterprise friendly6
- One-way binding only1
- State consistency with backend neglected1
related React posts
I am starting to become a full-stack developer, by choosing and learning .NET Core for API Development, Angular CLI / React for UI Development, MongoDB for database, as it a NoSQL DB and Flutter / React Native for Mobile App Development. Using Postman, Markdown and Visual Studio Code for development.
I've used both Vue.js and React and I would stick with React. I know that Vue.js seems easier to write and its much faster to pick up however as you mentioned above React has way more ready made components you can just plugin, and the community for React is very big.
It might be a bit more of a steep learning curve for your friend to learn React over Vue.js but I think in the long run its the better option.
- Purely functional4
- More Haskell-ish than Haskell0
- Have Some Bugs1
related PureScript posts
- Pattern Matching4
- Type System3
related ReasonML posts
- Purely-functional programming83
- Statically typed64
- Open source38
- Great community37
- Built-in concurrency29
- Built-in parallelism28
- Referentially transparent22
- Intellectual satisfaction13
- Type inference13
- If it compiles, it's correct11
- Great type system4
- Proposition testing with QuickCheck4
- One of the most powerful languages *(see blub paradox)*3
- Highly expressive, type-safe, fast development time2
- Kind system2
- Purely-functional Programming2
- Pattern matching and completeness checking2
- Better type-safe than sorry2
- Type classes2
- Best in class thinking tool2
- Great maintainability of the code2
- Error messages can be very confusing6
- Too much distraction in language extensions6
- Libraries have poor documentation4
- No best practices3
- No good ABI3
- Poor packaging for apps written in it for Linux distros2
- Sometimes performance is unpredictable2
- Slow compilation1
related Haskell posts
Why I am using Haskell in my free time?
I have 3 reasons for it. I am looking for:
Improve functional programming skill.
Improve problem-solving skill.
Laziness and mathematical abstractions behind Haskell makes it a wonderful language.
It is Pure functional, it helps me to write better Scala code.
Highly expressive language gives elegant ways to solve coding puzzle.
- Real Reactivity23
- Fast as vanilajs21
- Near to no learning curve19
- Compiler based16
- Use existing js libraries15
- All in one15
- Very easy for beginners12
- No runtime overhead10
- Ease of use10
- Built in store9
- Best Developer Experience5
- Start with pure html + css5
- Learning Curve2
- Hard to learn2
- Event Listener Overload2
- Little to no libraries1
related Svelte posts
I just want to have a simple poll/vote...
If you guys need a UI/Component Library for React, Vue.js, or AngularJS, which type of library would you prefer between:
1 ) A single maintained cross-framework library that is 100% compatible and can be integrated with any popular framework like Vue, React, Angular 2, Svelte, etc.
2) A native framework-specific library developed to work only on target framework like ElementUI for Vue, Ant Design for React.
Your advice would help a lot! Thanks in advance :)
- Erlang vm127
- Great documentation109
- Great tooling102
- Immutable data structures82
- Open source77
- Easy to get started61
- Actor library57
- Functional with a neat syntax28
- Ruby inspired28
- Erlang evolved22
- Beauty of Ruby, Speed of Erlang/C20
- Fault Tolerant17
- High Performance13
- Good lang10
- Stinkin' fast, no memory leaks, easy on the eyes9
- Doc as first class citizen9
- Pipe Operator8
- Resilient to failure7
- Fun to write6
- GenServer takes the guesswork out of background work5
- Not Swift4
- Pattern matching4
- Fast, Concurrent with clean error messages4
- Error isolation2
- Dynamic Typing1
- Fewer jobs for Elixir experts11
- Smaller userbase than other mainstream languages7
- Elixir's dot notation less readable ("object": 1st arg)5
- Dynamic typing3
- Not a lot of learning books available1
related Elixir posts
Another major decision was to adopt Elixir and Phoenix Framework - the DX (Developer eXperience) is pretty similar to what we know from RoR, but this tech is running on the top of rock-solid Erlang platform which is powering planet-scale telecom solutions for 20+ years. So we're getting pretty much the best from both worlds: minimum friction & smart conventions that eliminate the excessive boilerplate AND highly concurrent EVM (Erlang's Virtual Machine) that makes all the scalability problems vanish. The transition was very smooth - none of Ruby developers we had decided to leave because of Elixir. What is more, we kept recruiting Ruby developers w/o any requirement regarding Elixir proficiency & we still were able to educate them internally in almost no time. Obviously Elixir comes with some more tools in the stack: Credo , Hex , AppSignal (required to properly monitor BEAM apps).
- Can be used on frontend/backend1.6K
- It's everywhere1.5K
- Lots of great frameworks1.1K
- Light weight733
- You can't get a device today that doesn't run js378
- Non-blocking i/o280
- Extended functionality to web pages49
- Relatively easy language42
- Executed on the client side40
- Relatively fast to the end user24
- Functional programming15
- Setup is easy7
- Because I love functions6
- Like it or not, JS is part of the web standard5
- Future Language of The Web5
- Can be used in backend, frontend and DB5
- Its everywhere5
- Expansive community5
- Everyone use it4
- Supports lambdas and closures4
- Love-hate relationship4
- Popularized Class-Less Architecture & Lambdas4
- Evolution of C4
- For the good parts4
- Easy to hire developers4
- Only Programming language on browser3
- Easy to make something3
- Promise relationship3
- Scope manipulation3
- Hard not to use3
- Client processing3
- Client side JS uses the visitors CPU to save Server Res3
- Stockholm Syndrome3
- Can be used both as frontend and backend as well3
- Most Popular Language in the World3
- No need to use PHP3
- Photoshop has 3 JS runtimes built in3
- Function expressions are useful for callbacks3
- Can be used on frontend/backend/Mobile/create PRO Ui3
- Because it is so simple and lightweight3
- Its fun and fast3
- It let's me use Babel & Typescript3
- What to add3
- 1.6K Can be used on frontend/backend3
- It's fun3
- Agile, packages simple to use3
- Acoperișul 07576043351
- A constant moving target, too much churn21
- Horribly inconsistent20
- No ability to monitor memory utilitization8
- Shows Zero output in case of ANY error6
- Can be ugly5
- Thinks strange results are better than errors4
- No GitHub2
But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.
But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.
How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve: