What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch?
Thanks!
101–110 of 247 posts
What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch?
Thanks!
Earlier quoted context omitted.
The old advice was wrong anyway. First, in practice what everybody turned up doing was the inverse (add programming logic inside their HTML). So you still had mixed HTML and JS, but in a way worse way: with ad-hoc and incompatible pseudo-languages (e.g. Angular's ng-repeat etc, Knockout's template instructions, etc), spiced with "JS inside HTML attributes", with no syntax checking (a typo could blow your code in runt…
> After all in every native UI framework you have instructions to draw the widget IN your code -- not as some external additional technology. A widget's C/C++/Obj-C/Swift/Java/C# etc code encapsulates everything about creating it and showing it. With the notable exception of Windows. XAML strictly enforces code and markup separation. It makes the View layer more toolable and easier to edit by designers who usually do…
I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?
This is a debate that has been going on since I started in the late 90ies. You need some sort of logic in your views, no matter what system you use, i. e. loops or formatting dates. Because people are raised on the "don't mix logic & layout" maxim, they feel dirty when they write sich logic in their usual language. .. so they invent template languages... ... that then expand to be turing-complete and basically offer…
It sounds to me like you are arguing that because people will put logic in templates, and this leads to ugly template languages, we should just program in ugly template languages rather than doing any separation of logic from templates.
I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?
This is a debate that has been going on since I started in the late 90ies. You need some sort of logic in your views, no matter what system you use, i. e. loops or formatting dates. Because people are raised on the "don't mix logic & layout" maxim, they feel dirty when they write sich logic in their usual language. .. so they invent template languages... ... that then expand to be turing-complete and basically offer…
Where I work right now, we use the newer versions of ASP.NET that come bundled with the Razor templating engine, which uses .cshtml files. You can write C# inside the files much the same way you can write JavaScript in a JSX file, it makes creating forms and such a breeze.
Big bonus is that moving from writing server-side logic to client-side logic doesn't require much of a context switch, and you can use the same objects to represent your data on both sides. If I spend all day moving between half a dozen different languages that get compiled by a dozen different tools, it can get a little exhausting.
Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it. What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch? Thanks!
What really bothers me about React (and other frameworks) that without JS you do not see anything. No fallback. No progressive enhancement. Is this really the way to go? Did JS replace HTML/CSS as the backbone of websites/applications ?
On e.g a newssite react doesn't make much sense though (except, possibly on the backend).
Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it. What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch? Thanks!
I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?
Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it. What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch? Thanks!
Since we started using Webpack where I work we've stopped using all other build tools. There's very little Webpack can't do, and the main advantage is that there's no need to hook things up to eachother since it's all part of the same system.
#3 Write functional components I'd say "Write functional components where it makes sense". For simple components that is a reasonable advise, however in cases when you need such methods as `componentDidUpdate` or generally any lifecycle methods - that won't do and you have to use classes.
Not a React guy, but why couldn't the component that updated broadcast that it did so? Or is that componentDidUpdate method a callback to the message I'm describing?
However, if the component that just updated is high level, like an entire page or something, then it's reasonable to assume it's a one-off controller component and you should feel free to broadcast messages and couple the component with other parts of the program.
https://medium.com/@dan_abramov/smart-and-dumb-components-7c...