Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do Not Follow JavaScript Trends

pragmaticpineapple.com

Post reply on HN
Print view View original

211–220 of 275 posts

Re: Do Not Follow JavaScript Trends

#211

Post by joshribakoff »

omniscient_oce wrote: post #89
joshribakoff wrote: post #64

I find it interesting the blog post mentioned Kent Dodds article recommending everyone rewrite fetch. I just argued adamantly against Redux docs about writing tests being switched off of Enzyme to his library because it’s “more trendy”. https://github.com/reduxjs/redux/pull/3708 Unfortunately, the community overruled me and the docs no longer show how to test Redux apps with enzyme. It only shows Kent’s “react testin…

react-testing-library and Tailwind are two tools that I use that I feel the userbase are a bit cult-like. I don't know if it's "not invented here" syndrome so much as people use tools based on people, not always just merit. Kent and Adam had similar self-promotion engines running with long-form free video tutorials and strong social media presence, blog posts online, etc. Perhaps this style of promotion more of a too…

Yeah a blog post titled “never do X” is going to get more clicks than “consider the trade offs before doing X” unfortunately. This leads to people following “thought leaders” and trends, instead of thinking for themselves imo

Re: Do Not Follow JavaScript Trends

#213

Post by MaxBarraclough »

jcbrand wrote: post #204
MaxBarraclough wrote: post #114

Earlier quoted context omitted.

> a virtual DOM? Aren't current web standards enough to make a flower shop website? Of today's frameworks, all but Svelte use a virtual DOM.

Not true. litElement (used by Polymer) uses tagged template literals and no vdom.

You're right, LitElement and Polymer don't use a VDOM. [0][1]

I don't think Polymer 3 uses LitElement though. Seems to say they're highly compatible, but that Polymer 3 uses PolymerElement, not LitElement. [2]

[0] https://lit-html.polymer-project.org/

[1] https://www.infoq.com/news/2019/06/polymer-lit-html-element-...

[2] https://github.com/Polymer/polymer

Re: Do Not Follow JavaScript Trends

#214

Post by rowanG077 »

wegs wrote: post #186
mettamage wrote: post #136

Earlier quoted context omitted.

How about using Typescript? That still seems like a huge improvement, especially because you can implement it incrementally (aka for parts of code where type checking is vitally important). I'm using it now at my work and I'm surprised how much info I'm getting compared to whatever JS is throwing at me.

TypeScript? Erm... Not for me. There were many such systems in the past. CoffeeScript was a big improvement over 2010 JavaScript. Before that was GWT, which was sooo much nicer than 2006-era JavaScript. I could list a bunch of others. If you used any of them, you're now stuck with a legacy system(+), and you'll find fewer and fewer people able to read/write your code, and otherwise. I'm also not a big fan of static t…

Dependently typed language can check at compile time if you violate a ranged integer value among many other things.

I'm curious though why you are not a fan of static typing? I feel like if you have a language with inference it's pretty good. I mean you could imagine python with type inference and you could essentially write anything in it you can today (baring stuff like heterogenous data structures) without specifying the type manually.

Re: Do Not Follow JavaScript Trends

#215

Post by ccmcarey »

cameronfraser wrote: post #168
wnevets wrote: post #131

Earlier quoted context omitted.

What do you mean, everyone is now updating their codebases to remove redux, HoF and switch to hooks.

No, people are realizing that they were just using redux as a caching layer and the boilerplate associated with it wasn't worth it when there are better approaches to caching local data now.

Out of curiosity what are the better approaches to caching local data? The only thing I'm aware of is something like Apollo client but .. that only works for graphql.

Re: Do Not Follow JavaScript Trends

#216

Post by pacala »

mettamage wrote: post #136
wegs wrote: post #118

Earlier quoted context omitted.

Rewrites only make sense if you get a multi-fold improvement. In the history of computing, that's rare. So they rarely make sense. Well, JavaScript was really horrible when it came out. It was just about the worst major programming language ever made. It sort of reminds me of an interpreter I threw together for a programming language I invented when I was in high school, when I really didn't get any aspect of program…

