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

251–260 of 275 posts

Re: Do Not Follow JavaScript Trends

#251

Post by kingdomcome50 »

mikewhy wrote: post #201
novaleaf wrote: post #141

Earlier quoted context omitted.

I'm just now getting back into webdev after 3 years. Can you please recommend a good tutorial/demo using Hooks? Especially if it's using Typescript! I strongly dislike the create-react-app project because it abstracts everything away.

> I strongly dislike the create-react-app project because it abstracts everything away That's the point of it, really. CRA sets up your build (webpack) and test runner (jest). Has nothing to do with hooks. I'd strongly suggest using it, unless you're interested in learning how all that stuff works.

Any dev worth their salt should know how to set up these tools from scratch anyway.

The day I first ejected a CRA app I had started was the day I decided to never use it again. I could not believe the sheer amount of code behind that project...

I’ve been writing reasonably complex React/ Typescript projects for years, and have never had any problems with nothing more than a few simple config files to bootstrap everything.

Re: Do Not Follow JavaScript Trends

#252

Post by blackrock »

throwaway894345 wrote: post #249
blackrock wrote: post #234

Earlier quoted context omitted.

Can’t you write the Python functions to force check the input parameter for its type? And error out if not. This should enable you to catch most errors immediately during development.

No, this doesn’t help at all. You only hit these errors if you run those paths in your tests, but those paths would already error downstream. Those paths that weren’t tested may still contain errors that go to production, and again you just hit your new type error instead of the downstream type error. What you need is something that can help you test more paths, and static type checking checks all paths. Further, the…

I don’t disagree with you. Python seems to encourage poor development practices. Basically, anything goes. This can be problematic if you use other people’s libraries, and if their libraries are not fully vetted.

This is not a Python problem, per se. It is a developer problem. It is a human problem.

However, with your own code and libraries, you can enforce your own rigor. Keep your functions smaller, test all the inputs, and validate all the outputs. Although you may end up with smaller production code, but more unit tests.

The unit tests are good, as they give you evidence that you did cover those corner cases.

However, the good thing, is that if the functions are smaller, and well unit tested, then it becomes rare that you have to modify it at a later date. And especially if you think through all the different angles, and try to future proof it. Now you have the ability to do functional composition. Just keep chaining the outputs of one function into another.

Re: Do Not Follow JavaScript Trends

#253

Post by nefitty »

ljm wrote: post #129
sushshshsh wrote: post #94

Earlier quoted context omitted.

.componentInQuestion { whateverBackgroundTagIsCorrectInCss: #hexvalueForColor }, no?

Well it depends, because maybe you're using Styled Components or some other library that ties you into the React/JSX ecosystem. Or maybe your app passes a 'theme' through various contexts and you have to find the right theme and find the thing you need to tweak the background colour for, which might be in a CSS file pulled in through Webpack if you're lucky. If you're not lucky, maybe there's some funky SASS/LESS set…

If this seems absurd to anyone, this aligns closely with my experience in React and even more with Gatsby....

Re: Do Not Follow JavaScript Trends

#254

Post by nefitty »

tfleming wrote: post #205
yxhuvud wrote: post #110

Earlier quoted context omitted.

> Users don't tolerate the inherent delays caused by this approach anymore. Well, I certainly also do not tolerate the delays in contemporary React sites either. Take Reddit for example, which used to be lightning fast when it was mostly serverside, which now is painfully slow, especially on mobile.

Yep, I agree. Was just talking to my wife about Reddit. It's so slow now, especially on mobile. The page constantly crashes on my Android phone and they always recommend the app. No thanks.

Today is the day I decided to switch to old reddit... My Mac can run garageband and vsc and 40 chrome tabs at once, but as soon as I click a front page Reddit link, that modal is like pouring sludge into my computer.

Re: Do Not Follow JavaScript Trends

#255

Post by MaxBarraclough »

spankalee wrote: post #225
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.

As mentioned, LitElement doesn't use a vdom, but neither does Angular, Ember/Glimmer, Solid, incremental-dom, and many others. VDOM diffing is pretty slow, memory intensive, and unnecessary. It's very good it's not the only game in town.

Thanks, I see I'm mistaken. Could've sworn Angular was VDOM-based, but no. [0]

[0] https://stackoverflow.com/a/39739739/

Re: Do Not Follow JavaScript Trends

#256

Post by oalae5niMiel7qu »

throwaway894345 wrote: post #167
gfodor wrote: post #146

Earlier quoted context omitted.

Typescript doesn't strike me as a multi-fold improvement. Dynamic vs static typing is an age-old debate, and in general, advocates can be found arguing that moving your code in either direction results in benefits. So, regardless of your stance on it, it seems unlikely to be unambiguously beneficial. Many large programs exist written in dynamic languages that do just fine.

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…

The trend toward static typing is a fad, like NoSQL in the early 2010s. Who knows what the next fad will be. Perhaps correctness proofs will make a comeback.

Re: Do Not Follow JavaScript Trends

#257

Post by MaxBarraclough »

spankalee wrote: post #224
MaxBarraclough wrote: post #213

Earlier quoted context omitted.

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

Polymer 3 and LitElement are separate projects by the same team. LitElement is the successor to Polymer 3. It would have been named Polymer 4, but it's quite different. They're highly compatible because they are both web components-based. There's no "framework" that creates component instances, the browser does that when it sees the custom elements. So each component is in control of its own lifecycle and rendering.…

How does it work with data-binding? Isn't that a Polymer-specific feature, rather than a feature of Web Components?

Re: Do Not Follow JavaScript Trends

#258

Post by christophilus »

runawaybottle wrote: post #231
christophilus wrote: post #62

Earlier quoted context omitted.

Is front end churn really so prevalent? I hear this opinion all the time, but React is 7 years old. I've been using it for around 5 years, I think. Redux is 5 years old. How old does the most popular web framework need to be before we consider it to be low churn? [Edit: Also, anecdote: before JS, I was mostly a C# developer, and the churn there was at least as bad, maybe worse in my personal experience. Over 15 years…

I’m not sure if you realize your own paradox. Is churn really so prevalent? You then point out how prevalent it is in the .NET community. Yeah it’s prevalent, and if we resemble other shitty ecosystems then we need to introspect.

I do realize it. Maybe I should have added: churn as compared to what? JS doesn’t exist in a vacuum. Most language ecosystems experience churn. I explicitly mentioned we shouldn’t hold everyone to the gold standard of stability that is Clojure. But... maybe we should?

I’m not entirely sure that churn is a binary good or bad. When you think, “Hm I have a more elegant solution to this common problem.” And then offer it to the world, you’ll be shot down with “churn” comments. Churn is way we experience experimentation and the slow progress towards a better solution. I, for one, am glad I no longer have to program COBOL.

Anyway, there’s probably a happy medium. Even Clojure has had some front-end churn. Om is no longer the hotness. Reframe seems to have won. Clojure itself isn’t that old.

Re: Do Not Follow JavaScript Trends

#259

Post by randyzwitch »

thanatropism wrote: post #220
recursivedoubts wrote: post #36

Earlier quoted context omitted.

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.

(Note: I'm Head of Developer Relations at Streamlit)

Out of curiosity, which features are you looking for in a "proper" front-end? Flexibility?

Re: Do Not Follow JavaScript Trends

#260

Post by cameronfraser »

ccmcarey wrote: post #215
cameronfraser wrote: post #168

Earlier quoted context omitted.

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.

react-query, swr
Post reply on HN