7 ms·

Interesting breakdown of some pros and cons of using Elm in production. However, it appears the JavaScript codebase they used for comparison was quite bad and m

Interesting breakdown of some pros and cons of using Elm in production. However, it appears the JavaScript codebase they used for comparison was quite bad and maybe not representative of a good or even typical JavaScript app: > Our JavaScript application had global variables everywhere, and debugging was a nightmare Point #3 in their list of cons is especially important for anyone considering Elm: > Because Elm is not a mainstream language, it is sometimes necessary to reinvent something that could otherwise have been acquired by adopting a different technology. This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. This attracts a lot of developers who enjoy working on libraries and tooling, but it’s not ideal if you’re trying to run a lean team that ships products quickly. Elm is fun, but I wouldn’t use it unless I could afford to hire a relatively huge team to absorb all of the additional complexity and detours that go into building an Elm app. There’s a constant promise of Elm being faster and easier to write for various reasons, but in practice it always seems to get bogged down in endless gotchas and framework shortcomings that need to be addressed before we can get down to getting real work done.

dimitrios1 5y ago
> but it’s not ideal if you’re trying to run a lean team that ships products quickly. Good. The longer I do this, the longer I realize that unless your in a race-to-the-bottom industry (something like vying for eye balls to increase ad spend), then this is categorically a bad thing. I would prefer the quality of engineering required in knowing how to do some of these things yourselves. Take your time. Understand what you are doing. Some of the world class technologies we all know and use daily use minimal dependencies. And with more malicious code entering more package repositories, it might be apt advice more than ever today.
- deleted 5y ago
  [deleted]
- pjlegato 5y ago
  Quality engineering must always be balanced against the reality of finite budgets. Sure, lots of amazing engineering can be achieved in theory, _given infinite funding_. That never happens in the real world. One always has limited time to produce a viable product. There is always some extrinsic constraint to how much time can be spent taking your time and understanding what you're doing. Moreover, if you are operating in any commercially viable product space, you're always competing against other firms for finite market share. If it takes x years to ponder and understand how to build and ship a masterful feat of engineering, while some other company ships a "sort-of-works" product with bugs and engineering flaws in <<< x years, the other company will usually win in the marketplace. Your company usually goes bankrupt, and all the engineers will complain at their next jobs about what a wonderfully designed engineering system they were building, and how awful it is that nobody appreciates such things these days.
  - Silhouette 5y ago
    This is the popular wisdom but I question how universally applicable it is. We all know that having the best technology doesn't necessarily mean you win in a commercial market and we all know that being first mover can be an advantage, but those observations don't tell us what will be successful in the long term. How often does substandard technology and technical debt become a drag on a business not long after that first move, allowing someone else to overtake because the poorly built system couldn't scale to production levels or wasn't adaptable enough for changing requirements or failed so often that the early users drifted away? How often do we see developers advocating shortcuts and showing limited understanding of basic software development or computer science ideas, only to see the product they work on being rewritten within a year or two, or the whole team shut down? You can try to be fastest always. You can often succeed, at first, if you take enough shortcuts. But you can't sustain that pace without enough quality in your people and your code. Planning to throw each implementation away and rewrite with more resources every year or two is a very unicorn-like strategy. It reminds me of VCs whose strategy is to invest liberally, who are fully aware that most of those investments won't work out but they're hoping for one or two in each batch to become the next big hits. Real engineering isn't done in a vacuum and its goal isn't perfection. Real engineering takes issues like costs and timescales and staffing into account and aims to find a solution that is good enough on all counts. But it still has to be good enough. Producing junk but quickly and cheaply is an effective strategy until it's not and the success of any product using that strategy comes down to little more than the luck of the draw.
