41–50 of 228 posts
I just wanted a way to put templates in tags that get loaded by React Components. That way, I won't be mixing templates and the behavior of the components. Has anyone done this before?
Earlier quoted context omitted.
Not even if bower let you search by component type or some kind of category or tag?
The best interface for a react UI component repository would be something that had information like: * A picture of what the component looks like * How large the component is in KB * Which CSS frameworks it requires or supports * Cross browser support information Bower is a very simple package manager right now with little information about the package beyond its name, a line of descriptive text, and a link to the Gi…
As mostly an outsider to the web front end development, React.js is probably the easiest one for me to understand among the typical "frameworks", especially Angular and Ember. After all the excitement about Angular for example, I went to learn about it and just got lost with new concepts: DOM transclusion, scopes, services, directives, ng-apps, controllers, dependency inversion and so on. I can use it but need someon…
Would you recommend using React instead of Angular for JS heavy areas of a website that is built with a server side framework (like Rails, Django etc.)? I developed a rather complex SPA with Angular recently and I cannot go back to the ghetto that is jQuery when using server side rendering.
Angular solves more than the UI problem,React on its own doesnt solve the architecturing problem , AngularJS does. The big weakness of Angular is server side rendering,which involves heavy solutions like phantomjs,while you can render react components on the server. Angular is not very good at rendering/managing svg either,that's a fact. I would argue maintaining pure html templates is not that hard. But frankly Angu…
It has been discussed on HN before : https://news.ycombinator.com/item?id=7719957
Some good comments there, worth checking out. Personally, I think the message loop architecture proved very good in Windows when processors were slow and had only 1 core and it is at least worth giving it a try in web development.
Earlier quoted context omitted.
I just tried it on Firefox 26 on OSX and could not replicate. It has worked for everyone I've had test the page. The only thing that happens when you press back is the animation to load the right demo. There might be something buggy with how the CSS animation is using your graphics driver?
Back button breaking on latest version of Chrome/Win7 here. Scrolling up and down adds history.
For those that haven't tried it, David Nolen's Om for ClojureScript is an excellent React framework. https://github.com/swannodette/om I've not used vanilla React, but Om is certainly fantastic and apparently adds a bunch of stuff that's not in the JS version. Also, a web framework written by the guy that wrote most of the language you're using? Win!
Would you recommend using React instead of Angular for JS heavy areas of a website that is built with a server side framework (like Rails, Django etc.)? I developed a rather complex SPA with Angular recently and I cannot go back to the ghetto that is jQuery when using server side rendering.
Earlier quoted context omitted.
I'm working on an app that takes this idea a step further. It is a platform that lets people create apps by defining a data schema and UI components to edit and display this. Once an app/schema/component is defined, it can be "forked" by others and further customized. Think github not for source code, but live apps[1]. One of the key requirements for this was a way to run untrusted scripts client-side (server-side is…
That is pretty interesting. So using Fora you can jumpstart a new app by defining all your data models, and then select a bunch of components to build a skeleton view that makes use of those models? If so this will be very useful, especially since it sounds like it will allow us devs to spend more time on the business specific logic, and making the interface beautiful, instead of spending lots of time gluing together…
The social aspect is equally important:
- There are millions of developers who don't participate in improving apps today because creating and hosting an app isn't a friction-less process. On Fora, if you see an app/forum that fits your needs, click fork, edit some JS+React/JSX in the browser, and you have a new app.
- Everybody sees all source code for all apps/forums; so it's great to learn. And then improvements help everybody. Like wikipedia for code. .
- Many people know enough JS to tweak stuff. React mostly takes just JS knowledge, so you don't need to know the framework like Angular. Ah, and also isomorphic UI code that runs on the server and browser. Also for all it's issues, one thing JS has going for it is that you can read and edit in a browser.
Ah there; I got excited. :)
Tester: The UI is wrong right here... Developer: Hmm...I wonder how long it's going to take me to figure out where that HTML was generated in my javascript.
You can either build something on a mass production line, where you're just screwing the same bolt in day in and day out, or become a master craftsman and build it with proper care, design, and quality.
These frameworks are nothing more than a factory floor and if all you do is build apps with a framework you're little more than a paid glue stick piecing bits of code together. Or you can become a master software developer and build something of quality without needing a crutch like a framework.
Now, if the needs of the project are such that a framework will suffice then by all means, use a framework. Chances are, if you're doing more than building a working prototype then at some point a framework is going to fail you. If you enjoy building apps using frameworks then by all means, do it. But to my mind you're doing your customer a disservice.
Contrast that with great software developers (and I've been fortunate to have worked with some really great developers) who abhor these frameworks. They can get more done with less code and ultimately deliver the project faster without frameworks. The tradeoff is that it takes time and dedication to achieve that level of mastery. I personally would prefer that path.
I have two concerns with this approach. Take everything I say with a grain of salt as one of the authors of Ember.js.
First, as described here and as actually implemented by Om, this eliminates complexity by spamming the component with state change notifications via requestAnimationFrame (rAF). That may be a fair tradeoff in the end, but I would be nervous about building a large-scale app that relied on diffing performance for every data-bound element fitting in rAF's 16ms window.
(I'll also mention that this puts a pretty firm cap on how you can use data binding in your app, and it tends to mean that people just use binding from the JavaScript -> DOM layer. One of the nicest things about Ember, IMO, is that you can model your entire application, from the model layer all the way up to the templates, with an FRP-like data flow.)
My second concern is that components libraries really don't do anything to help you manage which components are on screen, and in a way that doesn't break the URL. So many JavaScript apps feel broken because you can't share them, you can't hit the back button, you can't hit refresh and not lose state, etc. People think MVC is an application architecture, but in fact MVC is a component architecture— your app is composed of many MVCs, all interacting with each other. Without an abstraction to help you manage that (whether it's something like Ember or something you've rolled yourself), it's easy for the complexity of managing which components are on screen and what models they're plugged into to spin quickly out of control. I have yet to see the source code for any app that scales this approach out beyond simple demos, which I hope changes because I would love to see how the rubber hits the pavement.
It's always interesting to see different approaches to this problem. I don't think it's as revolutionary as many people want to make it out to be, but I've never been opposed to borrowing good ideas liberally, either. Thanks again, James!