231–240 of 356 posts
The article's author does not seem to understand what React is for and why people use it. The article is full of sentences like: it's true React is fast, but basic Javascript is even faster. Duh? It's true React is quite small, but if you don't use it, your site will be even smaller. No sh*t Sherlock? React was invented to simplify the program structure of medium-to-large applications by replicating the successful da…
Are Slack Files an official blog from Slack? For a second, I thought looking at the URL that this was just a URL for a Slack snippet or something similar.
Earlier quoted context omitted.
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.
What's the difference between platforms, frameworks and libraries? Here's my attempt ... jQuery: library. (Others: D3, knockout). Salient feature: does not impose code structure or organization of code modules. Angular and React: frameworks. Salient feature: expects adherence to module separation and code structure protocol. Like other MVC frameworks. EJB: platform. Salient feature: provides entire terra firma and at…
I'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…
'I'm really glad I don't have to work with people who think like this.' You're glad you don't work with people who weigh up the list of possible solutions based on the specific problem? You're glad you don't work with people who care about performance, size and redundant code? You want to work with people who don't think, who don't question implementation? Thats pretty dumb isn't it. If someone has an alternative sol…
I don't really need a smartphone, but it is quite useful.
Earlier quoted context omitted.
Dude. This site has onlylike 6 lines of JavaScript, and that's just to make the arrows disappear after you click them.
This site is also extremely simple and only requires 6 lines of js. HN is not a complex app.
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…
And that's perfectly valid. In fact, it's one of the best reasons to use a framework.
If I hand-roll my application with a cobbled-together framework, I am the only one who understands how it works. Even if I'm a pretty great developer and write very clean code, there is an inherent complexity cost to any code—whoever comes on board will have to learn how I'm tracking state, managing the DOM, etc.
On the other hand, if I just wrote it in React I could be fairly confident that another web developer could pick up the project and easily understand how things are working with minimal effort. They've likely already paid the complexity cost of understanding React.
That's what the article and OP entirely miss. We don't use frameworks to improve the speed of the application. We don't even use frameworks to improve the speed of development. We use frameworks to improve the speed of understanding.
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…
We did it because users demand it. A SPA feels substantially faster and more reactive. Users notice.
If Gmail used your approach, it never would have succeeded.
> How does a LAMP/RAILS app provide search engines with indexable dynamic pages? Uh, through clever use of jquery AJAX and postgres indices?
I have to assume you're just throwing out terms you've heard of but never understood. Database indexes have literally nothing to do with making your site indexable for search engines.
Earlier quoted context omitted.
It wasn't written to be easily maintainable, as it was a PoC. So no comments, relatively short naming. However, it had good SoC and simple logic to update views. Minimal, but understandable. I wanted it to be rewritten before I wrote the first line of code. My trust went to someone who does full-time web development (I'm alround, full-stack).
What is the argument here? You wrote a POC of unmaintainable code, and then some junior web devs butchered your project because it was undocumented and "understandable" to you only. Get off your high horse. If I was your boss I would be asking why you didn't speak up earlier, and why you didn't document your work better.
Going from "not written to be easily maintainable" to "unmaintainable" is exactly the problem you see very often. Instead of investing a bit of time to learn things and make them incrementally better people cry foul when it's not perfectly to their liking (i.e. if they haven't written it themself) and tell you later when you ask them if that monstrosity they've written was really necessary - which probably doesn't work and/or has bugs which had been already fixed in the original codebase - that it was "unmaintanable" and so they "had" to rewrite it.
Earlier quoted context omitted.
It's a lot easier to learn React than what all of you think. It's especially easier to learn these frameworks when you tried to solve the problem without them and experienced the pain of not having them.
As a user of React, I disagree -- unless you are using React in a javascript runtime, in which case you're probably fine. But I resent react for all the extra cognitive load it forces me to worry about when all I really give a shit about is its shadow DOM implementation. And then, only when I've got page(s) full of data I need to update without lag.
> unless you are using React in a javascript runtime, in which case you're probably fine
React is written in JavaScript. It runs exclusively in JavaScript. If you've somehow managed to run it outside a JavaScript runtime then I'd actually be delighted to learn about how.
> all I really give a shit about is its shadow DOM implementation
React doesn't have a shadow DOM.