- PragmaticPulp 5y ago
  > I would prefer the quality of engineering required in knowing how to do some of these things yourselves. Realistically, a couple of engineers writing a library from scratch isn’t going to be higher quality than adopting a mainstream, battle-tested library that accomplishes the same thing. Writing your own implementations of everything can be fun, but it’s not possible to compete with all of the iterations and reviews that a mainstream library collects over time.
  - Silhouette 5y ago
    Realistically, a couple of engineers writing a library from scratch isn’t going to be higher quality than adopting a mainstream, battle-tested library that accomplishes the same thing. That's true but the vast majority of what you find on NPM is not mainstream, battle-tested libraries. Libraries that do clear that bar tend to be widely useful but that suggests generality you won't necessarily need for any single use case. A couple of good engineers might struggle to beat a well-established open source library at everything it does, but that is rarely what they are trying to achieve. They just need something that is better for their own specific needs at that time, which might be a useful and realistic target.
  - dimitrios1 5y ago
    Once you detach from "I must use a library for every thing" land, you begin to realize you don't need the overwhelming majority of them. Which results in writing cleaner, simpler, more focused code, with less of a surface area for bugs. It's a whole mindset, tbh.
    - ModernMech 5y ago
      I appreciate libraries for: - ubiquitous things, like data structures - hard to get right things, like time - implementations of specs, like Unicode - hardware interfaces, like CUDA For everything else, I'll take the above and roll my own solution.
      - dimitrios1 5y ago
