1. 6

    Where does it say that a version change means no bugs? Maybe I’m wrong but I’ve always understood SemVer to be a means of communicating the scope of changes. A patch change means I shouldn’t have to change anything, minor means I can access new features, and major means I may have to change my code. Nothing there says anything about lack of bugs though.

    I’ve also come to believe less and less in placing 1.0 on a pedestal. So many companies and devs use 0.x software that the idea of 1.0 == production is just a silly things we tell ourselves to feel cozy. Many popular tools either stay at 0.x for years while being used in production and others hit 1.0 then 2.0, 3.0, etc all in quick succession making the idea of 1.0 meaning stability just a joke.

    1. 8

      Ehm, you have just somewhat summed up parts of the article making it sound like you’re contradicting. What did you think it was trying to say? 😅

    1. 4

      I took a stab at writing a toy concatenative language. Had a lot of fun learning along the way. https://github.com/wolfadex/bex

      1. 2

        It’s interesting because I often try to sell others on using vanilla web components when possible and if you need a larger tool to guide your data and organize things I suggest Elm. Both because they’re slow to change, so if the same code I was writing 3+ years ago is still the same I’m writing today, they’re focused, and they’re small. React, Vie, Ember, Angular, etc are all changing frequently. Some as often as every 6 months. I know entire teams that can’t keep up with a 6 month release frequency! How is an individual supposed?

        1. 4

          The two with which I identify are:

          Pencil and paper are the best programming tools and vastly under used

          An IDE is for when you are dead-certain about what to do. Design reviews are as-important as code-reviews, and design reviews are best conducted with pencil and paper.

          Typed languages are better when you’re working on a team of people with various experience levels

          In the vernacular, types are a common language that improves communication

          The one I slightly disagree with is:

          People who stress over code style, linting rules, or other minutia are insane weirdos

          Those beautifiers make it easier to do diffs; if you consistently use specific beautifiers, code reviews are easier.

          1. 1

            Those beautifiers make it easier to do diffs; if you consistently use specific beautifiers, code reviews are easier.

            This is a problem with diffs though, not with code or its formatting.

            1. 1

              My interpretation of the formatting/linting was more about those who nitpick over things like 2 spaces, 4 spaces, or tabs. For example the code styling story is vastly different in say JS vs Elm. There are many beautifiers and linters in JS and the style always slightly changes when you move between teams or companies. I’ve even been on teams in the past 2 years that don’t use any because they don’t like them. On the opposite end you get a language like Elm where there’s 1 community formatter that doesn’t even have a config. This means that 99% of all Elm code is formatted identically.

              1. 3

                The Elm solution to this problem is just so much better. Just get something decent looking and consistent and shut down all the arguing.

                Even if you’re someone who thinks formatting and consistency don’t matter, there will always be plenty of people to whom it does, and the only way to avoid wasted time and arguments is an auto-formatter.

                1. 2

                  Copy that. We just try to ‘formalize’ a specific beautifier (for specific code sets) and its values and say: that’s it! Do what you want but bring it formatted to team meetings (a form of “dress code”). Diffs are where arguments start, and common beautifiers make diff analyses easier IOE.

              1. 3

                Typed languages are better when you’re working on a team of people with various experience levels

                Funnily enough, the opposite is true for me. I used to be strongly in favor of typed languages, but now I simply don’t care that much. I’d say that I have less trouble navigating the project I’m currently working on (Ruby on Rails) than I had navigating previous projects written in C# and/or Java. In the end, I guess it all depends on many other factors, not just the language itself.

                1. 8

                  Having recently (past year) learned Rails as well as Haskell I’ve found that the style of types and amount of enforced structure is a significant factor. The type systems of Haskell, Elm, etc help me a lot more than those of C# or Java. Lack of types in Rails isn’t as much of an issue because everyone writes roughly the same way. So without an expressive type system like Elm then I’d argue you need a very rigid structure like Rails.

                  1. 2

                    My view on typed languages has both changed a lot and stayed exactly the same. I’ve always thought that most of the interesting properties that I care about and don’t want people to get wrong are not ones that type systems typically express. I’ve more recently learned about some type systems that can express those properties in a useable way, so now I’m massively in favour of strong type systems, just not the ones that most languages have.

                    1. 1

                      For me it kind of depends on how much turnover your team has and how much of your time is dedicated to teaching a code base or an entire language, for that matter. Sometimes newbies are competent in a codebase relatively fast, others can make dangerous mistakes without the “training wheels” typed languages tend to provide.

                      1. 4

                        I find no interesting codebase is small enough for all that bollocks to stay in my head, why on earth should it when we can make the computers remember it all for us?

                        1. 1

                          I’m not talking about memorizing a code base. I’m talking about teaching new teammates about an enterprise code base. I think knowing at least a portion of how things work is necessary before making a change. Sometimes new teammates don’t even know the language that a code base was written in, so you need to teach them about the language itself.

                          1. 2

                            Yikes, I’ve never been there thankfully.

                    1. 1

                      Thank you for this. It’s nice to see support for mixing langauges and using small languages.

                      1. 10

                        I was expecting a little more than “it doesn’t use semantic html” to qualify it as a “Fractal of Bad Design.” I get that that’s not good, but this article hasn’t really convinced me that i shouldn’t use Flutter Web, just given me a reason to be somewhat more wary of it than I would be otherwise.

                        1. 10

                          I agree. I think this is major flaw, and I think it’s suspicious that google has put out a major tool that essentially breaks automation.

                          But ‘fractal of bad design’ implies significant and unique design mistakes that culminate into something much more serious, across a multitude of surfaces.

                          And and top of that, the conclusion of

                          Flutter is a misguided attempt to achieve the impossible: quality cross platform experiences

                          Is I think a little hyperbolic, especially when the article doesn’t tackle any topic related to cross platform considerations at all.

                          Classic clickbait, but that shouldn’t take away from the concerns illustrated

                          1. 10

                            If accessibility isn’t a good enough reason then what is?

                            1. 5

                              It depends on the circumstances - difference circumstances have different requirement - sometimes I’m making a tool just for myself, so I don’t care that screen readers or userstyles don’t work. Also, the article doesn’t mention it, but Flutter does seems to care at least somewhat about accessibility, and Flutter Web is still in beta, so it seems quite possible that this will improve in the future. I’m not sure what the roadmap looks like (since I’ve never used flutter), but it seems likely that accessibility will improve in the future. Flutter also seems pretty open about the limitations of Flutter Web:

                              Not every HTML scenario is ideally suited for Flutter at this time. For example, text-rich flow-based content such as blog articles benefit from the document-centric model that the web is built around, rather than the app-centric services that a UI framework like Flutter can deliver. However, you can use Flutter to embed interactive experiences into these websites.

                              1. 1

                                What I was expecting was a more in-depth report based on experience, rather than a “I looked at it for a few minutes and here are my first impressions”, which is what this post seems to be.

                                It’s almost unimaginable to release something like this in 2020 and not have a11y support, so I did a quick search and it seems like accessibility is possible with flutter. I don’t know how well that works in practice (I never even heard of “Flutter” before I read this post) and it’s entirely possible that it’s really bad, but it’s not even mentioned in this post which leaves me with the impression that the author doesn’t know either.

                            1. 3

                              It will be interesting to see what other languages are influenced by Elm over the next decade or so. It’s already influenced both Rust and Reason error messages.

                              1. 2

                                This series is off to a good start. I’m interested to follow it… most Build Your Own Lisp type projects use a virtual machine instead of compiling down to native code.

                                1. 2

                                  I wrote a series last year on compiling a lisp to amd64 assembly in JavaScript. Unlike this series mine is on AOT, not JIT compilation. In the series I explored simple register-based usage of amd64, LLVM, and ultimately another variant of amd64 using it more solely as a stack machine.

                                  You may be interested: https://notes.eatonphil.com/compiler-basics-lisp-to-assembly.html

                                  1. 2

                                    Thanks for this! I’ll definitely be reading this later today.

                                    1. 1

                                      Indeed I am interested. Thank you, will look at your series too.

                                      1. 1

                                        I think we solved basically the same problem except that you are using an external assembler and linker to generate the ELF file for you.

                                        1. 1

                                          Well fundamentally I’m not JIT compiling (writing and executing memory in the same process) but yeah other than that the two are similar.

                                          1. 1

                                            Oh, I think there’s our linguistic difference. I draw the line in a different place:

                                            AOT: Compile the whole program to the target architecture. May or may not include disk I/O.

                                            JIT: Compile the pieces you need, when you need them, and probably have some kind of inline caching and inlining.

                                      2. 1

                                        Where do you get all these Lisps with VMs? I seem to find only tree-walking interpreters.

                                        1. 2

                                          Lisp in Small Pieces was the one I had greatest hopes for.

                                          1. 1

                                            The Lisp System Implementation book similarly targets a vm.

                                      1. 7

                                        Interesting that they use JavaScript as an example of a good dev environment. As someone who’s been working in web for over 8 years and did some C, Java, and C# before that, I find it frustrating. Comparing my experience building web apps with React, Ember, Angular, ExtJS, and more to Elm and it’s like living in 2 vastly different worlds. The former means that I often don’t know about bugs or general issues until I run my code in the browser. It feels like knitting a sweater in the dark and only knowing if it works by trying it on. Conversely, Elm gives me immediate feedback. I don’t think everyone should write Elm, but its programming environment is vastly better than all of the JS tooling I’ve tried. Apso better than most back end languages I know/use.

                                        1. 14

                                          I guess this is a little off topic, but creating a browser engine is so difficult, I wonder if anybody has considered creating Markdown browsers and communities around them?

                                          The key ideas would be:

                                          • Serve markdown (maybe an extended version) over HTTPS
                                          • Reuse existing server infrastructure
                                          • Only text, images, video, and audio - no client scripting
                                          • Leave all rendering decisions to the browser
                                          • Participating sites would (ideally) only link to other markdown sites

                                          The HTML and Javascript web seems to get more and more like TV every day, with less user control and more centralized/corporate control. A new browser engine might help, but it feels like it’s beyond saving at this point.

                                          1. 25


                                            Gemini is a new, collaboratively designed internet protocol, which explores the space inbetween gopher and the web, striving to address (perceived) limitations of one while avoiding the (undeniable) pitfalls of the other.

                                            While not a browser per say, this is similar in spirit to your markdown browser idea.

                                            1. 12

                                              Leave all rendering decisions to the browser

                                              I’m torn on this. I don’t really care for the CSS or layout for random news sites, but at the same time I really like the distinctive and wacky styles I see on people’s personal sites. Removing that element of individuality would, IMO, make the web more corporate.

                                              1. 6

                                                Sounds kind of like the existing Gopherverse, sans HTTPS.

                                                1. 5

                                                  Reminds me a bit of this post calling for a “Khyber Pass Browser”. I saw it in another forum, so I’ll paste my comments here as they also apply to your idea, and I’m intrigued by the design space and problem of staying simple:

                                                  What are your use cases or goals? I ask because I am ancient, and this sounds like a design doc for Mosaic 1.0, down to opening an external application to deal with those newfangled jpegs.

                                                  Depending on those high-level questions, maybe you want to lean way, way more into unix and do the most extreme version of “defer any content-specific rendering to user-specified helper programs” and like make a FUSE filesystem for browsing IPFS/DataShards or similar? Then you don’t even have to define a document format and write a renderer. (But more likely there’s some context/assumptions I’m missing.)

                                                  [discussion turned to the “should be implementable by a motivated undergad in a year of free time” heading]

                                                  I think an undergrad with a high-level binding like fusepy could bang out an integration pretty quickly. But I’m not married to the idea, I was throwing it out there to try to figure out what’s important to you in this project, same with the use case/goals question. Is it networking? Is it a new document markup? Is it use of mimetypes?

                                                  A point I meant to make with the comparison: Mosaic was an undergrad project and thirty years later, here we are with browsers that have 10x more code than the OS it ran on. What about this project keeps it from growing? How would you allow it to change and adapt, but not grow? That’s a really fascinating problem; how do you repeal Zawinski’s Law? Is there something in your design space that you think will help a KBP become a living fossil?

                                                    1. 1

                                                      I could see myself using that, though I assume it’s going to mostly for personal websites, so one will still need an extra conventional browsers.

                                                      Really interesting idea

                                                    1. 7

                                                      Someone suggests that maybe we could be more empathetic and half of the responses are anti-empathy. Typical “tech-bros” responses. E.g. @cdo “mollycoddling”, @mrr “[..] I don’t think there’s any value [..]”, @gerikson “I don’t find the example very enlightening.”, @icy “Not everyone has the time to construct a response like in your example. Besides, there was nothing hostile in the first answer either.”, @LibertarianLlama “[..] I’m not sure why. [..] You either have it, or you don’t.”, @jackdk “Devin has not done any due diligence”.

                                                      This isn’t about saying you’re wrong, it’s about saying “we” can do better. Instead of saying the authoring is wrong, maybe we need to reflect on ourselves a little more. Why is our industry overwhelmingly white? Why is our industry overwhelmingly male? Maybe this has something to do with it?

                                                      Sorry if this comes off as a little rant-y but it’s incredibly frustrating to have someone ask for things to be a little friendlier and half of the response be basically “no”. There’s plenty of evidence that our culture has issues: https://rework.withgoogle.com/blog/change-culture-not-curriculum-for-women-in-cs/ and https://www.youtube.com/watch?v=g1ib43q3uXQ as just a couple examples.

                                                      1. 4

                                                        Someone suggests that maybe we could be more empathetic and half of the responses are anti-empathy.

                                                        I don’t think anyone is being ‘anti-empathy’, we just disagree with what you mean by ‘empathy’. I specifically said in my comment (that you shortened down from eight deeply personal paragraphs about my own experiences and views on a culturally variable issue to a sentence fragment):

                                                        The former doesn’t convey any additional sense of empathy to me. It’s just less formal.

                                                        It was right after the bit you quoted from my comment as well, so I doubt you missed it - unless you only read far enough until you found a sentence fragment your internal LR parser reduces to something you find objectionable and early-exited.

                                                        I’m really unsure how you got ‘anti-empathy’ from ‘this doesn’t convey any additional sense of empathy to me’. Maybe I’ll rephrase it: being more informal doesn’t make you more empathetic at all, in my opinion. Chattiness doesn’t make you seem more empathetic. Corporate chatbots and customer service drones are super chatty ‘Hey how are you? Are you having a nice day? What can I do for you? Well if you want to solve that problem I think the best way to do it is …’. They’re not empathetic, quite the opposite. They really do not give one tiddlywink about you or the problems you’re having and I hope no-one is fooled into thinking they do.

                                                        This isn’t about saying you’re wrong, it’s about saying “we” can do better. Instead of saying the authoring is wrong, maybe we need to reflect on ourselves a little more.

                                                        Or perhaps the author needs to reflect on themselves a little more and think about the fact that not everyone comes from the same cultural background as them? Maybe you need to think for a little and realise that you can’t expect the world to change to suit you. If you can’t handle someone saying ‘Upgrade your Ruby version’ as a free response to your unsolicited support request, then you need to seriously re-evaluate your sense of entitlement, in my opinion.

                                                        If you want to pay someone to give you flowery, fake friendliness on top of their paid technical support, then go right ahead, but acting like you’re entitled to it free-of-charge from every free software maintainer or developer on GitHub is incredibly arrogant, IMO.

                                                        Why is our industry overwhelmingly white? Why is our industry overwhelmingly male? Maybe this has something to do with it?

                                                        Why would this have anything to do with the whiteness of the American software industry? In my (admittedly small) experience interacting with Americans both here and in the United States, the black Americans I encountered were significantly more direct than the white Americans. And that’s backed up by my general perception around American racial stereotypes of black people ‘saying it like it is’ etc.

                                                        If anything the American software industry is probably excluding black people by expecting this kind of white middle class cultural norm.

                                                        And looking at the stats, the software industry isn’t overwhelmingly white either, there are huge numbers of software developers of Asian descent in the US, both American-born and immigrants. I’d hazard to say there are bigger cultural differences between the US and China, India, Korea or Japan than there are between black and white Americans.

                                                        Sorry if this comes off as a little rant-y but it’s incredibly frustrating to have someone ask for things to be a little friendlier and half of the response be basically “no”.

                                                        But that’s the thing, it’s not just asking for things to be ‘a little friendlier’, is it? It’s asking people to use the language and norms of American customer service staff when talking to people on issue trackers. It’s really not about empathy.

                                                        If the author had some empathy they’d think about what it’s like to help people for free and then be told you’re not being friendly enough. If someone told me that I should use this kind of fake friendliness after I’d helped them by telling them how to fix their problem, I’d tell them to piss off and not expect any free help from me ever again.

                                                        1. 2

                                                          I apologize, I should not have included you in that list. I had read though your response initially but was only skimming when going back through for a second read.

                                                          whiteness of the American software industry

                                                          From my experience in the American software industry, it is overwhelmingly white and male. Across the very large and very small companies I’ve worked at as well as my college courses at both university and community college I have only occasionally had non-white, non-American, or non-male peers. The more coastal the company, the more diverse it’s gotten but only marginally so.

                                                          it’s not just asking for things to be ‘a little friendlier’, is it?

                                                          I agree that empathy can look different across different cultures. I don’t think the author is saying that everyone should adhere to specific language, but in the context of an example some language has to be chosen and that example won’t fit every culture. I don’t think giving a terse response should responded to with claiming you’re un-empathetic, but the idea that “it’s free feedback so I can say it however I want” does come off as harsh, irrespective of it’s terseness.

                                                          Having traveled a decent amount around the world and around the US, I don’t think the length of a response denotes empathy. E.g. in the midwest US, people have a way of giving long winded responses that basically boil down to belittling the person while sounding somewhat polite. All the people I’ve met from Oakland, CA tend to be very blunt, which many interpret as rude. @cdo’s response “mollycoddling” in comparison to yours is a perfect example of it not being about length but content.

                                                        2. 4

                                                          I should have been clearer in my comment - my point was that without more context, it was hard for me to determine if the perceived lack of empathy in the initial exchange was a bad thing.

                                                          • between two peers with a shared work history - normal
                                                          • between a person new to the organization and a mentor figure - lacking empathy if it was the first exchange, normal in a longer conversation
                                                          • in a dedicated help channel on IRC - normal

                                                          Etc, etc.

                                                          I don’t think the point about being empathetic is a bad one, only that the chosen example ironically required empathy for the author’s point of view.

                                                        1. 4

                                                          Generally speaking I agree with the sentiment. The react world is specially driven by this hype mentality. I started using React in 2015 but been following it since it was publicly released in 2013 I believe. I’ve seen a number of major changes in its methodology. From createElement to JSX to classes to hooks… In truth it feels like they are still figuring it out.

                                                          But sometimes it pays off to try something new. After a couple of years of mainly using React and Vue I tried Svelte and it is a game changer. I don’t say this lightly, I’ve been in web dev since the late 90s.

                                                          Svelte is very pragmatic so it optimizes for 90% of the use cases and IMO solves it better than the others, but what’s really revolutionary is the compiler approach. A priori it seems like it’s just some syntax thing like JSX, SCSS, or Vue single file components but it’s not. The Svelte compiler is actually analyzing your code and creating dependency graphs to output the most optimized and efficient version of your components in almost pure vanilla js. There is no runtime.

                                                          1. 3

                                                            Svelte is a super-exciting development, for sure, but my spider senses are tingling about its maturity. I’d gladly use it on smaller / personal projects, but since it’s closer to the all-encompassing end of the dependency spectrum, I wouldn’t go all-in on it for a huge project just yet. (YMMV)

                                                            1. 1

                                                              Same feeling here. I tried it for a small side project. There’s definitely way more documentation, support, and third-party code available for React. Svelte was way faster though, definitely seems promising.

                                                              1. 1

                                                                Yeah if you want a rich ecosystem then definitely Svelte is a bad choice, at least today.

                                                              2. 1

                                                                As someone who’s only barely used Svelte, what do people mean when they say Svelte has “no runtime”? As far as I can tell, there’s still code executing in the browser that decides what to show, when to show it, and how to display it. Sometimes that’s JS, but from what I can tell it’s not substantially different from Vue, React, or any other web tool. In some ways it’s more like Elm or ReactReason in that it’s a language that compiles to browser native languages, but there’s still code that’s executing at runtime.

                                                                1. 3

                                                                  Rather than relying on a runtime library — where your code calls methods from a library — Svelte will “compile” (if you will) to code that uses native DOM methods directly. I haven’t used Elm but that sounds like a fair comparison. However, I think Svelte is substantially different from Vue and React; virtual DOM is pure overhead says the main Svelte author, Rich Harris.

                                                                  1. 1

                                                                    That makes sense, happy to have someone finally clear that up :D

                                                                    I’ve heard that about vdom from Rich Harris before, though Elm’s vdom would disagree in that it’s easily comparable performance wise to Svelte. It does help that Elm is able to optimize away a lot of code that Svelte and React aren’t able to.

                                                                    I do like some of the premise of Svelte though.

                                                                  2. 1

                                                                    Yes, obviously there is code executing. :)

                                                                    With, React, Vue, etc, your components do get transpiled to JS but these are useless without the engine, so to speak. On top of the components these need what’s commonly called a runtime (even if the term might not be technically accurate) which includes say a vdom, component base class, reactive primitives, etc.

                                                                    The Svelte compiler simply produces vanilla code you could actually write yourself by hand, given enough time and expertise. Other than some helpers functions to reduce the final size there is no engine, no virtual DOM, etc. The produced code is just a series of very simple imperative vanilla instructions. This makes Svelte very fast but also much lighter which I think is the most important metric for 99% of use cases. It’s not very often one needs to update thousands of dom elements per frame anyway (although Svelte can do it with ease).

                                                                    The downside of this approach is the the size per component can end up being higher with Svelte since it will end up repeating some pieces of code in every component. Given enough components a Svelte app will end up being bigger than a React app with the same number of components. But quite frankly if your app is so big that you’ve actually hit this inflection point you should start using code splitting which totally negates this problem.

                                                                  3. 1

                                                                    Svelte looks so nice, I can’t wait to get a chance to work with it next time I’m green-fielding something. Hopefully they’ll have TS support fully-baked by the time I do, I don’t wanna go backwards and lose my types.

                                                                    1. 1

                                                                      “From createElement to JSX to classes to hooks” is not really an actual flow. It was more like “from createElement to JSX” as one thing (though even then JSX was at the front of the initial releases) and then “from classes to hooks”.

                                                                      Now, hooks are problematic to say the least, though it’s a nice feeling API there’s a lot of unfortunate, avoidable magic that would be hard to roll back. But JSX provides a “real” improvement that none of the traditional stuff provides, which is actually typechecked templates.

                                                                      There are a lot of issues with usage of frontend JS but it is by and far miles better than almost all other forms of frontend and UI development, by being (when done at its best) safer, nicer on bandwidth (you heard me right! Of course sending raw data and using cached templates on the client side is going to be quicker than server-side rendering and constantly sending over HTML to the user for most devices), and just a better abstraction than other UI development tools.

                                                                      EDIT: I think Svelte is kinda interesting from a tool development perspective but I disagree with its approaches and moving backwards on safety guarantees that React provides. There’s a middle ground but I feel like we’re not going to find it because of “no runtime” navel gazing.

                                                                      1. 2

                                                                        It was more like “from createElement to JSX” as one thing (though even then JSX was at the front of the initial releases) and then “from classes to hooks”.

                                                                        Indeed, it was an artistic license. :)

                                                                        nicer on bandwidth

                                                                        I agree, as long you know how to manage the first hit of JS bytes that needs to be downloaded and parsed.

                                                                        Another problem with modern SPAs is that, unless done well, it breaks many things users take for granted.

                                                                        1. When going back to a form these should keep the last content that they had before pressing submit.

                                                                        2. Many routers in SPAs usually capture the click events and decide what to do with it which frequently breaks stuff like clicking with a modifier key, middle mouse button, etc.

                                                                        3. When going back the previous content should be preserved instead of reloading it again and showing a spinner.


                                                                        All of those points can be certainly solved, but in my experience most SPAs do not care about these details.

                                                                        Don’t get me wrong, I absolutely think that an SPA when done well can provide the best user experience. It’s just that doing it well takes a lot of effort. Also, considering the success of non SPAs like StackOverflow, Github, Amazon, Wikipedia, etc, I often wonder if going the extra mile is worth it.

                                                                    1. 4

                                                                      I wonder if this matches up with Carnegie Mellon’s success with bringing in and graduating a more diverse group of computer science students https://rework.withgoogle.com/blog/change-culture-not-curriculum-for-women-in-cs/.

                                                                      1. 6

                                                                        Replace the “asker” with a young female student and “answerer” with a middle age male professor and such use of emojis can now be interpreted as borderline flirting and be unwelcome.

                                                                        Furthermore emojis are too simple to express real emotions which are more complex than a single drawn face. In the rare cases when I used them I found myself not really “connecting” with the vibe they portray. And they tend to overstate. For example I suspect that very few who write “lol” are actually laughing out loud. But then why create this false sentimentality in the first place.

                                                                        1. 7

                                                                          As an older male who has worked with younger women emojis don’t mean flirting, unless you’re specifically using flirtatious or gratuitous emojis. You are correct that lol doesn’t literally mean laugh out loud anymore and hasn’t for many years. Like other forms of communication, spoken, hand (asl, and other sign languages), written, etc, meaning and pronunciation change over time.

                                                                        1. 2
                                                                          • Hoping for a new Snowpack release so I can add Elm support. Already have the plugin built but the Snowpack team needed to add support for recognizing .elm files.
                                                                          • Play Minecraft with my wife and some friends
                                                                          • Play Raft with my wife, and maybe friends if it runs on Mac
                                                                          • Possibly take another stab and trying to build a graphical web page editor
                                                                          • Keep knitting my first scarf!
                                                                          1. 1

                                                                            What is Snowpack? I looked at their website but don’t understand what they’re doing over regular npm?

                                                                            As to knitting, I got bored by a scarf quickly, but found a hat much more fun :)

                                                                            1. 2

                                                                              I restarted my scarf 5 times because I kept adding a stitch. I’m about an inch and a half in now and really enjoying it. I’ll probably try a hat next :D

                                                                              Snowpack is an alternative build tool for web development to Webpack or Parcel. It goes with the idea that most browsers support esmodules, <script type="module">, now so there’s no need to bundle or transpile that code. It makes development builds super fast because there’s nothing to build (unless you’re writing TypeScript, Svelte, Elm, etc.). Snowpack also has support for optionally using Parcel or Webpack to bundle your code for production.

                                                                              While the Snowpack devs did add support for .elm files on Friday, getting it all to work together in a way that would allow nice ejecting has eluded me. As far as I can tell, I’d have to do import Elm from "./Main.elm"; in my javascript and that isn’t valid javascript. Going to try and see this week if there’s a better way to go about it.

                                                                          1. 1

                                                                            The Elm ecosystem is now what I hold as the gold standard for dev UX. The compiler alone includes:

                                                                            • fastest build times I’ve ever experienced in web dev by far
                                                                            • error messages that both point to the exact cause as well possible solutions
                                                                            • repl for those that want it
                                                                            • dev server (for Elm only)
                                                                            • semver is enforced in public packages

                                                                            If you want more tooling there’s elm-format which follows in the footsteps of gofmt. There’s elm-language-server which supports a handful of IDEs and provides a lot of autocompletion and other niceties. If you need a slightly better dev server there’s elm-live, and soon Snowpack will support as well.

                                                                            For most hobby projects I rarely have to use anything beyond the cli and elm-language-server, and one or two 3rd party dependencies!

                                                                            1. 4

                                                                              Maybe I’m the exception to this behavior, but as a front end dev of 8+ years I’ve always been happy to jump into unfamiliar back end code to contribute as needed. Over the years I’ve written C, C++, C#, Java, Perl, and Ruby for the back end all while writing JS 99% of the time for web apps.

                                                                              I’ve also had co-workers from multiple companies that praise JS like it’s the one true language and all others will wither away.

                                                                              Overall I feel like it’s ignorance. So many of the “JS or bust” devs I know have only ever touched JS, so maybe it’s a fear of things that are different?

                                                                              1. 23

                                                                                So accurate, and I’m glad Lea had the patience to put it into writing. I’m much more inclined to write off the entire ecosystem as some expletive.

                                                                                This is generally why I push juniors towards learning Elm instead of JavaScript these days. There are so many edge cases in today’s JavaScript. So many inconsistencies. So much magic one just has to know. So much conflicting information and constant churn. I feel this pain every time a junior asks me for help with something that won’t work as they expect, which these days is effectively every day.

                                                                                Juniors are surprisingly good at finding logic rules that are internally inconsistent in programming languages.

                                                                                There’s been a push lately for people to write “simple Haskell”, and to be honest I think we more desperately need a push towards simple JavaScript. That or just abstract it away entirely and allow it become the bytecode of the web.

                                                                                1. 13

                                                                                  So many inconsistencies. So much magic one just has to know.

                                                                                  This sounds like English.

                                                                                  JS has two clear strong points: everybody knows it and it’s the lingua franca of the web. Just like how everybody knows English and it’s the lingua franca of international commerce.

                                                                                  The way it is going, we will use JavaScript forever.

                                                                                  Yes you could learn Elm. But when you quit your company 2 years from now, it will likely be better to have +2 years of JS than 2 years of Elm.

                                                                                  1. 16

                                                                                    everybody knows it

                                                                                    I would argue against that.

                                                                                    I think it’s no coincidence that one of the most popular technical book series for this language is called You Don’t Know JS.

                                                                                    1. 9

                                                                                      Well they know it the same way most people know English. Incomplete and error-prone but most of the time still good enough.

                                                                                      1. 4

                                                                                        I think “incomplete and error-prone” is what causes user experiences the likes of which is described in the article. For an experienced programmer, that might mean giving up on some library or language. For a novice, that might mean reconsidering their interest in programming.

                                                                                    2. 5

                                                                                      “everybody knows it and it’s the lingua franca of the web “everybody knows English and it’s the lingua franca of international commerce”

                                                                                      Sure, if by that you mean “everyone claims to know it, but when they need to use it, many fall flat on their face, or resort to some half-assed translation system that just complicates matters”.

                                                                                      1. 5

                                                                                        It sounds a bit like C, in fact: A standardized cross-platform (ha!) language with odd corner cases everyone seems to augment with libraries to smooth over the fact it was never fully portable from the beginning. It keeps being used, so it accretes more libraries around it, making it harder to switch away from, as even if you’re writing in a different language, you need to accept that the rest of the world speaks an API designed around That Language the moment you talk to something from the outside world.

                                                                                      2. 24

                                                                                        You push juniors towards learning Elm, a little known language, with smaller community and fewer learning and documentation resources, and no proven longevity (just google “leaving Elm” for crying out loud)? As someone who had to pick up JS over the past year and uses it at their job, any newbie picking up Javascript ES6 and following good programming practices should have little problem. The ecosystem is a different story, but most “edge cases” and “gotchas” come from inexperience with the language. Recommending they learn some random language won’t help with a PEBCAK problem like that.

                                                                                        1. 4

                                                                                          Despite being a Haskell fan, I don’t find Elm to be an attractive target. Sure, it’s simple, but the JS interop is really messy, some aspects of setting up elements just don’t scale well, and I’ve seen far too many complaints about the core team’s behavior to assume it’s just a fluke.

                                                                                          Yes, JavaScript has a ton of weird stuff going on. However, it’s still the standard, and learning it is beneficial—even if you don’t like to use it personally—because at minimum you’ll be seeing a lot of it. The edge cases in tooling are a mess but there are improvements lying around if you scan a bit (e.g. Parcel 2 is looking far more promising over Webpack’s config soup), and most of the type system weirdness is “solved” by using TypeScript (which makes me sad since it’s unsound, but it also has some incredibly powerful type system features that many other languages don’t).

                                                                                          1. 4

                                                                                            I want to be clear that the point of my comment was not to fetishise Elm.

                                                                                            The point is that all of JavaScript’s inconsistencies makes learning how to write programs with confidence immensely more challenging.

                                                                                            JS interop is not part of learning how to write programs, and some people’s reaction to how the the language designers reacted to language feature requests (which usually added a greater surface area for potential runtime failure) is also not part of learning how to write programs.

                                                                                            Minor aside: I don’t see how Elm’s FFI is “messy”. The port system works the way I would expect it to. It might feel more cumbersome than running some IO unsafely, but effects are hard, and this is the price we pay for a smaller surface area of potential runtime failures.

                                                                                          2. 2

                                                                                            With 8+ years of JS (and TS) experience, and a smattering of Perl, Java, C, C++,C#, Elm, Ruby (Rails), Elm, Haskell, and more. I’d rather write all of those other languages combined every day than write more JS. The community always feels like they revert to whataboutisms and “it’s the language of the web!”. When it comes to writing a server, it’s perfectly acceptable to use any of a variety of languages. When it comes to writing for the browser it’s JS or nothing. Suggesting Elm is akin to suggesting cannibalism. I’d suggest Svelte, but most people think it’s JS. Why can’t the web front end be as diverse and accepting as the back end?

                                                                                          1. 5

                                                                                            As a professional programmer of 8+ years, I feel like this describes most of my coworkers over my entire career.