Live data from Hacker News

You probably don't need a JavaScript framework

slack-files.com

151–160 of 356 posts

Re: You probably don't need a JavaScript framework

#151

Earlier quoted context omitted.

I remember seeing an article a while ago that suggested react was a bad paradigm because of a similar paradigm that failed... something about COM interfaces in windows programs? Does anyone remember such an article? That was one of the few truly interesting critiques of react that I have read. Don't get me wrong, I'm not a React die hard but I definitely do like that it exists, and I understand where it fits on the l…

I think you're referring to https://bitquabit.com/post/the-more-things-change/ , which compares React to a Win32 WndProc function.

Ah, those were the days! I think I still have that Petzold book somewhere. It had to come with examples, because Stack Overflow didn't exist yet, so that was the only way you could get stuff working in a reasonable amount of time. (Except for when it didn't work in your code for some reason.)

I really like the article, but I'm not sure how else you're really going to do it. You could have magic functions that get called like in Qt (draw(), mousePress())* or that clunky Microsoft C++ framework whose name is escaping me (OnPaint(), OnMouseDown()), but behind the scenes the windowing systems is going have to have a big case statement of: in case repaint call repaint(); in case mouse down call mousePress(); etc. Win32's WndProc just made you write the case statement yourself instead of looking up the documentation to see which magic function you need to override.

I'm a JS framework hater--I've never used any, but I figure if they have a new one every year, and all the frameworky-looking websites are slow, there's got to be a better way--but if React is basically WndProc then at least it's on a solid foundation.

I'm sure the names of these functions are wrong

Re: You probably don't need a JavaScript framework

#152
post #136

Earlier quoted context omitted.

This may surprise you, but we used to make web pages without JS. I know, it's a shocker!!! But guess what? 1 is irrelevant, 2 is irrelevant, 3 is there by default, 4 is easily solved, and so is 5. Turns out, logic on just the server side is simpler. It may not be as pretty, but please don't assume that your way is the only way.

When were you building web pages without JS? 1994? Server side logic MAY be simpler in SOME cases. Overall applications have become a lot more complex over the last 20 years and your oddated methodologies have been replaced by tested thorough solutions built and used by some of the biggest companies in the world.

Well, admittedly, I don't write webapps that often, as that's not actually my job. But last one I wrote without JS is also the last one I wrote period, about 2 months ago. Must be completely ramshackle and useless. Too bad it functions perfectly for me... Again, please don't assume that your way is the only way.

Re: You probably don't need a JavaScript framework

#153

Earlier quoted context omitted.

Hilarious. You are the only person working on the project and you are patting yourself on the back for writing "maintainable" code. Bring 50 more people into the project and then lets talk.

why 50? make it 500! Better yet, make it 5,000 of skilled offshore developers 12 hours away, capable of cranking up few megabytes of code per week each, full test coverage, mocks and injections. Now we are talking! That is maintainable!

Exactly. It is like trying to explain a car assembly line to a guy with a junker in his garage.

Re: You probably don't need a JavaScript framework

#154

Earlier quoted context omitted.

How does a LAMP/RAILS app share server side rendering code with the client? It doesn't, because I don't need/want it to. Any data that needs to be passed to the client is rendered as JSON. Client-side get committed to the database via AJAX (to my buzzword-o-rific REST api), or with good-ol' POST. How does a LAMP/RAILS app share data models between the server and client? Again, not needed. How does a LAMP/RAILS app pr…

