codecurve's comments

What makes the Date constructor a good candidate for the standard library but not the aforementioned methods? Not everyone knows about Day.js, you had to learn that at some point. Why Day.js instead of Moment or Luxon or Date-Fns? There's a lot of cognitive value to having a fully featured standard library.

As I discovered yesterday, :Gbrowse also works for other contexts such as jumping directly to the GitHub page for a specific commit after opening one via :Git log or :Git blame.

As someone who has written tens of thousands of lines across both ClojureScript and TypeScript, this baffles me. I can definitely understand why someone would prefer CLJS, but it has a way higher barrier to entry than TS.

If you're smart enough for Clojure then you're smart enough for TypeScript. That doesn't mean you have to like it though, but you don't have to hide that distaste behind incendiary exaggerations about TypeScript only being suitable for superhuman geniuses.

The overwhelming evidence is that TS is popular _because_ it is a safer and easy-to-understand alternative to JS.

We set off building a new product using this approach a few years ago and wrote about our motivations here: https://medium.com/hackernoon/exploring-single-tenant-archit...

I can't remember all of the reasons that we ditched the idea, but it quickly became clear that we would be writing a lot of the core tooling ourselves, and we kept running into problems with AWS around dynamically provisioning the load balancers and certs for N boxes.

I wouldn't dream of trying to manage different schemas across all the databases either, that sounds like a serious headache that could only be mitigated by having separate codebases and separate development teams managing them.

If a customer needs custom fields, I would make them a first class citizen and the required `fields_definitions / field_values` tables to your database and let them manage those fields themselves.

I'm glad we ended up defaulting to a multi-tenant architecture even though we lost some of the proposed benefits (isolation, independent scaling etc).

Kumu | Remote | https://kumu.io

Kumu is a web-based data viz platform that helps people understand complex relationships, mostly through network, systems, and stakeholder maps. We’ve spent years refining Kumu’s visualization platform, and we’re embarking on our next phase: developing a suite of specialized tools for tackling tough problems (such as building stronger communities through Weavr, building better teams through Compass, and collecting better data through Undercurrent and System Effects).

Full-time position (remote)

Salary $60-80k

Equity 1-2%

Small, bootstrapped, and profitable team with recurring revenue over $300k / year

Flexible hours with a fun mission-driven team

Modern stack: react, typescript, ruby/rails, aws/cloudformation, postgres, bonus points for experience with: ui/ux design, react-native, webgl, apollo/graphql, koa, webpack, babel

On a day-to-day basis you’ll primarily be working with Ryan (@rymohr) and will be involved throughout the entire development process: from the initial brainstorm to flush out the basic architecture all the way to the final stages of testing and release. We like to move fast and ship often, and we try to break work into weekly deliverables to keep everyone’s expectations and progress in check. We do a quick hangout at the beginning of each week to revisit everyone’s immediate priorities.

Once a year the whole team gets together for an adventure, with past retreats including snowboarding in Oregon, surfing in Hawaii and rock climbing in Colorado.

If you're interested, please send an email to [email protected] with answers to the following prompts:

1. Tell us a little about yourself. Who are you? Where do you come from? What skills have you mastered?

2. Tell us about a project you’ve worked on that you’re proud of

3. Include links where we could learn more about you professionally and personally (website/github/twitter/medium/instagram/etc)

4. Include a recent photo of you doing something that you love Thanks!

And 997 of those are development tooling dependencies that are not included in the application that you eventually deploy.

Don't get me wrong, I would rather there were fewer development dependencies too, but they are tooling abstractions that you are _opting-in_ to.

If that is still a cognitive burden, then there's nothing to stop you using React a build step through a CDN.

Kumu.io | Full stack developer | REMOTE | Full time | https://kumu.io

Kumu is a web-based data viz platform that helps people understand complex relationships, mostly through network, systems, and stakeholder maps. We’ve spent years refining Kumu’s visualization platform, and we’re embarking on our next phase: developing a suite of specialized tools for tackling tough problems (such as building stronger communities through Weavr [1], building better teams through Compass [2], and collecting better data through Undercurrent [3] and System Effects [4]).

We’re currently working with some of the world’s top organizations including The Omidyar Group, Gates Foundation, Hewlett Foundation, USAID, Stanford ChangeLabs, Democracy Fund, World Bank, Humanity United and more.

· Full-time position (remote)

· Salary $60-80k

· Equity 1-2%

· Small, bootstrapped, and profitable team with recurring revenue over $300k / year