How about using Typescript? That still seems like a huge improvement, especially because you can implement it incrementally (aka for parts of code where type checking is vitally important). I'm using it now at my work and I'm surprised how much info I'm getting compared to whatever JS is throwing at me.

Typescript greatest features are optional types and the extensive type inference. On small projects this can work well, but on larger ones I can see overly rigid style guides requiring typing everything explicitly in triplicate becoming cumbersome in an Enterprisey way. Curious what people's experiences are.

Re: Do Not Follow JavaScript Trends

#217

Post by pacala »

gfodor wrote: post #174
throwaway894345 wrote: post #167

Earlier quoted context omitted.

It seems like it's trending toward static, at least recently. I think the big driver for this is the popularization of statically typed languages that aren't C++ and Java. A lot of people had painful experiences with C++ and Java and attributed that pain to static typing. It's now more clear that static typing is a net benefit, but it must be implemented reasonably and it doesn't solve other language design issues. A…

Hard to say. It seems as cyclic as anything else. Hard to tease apart real benefit from the usual fad/hype cycles. Ruby, Python, Erlang/Elixir, Lisp/Clojure, etc, all doing just fine without it. (Some, with some lightweight annotative-oriented typing for a subset of projects.) The best counterargument to static typing I can articulate is that in general, the only way to be sure software works is to run it. And so, ul…

One of the greatest boons of static typing is formal documentation of data structures and interfaces. Catching errors early is a bonus :)

Re: Do Not Follow JavaScript Trends

#218

Post by pacala »

nwienert wrote: post #145
wegs wrote: post #118

Earlier quoted context omitted.

Rewrites only make sense if you get a multi-fold improvement. In the history of computing, that's rare. So they rarely make sense. Well, JavaScript was really horrible when it came out. It was just about the worst major programming language ever made. It sort of reminds me of an interpreter I threw together for a programming language I invented when I was in high school, when I really didn't get any aspect of program…

Typescript is leagues ahead of Python. Types and async/await are the big ones, but destructuring, no lambda weirdness, optional chaining, nullish coalescing, proxies, JSON support, and generally debugging tools are all better.

Having used both Python and Typescript recently, I largely prefer the consistency of Typescript. [Hey mom, I like cherries better than strawberries]. Having said that, I'd love to have named function arguments in Typescript. Props workaround is, well, a workaround.

Re: Do Not Follow JavaScript Trends

#219

Post by nsonha »

BossingAround wrote: post #160
nsonha wrote: post #60

Earlier quoted context omitted.

To me I sometimes get too obsesded with types and try to wrire clever ergonomic type inference. Usally I stop when I realize the types are double loc comparing to the actual implementation or what I was trying to do was impossible. It can be a drain on productivity if you're like me.

Coming from Java background, I personally have no such problem. Is JS your only/main language? Maybe JS + Python?

Not really I played around with multiple things. Came from a Java background too. I'm in the process of trying to get to a better language actually, like scala or F#. Java seems too limited and typescript while can do a lot of things is no scala and not as clean as F#.

Re: Do Not Follow JavaScript Trends

#220

Post by thanatropism »

recursivedoubts wrote: post #36
thanatropism wrote: post #23

Earlier quoted context omitted.

In 1996-1998 as a teen I "made some websites" for local businesses. The one I made for my parents even had a search function (in PHP) in a CSV with their products (which were like 100). The CSV was generated by taking whatever Lotus Approach (their desktop DB) generated and transforming it with some custom Haskell code (I was a teen, what did I know). They clicked an icon to pull the data and another to run a FTP bat…

I have something for you: https://htmx.org

Yow. I have an application growing out of control in Streamlit (https://streamlit.io), which is a rshiny-type interactive dashboard gizmo. I'm now able to consider rewriting it with a proper front-end.

It's like a whole world I had been sealed off from has reopened.

Post reply on HN