(gjolund: I can't reply to you directly, but consider this my reply) Because they're simple? They're relatively standard? They're compact? Because I don't have to learn a new god-damned framework for every single new assignment? When did software development become a paint-by-numbers exercise? There is a difference between spaghetti-code and engineering. Why do you want to write all that extra code instead of just pi…

just fyi, if you don't get the "reply" link, you should be able to click the "X minutes ago" and post a reply that way.

Re: You probably don't need a JavaScript framework

#155
post #112

To begin, React isn't a framework. It’s a tool. Would you compare a table saw to a workshop? That doesn’t make sense and neither does comparing React to a framework—especially if you’re saying you don’t need one. Furthermore, using a virtual DOM is not the purpose of React. Virtual DOM is merely a part of how React works. People don't buy cars to get an engine. They buy cars to get around places. People don't use Rea…

> To begin, React isn't a framework. The way I look at it: - If you use a library that augments your style of work but doesn't change it then it's a library. Maybe a tool. - If you use a library that replaces or changes your style of work then it is a framework. React is a framework in my opinion. It can be used as a library but it's almost never used that way; most people incorporate JSX and much of the virtual dom…

Good post, very well said and says most of what I wanted to say on the subject.

I was much more in the camp of 'use/learn frameworks as much as possible for productivity', started a new job and have really become much more moderate on the subject. There really is a balance and the type of application you're building matters. The best thing about writing your own framework is that you're able to structure to fit the exact needs of a business. The productivity gains can be extremely massive as well. If you can build a custom system that scales to your needs, it can certainly be worth doing. The flip side of course is that you may ( Probably? ) have a fairly simple/basic product. If you don't have heavy business logic to model, the heavy automation and tooling that is available can be a damn good way to go.

Re: You probably don't need a JavaScript framework

#156
post #67

Earlier quoted context omitted.

I didn't downvote you (and I thought it was a thoughtful post), but I could totally see somebody interpreting "web-boy" as some sort of weird emasculating epithet a la "fanboi". On the Internet it's super easy to take offense at things that weren't intended to offend, in fact some people seem to thrive on it.

I think he's referring to all of hipsters who don't really understand what they're using but they're using it because it's hip. Might offend some, but people shouldn't be so quick to hop on a bandwagon and go wrecking working code.

And then there are the "retro hipsters" who stick with "vanilla JS" and jQuery (not a framework?), smugly denigrating the new wave of modern "hipsters". Repeat ad nauseum.

Re: You probably don't need a JavaScript framework

#157
post #154

Earlier quoted context omitted.

(gjolund: I can't reply to you directly, but consider this my reply) Because they're simple? They're relatively standard? They're compact? Because I don't have to learn a new god-damned framework for every single new assignment? When did software development become a paint-by-numbers exercise? There is a difference between spaghetti-code and engineering. Why do you want to write all that extra code instead of just pi…

just fyi, if you don't get the "reply" link, you should be able to click the "X minutes ago" and post a reply that way.

thanks! That trick worked!

Re: You probably don't need a JavaScript framework

#158
post #43

I still remember doing a PoC for an end-to-end secure messaging app with web support, around 3 years back. It was written in plain JS with jquery and one or two libs for crypto bolted on. Simple, easy, but not very maintenance friendly written. Took around 2000 lines all in all. One of four clients (Android, iOS and a bot framework in Scala/Java). Then the web-boys came in to rewrite my... well, contraption. In came…

There's a very suitable verb for describing this process: "enterprisify" This trend toward "frameworkfulness" probably started with OOP and Java in the mid 90s, and spread from there. Fortunately they seem to be realising the ridiculousness and gradually getting out of that mindset, but unfortunately other developer cultures like JS are now headed in that direction.

Using a JS framework like jQuery or Angular or React isn't even remotely similar to Enterprise Java Beans and all that nonsense. You must be joking.

Re: You probably don't need a JavaScript framework

#159
post #72
post #61

Earlier quoted context omitted.

Yeah I find it hard to believe that the people who go on about how convoluted web development is actually get paid to do web development. 1) Where are all the people hiring web devs who don't know a single library or framework? 2) Why do huge tech companies like facebook and google develop web frameworks if they're unnecessary?

Do Google even really use angular? I know none of their core products use it. As to Facebook, their website is painfully slow, seems like it's not a model of the right way to do stuff

I don't think their main website uses React fully yet. Instagram does and that's pretty fast—same as most other well-done React apps.

Re: You probably don't need a JavaScript framework

#160
post #78

Earlier quoted context omitted.

Honestly, it just sounds like you are bad at managing your own software projects and trying to blame it on the web team. If your code had been as easy to understand as you say it is there would have been no need to re-write it. Also, your acknowledgement that it was difficult to maintain makes my point for me.

> If your code had been as easy to understand as you say it > is there would have been no need to re-write it. In theory, only difficult-to-understand and/or difficult-to-maintain code is rewritten. In practice, the definition for “difficult-to-understand” and “difficult-to-maintain” often boil down to whatever the team decides they are familiar with... Or want to be familiar with. I wouldn’t assume there’s any corre…

[deleted]
Post reply on HN