· Flexible hours with a fun mission-driven team

· Modern stack: react, typescript, ruby/rails, aws/cloudformation, postgres

· Bonus points for experience with: ui/ux design, react-native, webgl, apollo/graphql, koa, webpack, babel

On a day-to-day basis you’ll primarily be working with Ryan (https://twitter.com/rymohr) and will be involved throughout the entire development process: from the initial brainstorm to flush out the basic architecture all the way to the final stages of testing and release. We like to move fast and ship often, and we try to break work into weekly deliverables to keep everyone’s expectations and progress in check. We do a quick hangout at the beginning of each week to revisit everyone’s immediate priorities.

Once a year the whole team gets together for an adventure, with past retreats including snowboarding in Oregon, surfing in Hawaii and rock climbing in Colorado.

Please send an email to [email protected] if you’re interested or know somebody we can reach out to who might be. Thanks!

[1]: https://weavr.app/about

[2]: https://compasshq.com

[3]: https://undercurrent.io

[4]: https://systemeffects.com

I love the idea of Parcel but I've struggled with a number of non-obvious problems when using it on hobby projects.

° Sourcemaps not working (wrong files / no source translation)

° Randomly losing exports (a module with multiple exports where one of them ends up as an empty object - fix by clearing cache and restarting)

° Errors like "module 71b not found"

° Hot module reload enabled by default, meaning that all top level code runs again when you reload the code (e.g. here's an extra canvas in your dom)

My preferred zero config setup for hobby projects has become <script type="module">[1] and a live reload server[2].

If I'm working on a React project then I will always use Create React App when I can[3].

When I take something beyond the hobby stage and into maintaining it as an ongoing project, I use TypeScript Quickstart[4]—to abstract the underlying Webpack config and start writing code immediately.

I'll only reach for Webpack when I know that I need more flexibility than any of these other tools offer—which isn't very often.

[1]: https://jakearchibald.com/2017/es-modules-in-browsers/

[2]: https://github.com/tapio/live-server

[3]: https://github.com/facebook/create-react-app

[4]: https://github.com/danprince/typescript-quickstart

There are actually a lot of great materials available on Systems Thinking, here are a few of our favourites:

Articles:

- Introduction to Systems Thinking (https://thesystemsthinker.com/introduction-to-systems-thinki...)

- Tools of a Systems Thinker (https://medium.com/disruptive-design/tools-for-systems-think...)

- The Mythical Leverage Point (https://blog.kumu.io/the-mythical-leverage-point-d582ce4b8b4...)

Videos:

- Peter Senge Introduction to Systems Thinking (https://www.youtube.com/watch?v=eXdzKBWDraM)

- I Used To Be A Systems Thinker (https://www.youtube.com/watch?v=3Ymt_TbNNwE)

- The (Failed) Promised of Systems Thinking (https://www.youtube.com/watch?time_continue=614&v=aelqgvFXGi...)

- Systems Practice Mindsets (https://vimeo.com/212281432)

Courses:

- +Acumen Systems Practice Course (https://www.plusacumen.org/courses/systems-practice)

Books:

- Thinking In Systems: A Primer by Donella Meadows (https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp...)

- Fifth Discipline Fieldbook (https://www.amazon.com/Fifth-Discipline-Fieldbook-Strategies...)

- Systems Thinking for Social Change (https://www.amazon.com/Systems-Thinking-Social-Change-Conseq...)

Articles on Leading Systems Change:

- Dawn of Systems Leadership (https://ssir.org/articles/entry/the_dawn_of_system_leadershi...)

- Acting and Thinking Systemically (https://thesystemsthinker.com/acting-and-thinking-systemical...)

- Transforming the Systems Movement (https://thesystemsthinker.com/transforming-the-systems-movem...)

Relevant Tools and Websites:

- Kumu (https://kumu.io) - Web-based tool for building interactive system maps.

- The Systems Thinker (https://thesystemsthinker.com/) - Complete library of all "The Systems Thinker" publications over the past 30 years

- Loopy (http://ncase.me/loopy/) - An playground for building interactive systems maps.

(Disclosure: I'm a Developer at Kumu)

I did last year's Advent of Code[1] using a different programming language for each day of the month.

Repl.It was easily the best tool out there for quickly prototyping solutions and testing them out for the languages that I don't use often and don't have a dedicated environment set up for.

As part of that month, I started tracking each of the online REPLs I ended up using and threw them all into a gist[2]. Turns out you can do a lot of programming from the browser these days.

[1]: http://adventofcode.com/2017

[2]: https://gist.github.com/danprince/0f4a200319c95209c9c028b296...

Because a framework can't bring new language primitives, such as types?

Slack for the noisy chat.

GitHub issues for taggable discussions.

Zoom.us for calls and beer hangouts.

Google Docs for collaborative writing.

Screenhero for pairing/reviewing together.

Sure, no arguments there. It does save time in JavaScript and a large part of that is because the language has been designed around mutability.

Part of that trade-off is that JavaScript can't make the same guarantees about what happens when you pass an object into a function. It's harder to be confident that a given program is correct.

Immutability is just a part of the "simple made easy"[1] ethos of Clojure and I think most Clojure programmers will argue that taking the time to understand that philosophy _is_ worth the investment.

[1] https://www.youtube.com/watch?v=rI8tNMsozo0

Few points on immutability and Clojure.

The abstraction that hides mutable data structures is transient[1], not vars, refs, agents and atoms.

Those abstractions are all to do with mutable references, not mutable data. They're there to make sure that you have safe ways to coordinate state in concurrent environments.

I agree that immutability can be annoying in languages that weren't designed with it in mind, but the languages that were almost always make it easier, safer and performant to create copies rather than mutate data.

If you're writing Clojure or Haskell and you think you're going to save yourself time by "just creating a map and mutating its structure" then you're misunderstanding the purpose of the language. These constraints are what enable the guarantees and contracts those languages make.

[1]: https://clojure.org/reference/transients

Because both are opinionated ways to get a React project going without having to configure any tooling yourself.

Next.js also focuses on client side JavaScript, but happens to render at the server first, so that there's something there for users before the client bundles have downloaded, parsed and been executed.

You could think of it as a more configurable create-react-app that supports server side rendering, with a convention over configuration approach to pages and links.

We had a tough time with Terraform on AWS. The syntax is undeniably better than Cloudformation and having the concept of modularity built in is a big win.

However, when things went wrong we ended up with cryptic error messages and often when `terraform up` failed, then `terraform destroy` would fail too, leaving us using AWS console to jump in and start clearing up the resources. Particularly painful because AWS has no awareness that your stack came from a Terraform config, so you have to navigate through the subresource menus destroying things one-by-one.

We ended up switching over to Cloudformation. The extra verbosity does suck, but the tooling for running/updating stacks feels far safer. We can review the changeset when we update the stack, view a realtime event log as resources are created, deleted or updated, and best of all we can always tear the stack down from a single point.

Wonder what the language would now look like if we had some dedicated syntax for Object.create instead of hiding the underlying prototype mechanism under the familiar class syntax.

    typeof (class {}) === "function"

This is almost guaranteed to be a future WAT[1] moment for the next generation of JavaScript programmers.

I can already see that a big part of the appeal for classes is that they keep your code looking neat and succinct (as opposed to throwing .prototype and Object.create all over the place.

I'd much rather be writing code that looked something like the below, than having to think about super, static, own properties, constructors, private fields etc.

   // provided by some view library
   let Component = {
     state: null,

     setState(state) {
       Object.assign(this.state, state);
       this.forceUpdate(); 
     }

     // ...
   }

   let Counter is Component {
     get state() {
       return { count: 0 };
     },

     inc() {
       let { count } = this.state;
       let { step } = this.props;
       this.setState({ count: count + step });
     },

     render() {
       let { count } = this.state;
       return <button onClick={this.inc}>{count}</button>;
     }
   }

   render(<Counter step={2} />);

Although it introduces a new keyword, the abstraction ends up being minimal, because it's just a sugar for the existing Object.create.

   // let Counter is Component
   let Counter = Object.create(Component);

This is obviously a very half baked idea, but I have programmed quite happily with Object.create for a long time without ever _needing_ to use classes. If we had better tools for working with prototypes then maybe we wouldn't have to pretend the language had classes instead.

[1]: https://www.destroyallsoftware.com/talks/wat

Simple != easy.

Wordpress and co are easy, but they're fundamentally much more complex than static sites.

Jekyll is quite simple, but it can be hard to use in comparison.

Already had some time on the front page on HN today, but I just released https://zaphod.surge.sh/ which uses it.

Totally hear what you're saying and I think JS would be better off without `this` in the first place. Clojure's threading macros are another great solution to the chaining problem.

That said, `this` is here to stay and to me, function bind feels like a pretty great way to write code that feels natural, without the danger of extending the prototypes for Array and Object.