Yeah why not? Let's reinvent the wheel every fucking time.
I'm sure your clients and your family will love that.
You probably don't need a JavaScript framework
131–140 of 356 posts
Re: You probably don't need a JavaScript framework
#132To 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 into their workflow.
But this is pedantic. I feel comfortable I could make an argument for almost any JavaScript library being a framework as well as not being a framework.
> Scale your app up, however, and you’re going to end up with a framework anyway. The only difference is that it will be your own framework, and chances are it will be difficult to understand, hard to maintain, and full of bugs, and you may even be stuck with it because of how much it would cost to change.
While correct I cannot disagree with you enough. If you write clean, as-simple-as-possible code with clear separations of concerns it's dead easy to maintain and not necessarily "full of bugs". It really just boils down to how well a developer can architect an application to determine if their own framework is going to be a huge bottle neck / issue or a breeze. I've been through both :)
> You’re welcome to give this up to be a cowboy, but me: I’ve been there, thought I was that smart, and realized how much better off I am by not trying to reinvent the wheel every time.
I'm not a fan of this sentiment. If it makes the most sense (and it doesn't always) I try to avoid using frameworks but I would hardly call myself a cowboy (though perhaps I will going forward, ha).
The DOM API, as this article shows, provides quite a bit of functionality that many popular frameworks / libraries provide and as long as you don't need to target old browsers you're fine here.
Yes, angular and react do a lot for you but you can still write effective web applications without them with minimal "reinventing of the wheel". Just because someone provides a way to do X in a framework doesn't mean it's not easy to still do X without a framework. Many times the bulk of the framework's capabilities are supporting its own, specialized workflow that isn't always necessary.
Re: You probably don't need a JavaScript framework
#133I 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.
Re: You probably don't need a JavaScript framework
#134I'm really glad I don't have to work with people who think like this. You don't NEED a framework, just like you could theoretically build a car from scratch. If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about. Frameworks do exactly what they say, provide a common framework for your team to work off of while they build a complex application. I fee…
'simple people' as opposed to? I think people are coming down really hard on the article, and I found it to be light-hearted, and simply asking people to revisit where we're at. He doesn't call for anybody to stop using their frameworks. I am studying Erlang/LFE. I chose LFE over Elixir (I know it is not a framework), since I like Lisp rather than the Ruby-like syntax of Elixir, and because one of the creators of Erl…
Nobody brings in a framework out of hope that it will lead to them getting a job at said sponsors company.
If they do they are very very misled.
People choose a framework because they want to benefit from the R&D done at said company, and avoid sinking similar R&D costs into their product.
I don't find happiness when my neighbors "cow dies" (I like that metaphor), but it does pay the bills, and that makes me happy. If people keep making the same mistakes, I will keep getting the same contracts in my inbox.
p.s. try breaking up your wall of text in future posts, it makes your response really difficult to read.
Re: You probably don't need a JavaScript framework
#135Earlier quoted context omitted.
"I feel like people who say "just use the dom" don't actually have enough experience to know why that is such a bad idea." "You people really are kidding yourselves. I feel bad for whoever is paying your salaries." "Honestly, it just sounds like you are bad at managing your own software projects" "I'm really glad I don't have to work with people who think like this." "Both are signs of inexperience." "I guess I won't…
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.
Re: You probably don't need a JavaScript framework
#136Earlier quoted context omitted.
I think you're touching on exactly the problem: a 'spaghetti be-spoke' js app. Can a JS app be anything but? Javascript is a language for the view layer. It's supposed to be the minimal shim on top of LAMP or Rails or whatever, to bridge the gap between static HTML and dynamic movement. It was never supposed to run the entire app!
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.
Re: You probably don't need a JavaScript framework
#137Earlier quoted context omitted.
The main contention of the article is that this "simplicity" is illusory. You end up writing just as much code, but now you've added a complex dependency you don't really understand but have to make your customers download, and ultimately have to test against
That seems incredibly anecdotal. Perhaps if you don't understand the framework you are using. Ember (for example), takes care of huge swathes of complexity for you. I can't imagine trying to build a: * client side router * data transportation/cache layer * view layer * model layer * build pipeline ... and more, in less code that just `npm install -g ember-cli` `ember new my-app` And then having a common app structure…
> And then having a common app structure with thousands of other people that can provide help and insight.
You don't think that there are thousands of people who can provide help and insight into the standard Web & DOM API's? I mean, do you in all seriousness think that there are more people that can help you with React than it is that can help you with the Web & DOM API? Not to mention the standard browser libraries have decades worth of documentation and information about them, freely available.
> * client side router * data transportation/cache layer * view layer * model layer * build pipeline
Let's narrow that down a bit:
client-side router - There's examples online of a router that's 20 lines[1]
data transportation/cache layer - Umm, what? The browser already takes care of data transportation (also known as the HTTP protocol, WebSocket protocol or WebRTC - whichever floats your boat). Surprisingly, it also takes care of caching as well.
view layer - if you absolutely need one, here[2] - 2KB and has everything you need.
model layer - `class Model { ... }` and `let model = new Model('path/to/component')`. Simple as that.
build pipeline - don't really need to "build" thanks to HTTP/2. Otherwise if you want to transpile anything you could always just setup a single-line `npm run build` script.
> You people really are kidding yourselves. I feel bad for whoever is paying your salaries.
Why can't you try to have a friendly discussion instead of attacking on a personal level as you've done countless times throughout the comments. Nobody's pointing a gun at you.
[1] - http://joakim.beng.se/blog/posts/a-javascript-router-in-20-l... [2] - https://github.com/pakastin/frzr
Re: You probably don't need a JavaScript framework
#138Earlier quoted context omitted.
I think you're touching on exactly the problem: a 'spaghetti be-spoke' js app. Can a JS app be anything but? Javascript is a language for the view layer. It's supposed to be the minimal shim on top of LAMP or Rails or whatever, to bridge the gap between static HTML and dynamic movement. It was never supposed to run the entire app!
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 provide search engines with indexable dynamic pages?
Uh, through clever use of jquery AJAX and postgres indices?
How does a LAMP/RAILS app preserve client state between page reloads?
A serverside redis cache? In the database? In the cookie? LocalStorage? C'mon man.
How does a LAMP/RAILS app synchronize client state between multiple connected clients?
By pushing a hash with current state to all clients via polling? Websockets? Whatsitcalled where you don't close the original HTTP connection? Did you know postgres has some pretty awesome realtime pubsub tech? I suppose if I have some extra time I could send changesets and load them with $.merge()
...
I just want you to know that you are doing nothing to improve my image of the JS-scene-writ-large as immature, spoiled, and childish. There are isolated pockets of brilliance, for sure, but the everyday talk scares me.
Re: You probably don't need a JavaScript framework
#139Earlier quoted context omitted.
The main contention of the article is that this "simplicity" is illusory. You end up writing just as much code, but now you've added a complex dependency you don't really understand but have to make your customers download, and ultimately have to test against
That seems incredibly anecdotal. Perhaps if you don't understand the framework you are using. Ember (for example), takes care of huge swathes of complexity for you. I can't imagine trying to build a: * client side router * data transportation/cache layer * view layer * model layer * build pipeline ... and more, in less code that just `npm install -g ember-cli` `ember new my-app` And then having a common app structure…
> I can't imagine trying to build a:
* client side router * data transportation/cache layer * view layer * model layer * build pipeline
Why can't you? Routers are easy; you likely don't need more than a few lines of code to accomplish most of what you need. Caching and data transportation is also easy and simple (there are a million cache libraries if you don't want to write a small one). Views and models have been done since the 90s and are relatively easy as well (in fact I wrote one in just a few minutes the other day to drop some dependencies from a personal project). Though models are not always the best way but I'm digressing.
Build pipelines usually add more complexity than needed in my experience. I almost always, eventually, nix whatever complicated build pipeline I start out with and go with something dead simple.
Most of this stuff has been done for over 15 years on the web. It's at the point where it should be mostly boilerplate / routine if you're not using a framework.
Re: You probably don't need a JavaScript framework
#140The point of React isn't its performance (though that is nice). The point of React is the simplicity and composability of functional components. You can create this on your own of course (and I have), but the solution of "just use the DOM" ignores an enormous amount of progress that React made with component design , not performance.
Saying "React is all about composable components" is just as incomplete as saying "React is all about performance."
Here's my attempt: React is about making composable UI easy using stateless components which can still update fast because of the virtual DOM optimization.
(OK looking again you did say "functional" which implies something similar)
It's a bit harder to understand than the simple API indicates, especially coming from other kinds of stateful architecture. What I like best about React is how yoy can optimize stateless components incrementally, all the way up to where you're doing everything with raw DOM manipulation in the lifecycle methods. And how it's fast enough that you usually don't have to optimize at all.