- mwcampbell 5y ago
  > Good. The longer I do this, the longer I realize that unless your in a race-to-the-bottom industry (something like vying for eye balls to increase ad spend), then this is categorically a bad thing. It's not that simple. I realize this may be uncommon, but it's possible to work on a product that is truly worthwhile, that improves peoples' lives, and whose target users urgently need a solution to the problem you're solving. I recently developed a product that I believe meets this description (I won't plug it here). I chose Elixir for the web application. While I think that's a defensible choice, given the real-time nature of the application, I sometimes wonder if I would have been better off choosing a more mainstream language -- one with an official Stripe client library, for one thing. Any day I spent unnecessarily reimplementing something because I chose Elixir is a day that the target users couldn't benefit from my product. And, bearing that in mind, I should get back to work.
  - aszen 5y ago
    In a more mainstream language, while it may have a few Stripe client libraries but if your true use case of being real time isn't full filled then it makes no sense to choose them. A working stripe client takes at most a day to write, compared to years that can go in changing the architecture of your application
    - WJW 5y ago
      If you have enough talent that a good quality Stripe integration takes only a day to write, bending Rails or Laravel to serve websockets is not going to take more than a few days to write either. The true pain of non-standard languages is not in having to implement any specific dependency yourself but in having to reimplement a few dozen trivial-but-not-easy things yourself. It's a death by a hundred small cuts.
      - aszen 5y ago
        On the one hand u r writing a wrapper over an already well specified rest api of stripe and on the other hand u need to modify a programming language runtime to be faster and reliable for real time operations. I'm not sure these tasks are really comparable in any way. Choosing non-popular languages is a trade off yes but not as much as people think especially if you have a good team willing to learn them. There are also benefits apart from technical ones like better job retention and attracting finer talent without having to filter hundreds of resumes. I will say if your business is made around hiring and making anyone work of the shelf then it's a bad idea.
theobeers 5y ago
From the opening section of the blog post, I wondered why an incremental move to TypeScript wouldn’t have worked for them. The rest seems to be all about Elm (I haven’t read it thoroughly), but I feel there’s a disconnect between the problem they started with and their choice to dive into a wholly new ecosystem. edit: Ah, hold on; I just got to where they comment on this. “TypeScript, which adds optional static typing to JavaScript and is probably one of the best things to happen to JavaScript, can partially mitigate the issues with the JavaScript dynamic type system. But being a superset of JavaScript it needs to compromise on elegance and simplicity. It also has several ‘blind spots.’” etc. I don’t know that I’m 100% convinced.
- cardanome 5y ago
  TypeScript has a slow compiler and horrendous error messages (especially compared to the Elm). Plus it is far away from the no runtime exception guarantees that Elm offers by design. Also TS is just part of a potential solution while Elm comes with all batteries included. You still have to set up your code formater, liner, decide on a framework, state management library and so on and so on. With Elm, you just use elm-format. No arguing about code style, not arguing about how structure your code. There is only way to do it. It is not only a language but a framework. You get everything you need out need out of the box.
  - toastal 5y ago
    Elm also has a sound type system and no side effects because it doesn't need to be compatible with vanilla JavaScript
  - leshow 5y ago
    If you use something like nextjs and strict compiler options for TS a lot of these concerns go away. > You get everything you need out need out of the box. This is specious. There's lots of comments about how you don't get everything out of the box and for the parts that are missing it's a pain. Perhaps your particular use cases are covered, that's great.
- wk_end 5y ago
aranchelk 5y ago
> This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. This is an important point; I think it applies to varying degrees to any less popular language or framework. It’s a little worse with Elm because of the restrictions they’ve placed on JS interop. I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work; you'll just encounter surprises during implementation along the lines of "wow I can't be believe they don't have a library for x." On the plus side, since the work of implementing these libraries is very generic with regard to any specific application, it's easy to delegate to other employees or contractors. I’m currently working on a large PureScript project. At various times I’ve had to implement my own base libraries and components, but in many cases I’ve just been able to wrap existing JavaScript code. Some of the key libraries I use, which were developed by other community members are wrapped JavaScript libraries. This has been a pretty powerful mitigation strategy. In the case of PureScript, I also have the benefit of reusing a substantial amount of front end code on the server. For me, on this particular project, the benefits of using a language with advanced features has far outweighed the above mentioned costs, but I think you've got to look at each situation differently and do that evaluation.
- Silhouette 5y ago
  I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work I think you've just defined a pretty good benchmark for when it's sensible to consider a less popular choice. Are you familiar enough with it to be confident of coming out ahead by using it? Perhaps you have a backup plan like the interop you mentioned if some functionality is missing. Perhaps the tool is so much more productive in general that you are reasonably confident any extra development work to fill in the gaps will be outweighed by the overall benefits. But there should be some clear reason you think the risk is justified.
- platz 5y ago
  curious if you using halogen or react-basic? I've gone with halogen for a small project and it's been fine but sometimes i wonder if react-basic is a better choice.
whateveracct 5y ago
A seasoned small Elm team will probably scale to higher complexity heights than a small JS team in my experience. Same goes for Haskell and the like. The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here. Most of the time I see it, it's people flipping out at the very sight of there not being something available off-the-shelf. The actual cost is much lower than the panic implies. In general, people see ANY time spent in an FP language to solve FP problems as "a waste of time" but they're blind to the wastes of time people treat as "real code" in mainstream languages. But yeah if you're a software efficiency bean counter, maybe you won't like FP. Fair point. My opinion is the long-term technical & cultural benefits and opportunities pay off. And as a developer, I am happy to not optimize my development velocity to the utmost if it means I don't have to waste my brainpower writing imperative code. My mind is in a much better state at the very least :)
- vlunkr 5y ago
  > The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here This isn't a good representation of the argument. People don't want to write libraries because it's more valuable for everyone to spend time writing features using existing libraries, provided there are good libraries available. People aren't "freaking out", they just have deadlines, and you know, other things to do with their lives besides write code that has already been written.
  - mst 5y ago
    I would imagine that it's a good representation of their experience of such things, but a poor representation of the experience of such things of the person they're replying to.
  - whateveracct 5y ago
    Nah it's a pretty good representation. And acting like time should 100% be spent writing features is shortsighted - sometimes it's worth it to pay fixed costs such as filling in a gap of the ecosystem of the language you chose for higher reasons than cranking out business code.
aszen 5y ago
Elm is build on top of solid foundations, and has a good standard library unlike js so it's much easier to reinvent things as you say. One of the core ways to ship products quickly is to ensure you don't break things often, and elm lets u do that provided one learns it well enough
lhorie 5y ago
> Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. I dunno, having seen both sides, there are pros and cons to each. Teams that reach for libs quickly often think in terms of libraries instead of solutions (one recent example was some folks who were asking for my advice on some over-engineered client-side PDF generation thing, and me suggesting `window.print()` as a solution, considering this was for an internal tool and you effectively want print stylesheets anyways), and often use them as crutches due to a self-fulfilling cycle of "I don't know how to do X, let's use a library so I never need to find out" (and then pulling in a huge lib to do the job of a literal one-liner regex - `uuid.validate()`, looking at you). In my experience, they also often end up buried by their own complexity due to gluing too many things together. But at the same time, it's hard to argue with the ease with which one can plop a modal dialog or a calendar or a collapsible table in a React app. I find that teams working with more exotic technologies tend to be more creative with solutions (e.g. "oh there's no zoomable map UI lib bindings, so let's ask ourselves, do we really need a map library for that contact us page or is a static jpg good enough?") and a have a deeper appreciation for how hard things are to implement. But conversely, UX can suffer from too much "creativity". For example, if care is not taken w/ accessibility concerns for some UI element. Or, as you said, things just take longer to ship because people need to reinvent wheels.
mjaniczek 5y ago
> Elm is fun, but I wouldn’t use it unless I could afford to hire a relatively huge team to absorb all of the additional complexity and detours that go into building an Elm app. There’s a constant promise of Elm being faster and easier to write for various reasons, but in practice it always seems to get bogged down in endless gotchas and framework shortcomings that need to be addressed before we can get down to getting real work done. Is this your experience writing Elm apps in production? I am writing large Elm apps in production and I'm having very different experience to what you just described.

dimitrios1 5y ago

> but it’s not ideal if you’re trying to run a lean team that ships products quickly. Good. The longer I do this, the longer I realize that unless your in a race-to-the-bottom industry (something like vying for eye balls to increase ad spend), then this is categorically a bad thing. I would prefer the quality of engineering required in knowing how to do some of these things yourselves. Take your time. Understand what you are doing. Some of the world class technologies we all know and use daily use minimal dependencies. And with more malicious code entering more package repositories, it might be apt advice more than ever today.

deleted 5y ago
[deleted]
pjlegato 5y ago
Quality engineering must always be balanced against the reality of finite budgets. Sure, lots of amazing engineering can be achieved in theory, _given infinite funding_. That never happens in the real world. One always has limited time to produce a viable product. There is always some extrinsic constraint to how much time can be spent taking your time and understanding what you're doing. Moreover, if you are operating in any commercially viable product space, you're always competing against other firms for finite market share. If it takes x years to ponder and understand how to build and ship a masterful feat of engineering, while some other company ships a "sort-of-works" product with bugs and engineering flaws in <<< x years, the other company will usually win in the marketplace. Your company usually goes bankrupt, and all the engineers will complain at their next jobs about what a wonderfully designed engineering system they were building, and how awful it is that nobody appreciates such things these days.
- Silhouette 5y ago
  This is the popular wisdom but I question how universally applicable it is. We all know that having the best technology doesn't necessarily mean you win in a commercial market and we all know that being first mover can be an advantage, but those observations don't tell us what will be successful in the long term. How often does substandard technology and technical debt become a drag on a business not long after that first move, allowing someone else to overtake because the poorly built system couldn't scale to production levels or wasn't adaptable enough for changing requirements or failed so often that the early users drifted away? How often do we see developers advocating shortcuts and showing limited understanding of basic software development or computer science ideas, only to see the product they work on being rewritten within a year or two, or the whole team shut down? You can try to be fastest always. You can often succeed, at first, if you take enough shortcuts. But you can't sustain that pace without enough quality in your people and your code. Planning to throw each implementation away and rewrite with more resources every year or two is a very unicorn-like strategy. It reminds me of VCs whose strategy is to invest liberally, who are fully aware that most of those investments won't work out but they're hoping for one or two in each batch to become the next big hits. Real engineering isn't done in a vacuum and its goal isn't perfection. Real engineering takes issues like costs and timescales and staffing into account and aims to find a solution that is good enough on all counts. But it still has to be good enough. Producing junk but quickly and cheaply is an effective strategy until it's not and the success of any product using that strategy comes down to little more than the luck of the draw.
PragmaticPulp 5y ago
> I would prefer the quality of engineering required in knowing how to do some of these things yourselves. Realistically, a couple of engineers writing a library from scratch isn’t going to be higher quality than adopting a mainstream, battle-tested library that accomplishes the same thing. Writing your own implementations of everything can be fun, but it’s not possible to compete with all of the iterations and reviews that a mainstream library collects over time.
- Silhouette 5y ago
  Realistically, a couple of engineers writing a library from scratch isn’t going to be higher quality than adopting a mainstream, battle-tested library that accomplishes the same thing. That's true but the vast majority of what you find on NPM is not mainstream, battle-tested libraries. Libraries that do clear that bar tend to be widely useful but that suggests generality you won't necessarily need for any single use case. A couple of good engineers might struggle to beat a well-established open source library at everything it does, but that is rarely what they are trying to achieve. They just need something that is better for their own specific needs at that time, which might be a useful and realistic target.
- dimitrios1 5y ago
  Once you detach from "I must use a library for every thing" land, you begin to realize you don't need the overwhelming majority of them. Which results in writing cleaner, simpler, more focused code, with less of a surface area for bugs. It's a whole mindset, tbh.
  - ModernMech 5y ago
    I appreciate libraries for: - ubiquitous things, like data structures - hard to get right things, like time - implementations of specs, like Unicode - hardware interfaces, like CUDA For everything else, I'll take the above and roll my own solution.
    - dimitrios1 5y ago
mwcampbell 5y ago
> Good. The longer I do this, the longer I realize that unless your in a race-to-the-bottom industry (something like vying for eye balls to increase ad spend), then this is categorically a bad thing. It's not that simple. I realize this may be uncommon, but it's possible to work on a product that is truly worthwhile, that improves peoples' lives, and whose target users urgently need a solution to the problem you're solving. I recently developed a product that I believe meets this description (I won't plug it here). I chose Elixir for the web application. While I think that's a defensible choice, given the real-time nature of the application, I sometimes wonder if I would have been better off choosing a more mainstream language -- one with an official Stripe client library, for one thing. Any day I spent unnecessarily reimplementing something because I chose Elixir is a day that the target users couldn't benefit from my product. And, bearing that in mind, I should get back to work.
- aszen 5y ago
  In a more mainstream language, while it may have a few Stripe client libraries but if your true use case of being real time isn't full filled then it makes no sense to choose them. A working stripe client takes at most a day to write, compared to years that can go in changing the architecture of your application
  - WJW 5y ago
    If you have enough talent that a good quality Stripe integration takes only a day to write, bending Rails or Laravel to serve websockets is not going to take more than a few days to write either. The true pain of non-standard languages is not in having to implement any specific dependency yourself but in having to reimplement a few dozen trivial-but-not-easy things yourself. It's a death by a hundred small cuts.
    - aszen 5y ago
      On the one hand u r writing a wrapper over an already well specified rest api of stripe and on the other hand u need to modify a programming language runtime to be faster and reliable for real time operations. I'm not sure these tasks are really comparable in any way. Choosing non-popular languages is a trade off yes but not as much as people think especially if you have a good team willing to learn them. There are also benefits apart from technical ones like better job retention and attracting finer talent without having to filter hundreds of resumes. I will say if your business is made around hiring and making anyone work of the shelf then it's a bad idea.

theobeers 5y ago

From the opening section of the blog post, I wondered why an incremental move to TypeScript wouldn’t have worked for them. The rest seems to be all about Elm (I haven’t read it thoroughly), but I feel there’s a disconnect between the problem they started with and their choice to dive into a wholly new ecosystem. edit: Ah, hold on; I just got to where they comment on this. “TypeScript, which adds optional static typing to JavaScript and is probably one of the best things to happen to JavaScript, can partially mitigate the issues with the JavaScript dynamic type system. But being a superset of JavaScript it needs to compromise on elegance and simplicity. It also has several ‘blind spots.’” etc. I don’t know that I’m 100% convinced.

cardanome 5y ago
TypeScript has a slow compiler and horrendous error messages (especially compared to the Elm). Plus it is far away from the no runtime exception guarantees that Elm offers by design. Also TS is just part of a potential solution while Elm comes with all batteries included. You still have to set up your code formater, liner, decide on a framework, state management library and so on and so on. With Elm, you just use elm-format. No arguing about code style, not arguing about how structure your code. There is only way to do it. It is not only a language but a framework. You get everything you need out need out of the box.
- toastal 5y ago
  Elm also has a sound type system and no side effects because it doesn't need to be compatible with vanilla JavaScript
- leshow 5y ago
  If you use something like nextjs and strict compiler options for TS a lot of these concerns go away. > You get everything you need out need out of the box. This is specious. There's lots of comments about how you don't get everything out of the box and for the parts that are missing it's a pain. Perhaps your particular use cases are covered, that's great.
wk_end 5y ago

aranchelk 5y ago

> This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. This is an important point; I think it applies to varying degrees to any less popular language or framework. It’s a little worse with Elm because of the restrictions they’ve placed on JS interop. I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work; you'll just encounter surprises during implementation along the lines of "wow I can't be believe they don't have a library for x." On the plus side, since the work of implementing these libraries is very generic with regard to any specific application, it's easy to delegate to other employees or contractors. I’m currently working on a large PureScript project. At various times I’ve had to implement my own base libraries and components, but in many cases I’ve just been able to wrap existing JavaScript code. Some of the key libraries I use, which were developed by other community members are wrapped JavaScript libraries. This has been a pretty powerful mitigation strategy. In the case of PureScript, I also have the benefit of reusing a substantial amount of front end code on the server. For me, on this particular project, the benefits of using a language with advanced features has far outweighed the above mentioned costs, but I think you've got to look at each situation differently and do that evaluation.

Silhouette 5y ago
I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work I think you've just defined a pretty good benchmark for when it's sensible to consider a less popular choice. Are you familiar enough with it to be confident of coming out ahead by using it? Perhaps you have a backup plan like the interop you mentioned if some functionality is missing. Perhaps the tool is so much more productive in general that you are reasonably confident any extra development work to fill in the gaps will be outweighed by the overall benefits. But there should be some clear reason you think the risk is justified.
platz 5y ago
curious if you using halogen or react-basic? I've gone with halogen for a small project and it's been fine but sometimes i wonder if react-basic is a better choice.

whateveracct 5y ago

A seasoned small Elm team will probably scale to higher complexity heights than a small JS team in my experience. Same goes for Haskell and the like. The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here. Most of the time I see it, it's people flipping out at the very sight of there not being something available off-the-shelf. The actual cost is much lower than the panic implies. In general, people see ANY time spent in an FP language to solve FP problems as "a waste of time" but they're blind to the wastes of time people treat as "real code" in mainstream languages. But yeah if you're a software efficiency bean counter, maybe you won't like FP. Fair point. My opinion is the long-term technical & cultural benefits and opportunities pay off. And as a developer, I am happy to not optimize my development velocity to the utmost if it means I don't have to waste my brainpower writing imperative code. My mind is in a much better state at the very least :)

vlunkr 5y ago
> The freaking out about "oh no I gotta write a small library myself" is absurdly overblown here This isn't a good representation of the argument. People don't want to write libraries because it's more valuable for everyone to spend time writing features using existing libraries, provided there are good libraries available. People aren't "freaking out", they just have deadlines, and you know, other things to do with their lives besides write code that has already been written.
- mst 5y ago
  I would imagine that it's a good representation of their experience of such things, but a poor representation of the experience of such things of the person they're replying to.
- whateveracct 5y ago
  Nah it's a pretty good representation. And acting like time should 100% be spent writing features is shortsighted - sometimes it's worth it to pay fixed costs such as filling in a gap of the ecosystem of the language you chose for higher reasons than cranking out business code.

aszen 5y ago

Elm is build on top of solid foundations, and has a good standard library unlike js so it's much easier to reinvent things as you say. One of the core ways to ship products quickly is to ensure you don't break things often, and elm lets u do that provided one learns it well enough

lhorie 5y ago

> Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. I dunno, having seen both sides, there are pros and cons to each. Teams that reach for libs quickly often think in terms of libraries instead of solutions (one recent example was some folks who were asking for my advice on some over-engineered client-side PDF generation thing, and me suggesting `window.print()` as a solution, considering this was for an internal tool and you effectively want print stylesheets anyways), and often use them as crutches due to a self-fulfilling cycle of "I don't know how to do X, let's use a library so I never need to find out" (and then pulling in a huge lib to do the job of a literal one-liner regex - `uuid.validate()`, looking at you). In my experience, they also often end up buried by their own complexity due to gluing too many things together. But at the same time, it's hard to argue with the ease with which one can plop a modal dialog or a calendar or a collapsible table in a React app. I find that teams working with more exotic technologies tend to be more creative with solutions (e.g. "oh there's no zoomable map UI lib bindings, so let's ask ourselves, do we really need a map library for that contact us page or is a static jpg good enough?") and a have a deeper appreciation for how hard things are to implement. But conversely, UX can suffer from too much "creativity". For example, if care is not taken w/ accessibility concerns for some UI element. Or, as you said, things just take longer to ship because people need to reinvent wheels.

mjaniczek 5y ago

> Elm is fun, but I wouldn’t use it unless I could afford to hire a relatively huge team to absorb all of the additional complexity and detours that go into building an Elm app. There’s a constant promise of Elm being faster and easier to write for various reasons, but in practice it always seems to get bogged down in endless gotchas and framework shortcomings that need to be addressed before we can get down to getting real work done. Is this your experience writing Elm apps in production? I am writing large Elm apps in production and I'm having very different experience to what you just described.