121–130 of 422 posts
React will die by the weight of the frameworks and libraries that have duplicated effort and created more confusion and divide amongst the developer community.
It's made my life infinitely easier writing front end apps that need to keep state and update when the data changes. Remember the old days of backbone and marrionette? Remember even older, having horrible jquery sprinkled around everywhere?
http://isfiberreadyyet.com/
Is fiber similar to what glimmer is to ember? Is it a big enough improvement to reconsider using react instead? (I was stoked on the glimmer stuff).
If you left React for performance reasons especially related to real-time updates or animations, well this version is better.
They saw what happened with Angular and Angular 2—which Google named the same despite it being a totally different framework—and made a smart move.
Earlier quoted context omitted.
> which is the standards-based approach that ES6 actually provides for embedded DSLs and templating. Template literals could not possibly be a replacement for JSX. JSX is Javascript, template literals are strings. JSX isn't a templating language by design, it's one of the primary advantages.
JSX is not JavaScript, it's a non-standard bastardization that will never be supported natively in browsers. Its reliance on JavaScript for flow control is so problematic[1] that people have started working around its many glaring inadequacies by adding new language primitives to JavaScript itself via Babel plugins[2]. I do my templating in template literals because using standards-based JavaScript means that I don't…
That issue you linked to is 4 years old and is clearly a reflection of the poster being unfamiliar with React/JSX. The community has since unambiguously decided to avoid inserting more control flow in JSX. Also, I'm not entirely sure what the do/while plugin has to do with JSX.
> I do my templating in template literals
I would argue if you can write your code as easily with template literals as React/JSX your application isn't complex enough to warrant using a framework.
http://isfiberreadyyet.com/
Earlier quoted context omitted.
> Application development is complex, period. Posix development is complicated. Qt is big and complicated. Makefiles are complicated. Autotools is complicated. Big Java server apps are complicated. C++ is complicated. We've just hit the point where people are trying to do the same thing in a browser. Actually, Java, C++,QT and co are going through great length to make development simpler and all the compilation pipel…
The word Java and "simple development" is just absurd for any real application much less most enterprise applications.
Building Java applications using Undertow with a build setup in gradle is not _that_ different from a node.js service using Express and package.json for dependencies, or a Ruby, Sinatra and Rake stack. After having tried all three, I ended up going back to the JVM. It's not a perfect ecosystem, but it's damned good one.
Earlier quoted context omitted.
Your comment seems to be a bit of a non-sequitur. Application development is complex, period. Posix development is complicated. Qt is big and complicated. Makefiles are complicated. Autotools is complicated. Big Java server apps are complicated. C++ is complicated. We've just hit the point where people are trying to do the same thing in a browser. Would you prefer to build your application using Make, Scons, Waf, CMa…
> Application development is complex, period. Posix development is complicated. Qt is big and complicated. Makefiles are complicated. Autotools is complicated. Big Java server apps are complicated. C++ is complicated. We've just hit the point where people are trying to do the same thing in a browser. Actually, Java, C++,QT and co are going through great length to make development simpler and all the compilation pipel…
Earlier quoted context omitted.
I admire your exceptional work cataloguing these resources. However, just one look at that giant horde of links is, to me, a perfect demonstration of why the front-end development ecosystem is way out of control. Its amazing to me that the autoconf/automake/libtool system for making write-once-run-everywhere *nix applications is downright simple by today's standards. Every year the hot libraries change, the build too…
I don't know about others but I tire of these comments chiding the "out of control" front-end ecosystem. The situation has already changed years ago. We aren't going to get off of your lawn while you continue to beat a dead horse. The web is built on open standards and there are billions of pages and apps out there. To expect web development to be a perfect monoculture is a failure of your imagination and ability to…
Old people also get tired by all these "apps" wining for your attention; they want "just a phone". Young people grew up with it. Note to self: I'm getting old.
Old people were used to buying development toolset (compiler+tools+IDE), usually including a physical book, with which they can create software. Young people are used to assessing open source projects, and piecing a project together on top of many freely available libraries/frameworks.
Earlier quoted context omitted.
Monocultures develop because one tool is far better than all the others. Javascript isn't a monoculture because all the tools are bad.
Monocultures develop because of corporate backing. The web being open and unclaimed is what leads to the great diversity. As someone who does both server and JavaScript development, the tools are not bad. Often times they solve real problems well.