It's funny, I don't believe Elm itself needs much (if any) modification- the language is in a great spot, as are the core libs. I
f you care about it winning the "language wars", it needs more PR, examples, success stories, and tutorials. Here, I'm happy to have contributed in some way(s).
I have to disagree. Elm especially needs to be updated. That’s because Elm limits your interactions with browser. You can’t use browser APIs in Elm. (We can nitpick that ports and web components are some form of an escape hatch)
Internationalization API is a great example. We should leverage the platform but we can’t.
From my brief experience of trying to move onto 0.19, it broke the few project I had running on elm and the path forward wasn't very straightforward. JS interop and dealing with json are both still tedious and awful. I really want to want to use elm, but I'm not sure I can justify putting in the time.
JS interop via webcomponents is "the way" (vs ports). Re JSON decoding, agreed, and we cover in the episode: it's a solved/solvable problem that isn't popularized via a nice package...yet. But I think you've zero'd in on the pragmatic pain points; webcomponents is the revelation that was missing in the communication on the migration from 18 to 19, unfortunately.
I use web components as a workaround for elm being anti-component. It's infuriating. It makes me write JS instead of elm and obviously that causes lots of problems. The elm testing framework makes testing web components impossible too.
Elm has tons of low hanging fruit still. Evan just chooses to ignore them and look down his nose at any use case that doesn't work in elm currently.
Speaking on the VC side, some the crunch premise is flawed. The crunch is due to a huge explosion of early stage companies (easier than ever to get seeded, less capital than ever needed to get started) w/o a corresponding explosion of A-level capital.
There is no formula for unicorns, I'd dismiss that outright, and even if we found one, every founder would bend their story to adapt superficially, and the forumla would prove useless.
My #1 theory on why people w/ a somewhat logical strategy/thesis fail to raise? Failure to tell a compelling, coherent story about their opportunity, and failure to come across as a compelling "force of nature" founding team.
i partially agree with your point on an explosion in early stage companies. however, i think part of this explosion in seed stage companies is because companies are now raising 2-3 seed rounds and jumping straight to A rounds which in effect is the old "B round." i think part of this behaviour is driven by investors dis-interest in A rounds so entrepreneurs try to be "seed stage" as long as possible until then can raise 10 million dollar A rounds which is really a b round.
I do think the question of price discrimination is a really interesting one. Why hasn't anyone been successful suing for that? Why is Tinder being so obvious about it, do their lawyers no something we don't, or are they just that much more risk tolerant?
Movie theaters, theme parks, etc have all been using price discrimination based on age for years and never been prosecuted. I don't think Tinder's lawyers are afraid. They know it will cost a bit of bad press initially, but long term has little risk.
Hopefully some folks have heard of Boundless now, we make free e-textbooks out of open-source / public domain content and are now used by students at half of all universities.
We have a program to help educators quickly get up to speed using our content with minimal effort
It's rough. I hope there are open competitors that gain traction and are worth relocating to in the future. But for now I still like the platform over forced bidirectional communication platforms like Facebook. At the very least it's for fun, while it lasts.
Your opening digression is a bit harsh. We're all experienced web-devs, with the accumulated knowledge of building websites that have reached in excess of several hundred million individuals.
SEO - True. There are many different strategies to deliver solid SEO results using technologies like Spar. You can use headless browsers to pre-render and deliver on-demand rendered content, if you know your URL space completely, you can pre-render all documents. Spar isn't an attempt to solve SEO for you, you may not even care if you are building a phone-gap app, for instance. So does that invalidate the technology?
Accessibility: I'm 100% behind accessibility, and if the compatible tricks don't work... do you still make your site accessible for IE3? No... screen- readers MUST catch up. We can all do what we can to help, but shouldn't engineer for the past, which is an orthogonal concern from accessibile technology choices.
Page-performance - I'll challenge the several orders of magnitude claim, we've seen incredible performance w/ the approach, and best-case you're only talking about first-page speed, even ceding that it becomes a much different story later on... and if you're building an 'app' thats a big difference.
I apologize that it came off as harsh; it is good, technically, but I also think it's very important to stress what something like this can't do. There's a big mentality right now that "single page apps" are the hotness - and they ARE - if done right.
> do you still make your site accessible for IE3? No...
I subscribe to the ideas behind progressive enhancement, so I don't have to make that choice. An application can be built that works everywhere, for every technology, with little development overhead (and in my experience, the lowest-experience-first PE approach generally leads to better code anyway.) This isn't just theory - I've done it with apps large and small, and it works. I highly suggest http://filamentgroup.com/dwpe/ to find out more.
> best-case you're only talking about first-page speed
I'd also argue that that's what matters most to visitors - numerous studies show that there's a dropoff as that first page takes longer to load. Here we have the difference between loading a page, being useful, and then loading scripts vs loading an (empty, so faster) page, load libraries, load templates, then load data, then push the template to the screen. Additionally, if you're doing server rendering, you can probably cache that first hit at the web server level and avoid even hitting the web application at all.
The difference won't matter if you have a tiny app, so you don't have much js to download - but it will make a big difference if you have anything reasonably-sized.
Spar itself requires no knowledge of Ruby, that was one of the design goals. It happens to use Ruby tech under-the-hood, but no user of Spar would ever be exposed to those choices.
