Live data from Hacker News

You probably don't need a JavaScript framework

slack-files.com

141–150 of 356 posts

Re: You probably don't need a JavaScript framework

#141
post #78
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…

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 correlation whatsoever between the quality, readability, or maintainability of code and whether it gets rewritten when a new team arrives.

Sometimes, that’s just what happens, whether we think it’s justified or not.

Re: You probably don't need a JavaScript framework

#143
post #91

One thing many people underestimate is how easy it is to run into XSS, XSRF, XSSI when not using a framework, in particular XSS when using native DOM APIs ("location.href = ..." - pwned. "e.innerHTML = ..." - pwned. "a.href = ..." - pwned. "*.src = ..." - pwned.). You might not need a framework, but you'll need a structured approach to avoid those problems, and frameworks can help a lot with security.

Unless your framework bridges the backend and frontend you're not going to just magically get rid of XSS vectors.

Also regardless of what framework you are using you still have access to location.href, e.innerHTML, etc. I'm not really sure what you're trying to convey here but it's lost on me because, framework or not, all of these things still exist. Hell angular simply wraps location as do some other frameworks.

Re: You probably don't need a JavaScript framework

#144

Earlier quoted context omitted.

You are ignoring huge problems. How does a LAMP/RAILS app share server side rendering code with the client? How does a LAMP/RAILS app share data models between the server and client? How does a LAMP/RAILS app provide search engines with indexable dynamic pages? How does a LAMP/RAILS app preserve client state between page reloads? How does a LAMP/RAILS app synchronize client state between multiple connected clients? Y…

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…

Answer: a bunch of singular solutions that may or may not be tested/documented

Why do you want to write all that extra code instead of just picking the right tool for the job?

Re: You probably don't need a JavaScript framework

#145
post #136

Earlier quoted context omitted.

You are ignoring huge problems. How does a LAMP/RAILS app share server side rendering code with the client? How does a LAMP/RAILS app share data models between the server and client? How does a LAMP/RAILS app provide search engines with indexable dynamic pages? How does a LAMP/RAILS app preserve client state between page reloads? How does a LAMP/RAILS app synchronize client state between multiple connected clients? Y…

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.

Re: You probably don't need a JavaScript framework

#146
One of the big ones is build tools.

You don't need Gulp/Grunt/etc for 90% of the stuff I've seen it used for. They could be replaced with a Makefile plus a bunch of standard unix utilities.

You shouldn't have to install 90 libraries in order to build/install/run your program.

Re: You probably don't need a JavaScript framework

#147

Earlier quoted context omitted.

I am very good at what I do. I have had lots of these conversations with other people who think they are good at what they do. This line of thinking kills companies, because the prototyper they hired for their "MVP" doesn't like frameworks. A year later he/she is gone and I'm rebuilding their app as an angular app. You don't have to agree with me, but I am right. Millions of of dollars in contracts and a resume full…

I'm not going to engage you on what you do, but you need to re-read some of the comments you've made. A lot of it is too hostile / oddly opinionated to be taken seriously, regardless of message. Whatever it is, it's not good communication.

I am not an evangelist, I'm not trying to win a popularity contest in this thread.

If people choose not to listen to what I have to say it has no impact on me at all. I will continue making a living off their mistakes.

Re: You probably don't need a JavaScript framework

#148
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…

I can't think of anything that's particularly constructive to say, but I find your comment... irritating. It's likely that you are simply wrong. It sounds like you are personally upset that your creation was modified by other developers who may have more experience.

If you haven't had the experience of maintaining multiple projects with some kind of consistency between them, then adding "complexity" (unit tests? really?) may seem unnecessary. I've had similar discussions/arguments with (junior) developers (or non-developers) and it's just a waste of time. If you don't have the long view, the whole discussion is moot.

Now, if those other developers created an unmaintainable monster, that's orthogonal; you can do that with any framework or no framework. You will always end up either A) creating a one-off framework anyway or B) creating a nightmare of inconsistency.

Edit: Also, I think it's somewhat amusing that you include jQuery right alongside vanilla JS without irony while denigrating more-modern frameworks.

Re: You probably don't need a JavaScript framework

#149

Earlier quoted context omitted.

You are ignoring huge problems. How does a LAMP/RAILS app share server side rendering code with the client? How does a LAMP/RAILS app share data models between the server and client? How does a LAMP/RAILS app provide search engines with indexable dynamic pages? How does a LAMP/RAILS app preserve client state between page reloads? How does a LAMP/RAILS app synchronize client state between multiple connected clients? Y…

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 picking the right tool for the job?

Because I can do it in less lines, in less time, with no new dependencies, and -- again! -- I don't need to learn another new framework!

PS- Please understand, I know the difference between good code and bad. That's why I've automated most of my job title and am able to spend 97% of my working day helping the rest of my team solve their problems! Oh and did I mention I handle the infrastructure, enterprise integration, telemetry, and sales reporting for my company?

Re: You probably don't need a JavaScript framework

#150
post #102

Earlier quoted context omitted.

I'm paying my salary. In my last performance review I rated myself outstanding and gave myself a substantial bonus. Frankly my employer is a little bit irritated by your arrogant comments about his hiring policies You list a lot of things that a framework gives you, but they vary between the small (routers are easy if you can ignore #) and the things which you probably don't need but have been convinced you want by y…

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!
Post reply on HN