Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things every React.js beginner should know

camjackson.net

Post reply on HN
Print view View original

131–140 of 247 posts

Re: Things every React.js beginner should know

#131

Post by chimeracoder »

escherize wrote: post #100
aikah wrote: post #91

Earlier quoted context omitted.

> ... that then expand to be turing-complete and basically offer everything their primary language offered in the beginning. then they wrote template languages on top of the template language to separate layout and logic again ( PHP vs Twig/Smarty ) so maybe we need to step back a little and figure out how to write a language that wouldn't need a different syntax for logic and layout. This family of languages exists…

I'm a huge fan of Clojure's Hiccup library. It allows the user to make html like the following. Here's a function that always returns true - but it could do any kind of data access. It is just plain Clojure. (defn selected? [] true) Here is a datastructure that represents html: [:h2 {:class (when (selected?) "selected")} "Hello"] Calling the function hiccup.core/html on that datastructure yeilds an html string like t…

> I'm a huge fan of Clojure's Hiccup library. It allows the user to make html like the following.

It helps that Clojure's syntax is based on s-expressions, and s-expressions are already isomorphic to HTML/XML.

So in a way, you're still mixing your templates and your code, but you happen to be using the same syntax for both. Which is arguably an improvement.

Re: Things every React.js beginner should know

#132

Post by lmm »

matt4077 wrote: post #79
pkrumins wrote: post #10

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…

> You need some sort of logic in your views, no matter what system you use, i. e. loops or formatting dates.

No you don't. Look at Wicket for how to do this right: everything is a component, the only thing[1] your templates contain is a) markup (which is 100% valid, using a namespace for the only wicket-specific part) and b) ids that indicate that a given tag will be replaced with a component. Everything else is handled by the component hierarchy in code, using proper OO polymorphism (it's also a great example of proper use of OO, with classes left with only the correct extension points, and classes or methods declared "final" if the developers don't intend to support custom ones going forwards). You end up making truly reusable components that can be very small - even something like an address input is a component defined in terms of smaller components.

I wish there were Wicket equivalents in other languages.

[1] There are a few other conveniences, but they really are minimal

Re: Things every React.js beginner should know

#134

Post by matchagaucho »

pkrumins wrote: post #10

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?

JQuery took this "best practice" to it's extreme, and we learned 2-way data binding is bad.

React enforces 1-way data binding and renders everything in one clean pass (HTML/CSS/JS).

Re: Things every React.js beginner should know

#135

Post by DougWebb »

pkrumins wrote: post #10

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?

One of the features I always liked about Perl, which I felt set it apart from other languages, is the way regular expressions are part of the language syntax rather than an OOP library. In other languages, regular expressions seem very clumsy to use, while in Perl they're very natural. This is most evident when you're trying to use capturing parentheses; the differences between Perl and, say, C#, are huge.

Back in the day, I thought it would be a great addition to Perl if xml/html was also added to the language syntax. This was before html templating systems existed, and CGI.pm wasn't a good choice for my web application, so my code was full of print statements, quoted strings containing html, and having to use qq!...! for my quotes to avoid problems with " and ' characters in the output I wanted.

When I first saw JSX it seemed like a great thing, finally satisfying that old desire to have html markup as a native language syntax feature. I feel like it can be transformative, in the way you write your code, just like Perl's regex syntax or like having functions as first-class values can be in functional languages.

Having used React.js a bit, I'm not so sure. But I'm probably biased because I don't think React.js fits well with what I'm trying to do: ASP.NET MVC web applications that are mostly traditional full-page-refresh style apps, with some SPA-like AJAX-based interaction on some pages. I wanted to use React.js for those SPA-like pages, but it doesn't integrate well (or at all) with Razor-based server-side rendering, and in my testing it had a significant 1000ms+ startup time when the page loaded even for pretty trivial components, with caching of the React and Babel javascript files.

Re: Things every React.js beginner should know

#136

Post by stevejohnson »

tptacek wrote: post #113
Ambroos wrote: post #109

Earlier quoted context omitted.

I think Webpack has the monolith advantage here. It allows you to add things that would otherwise be immensely complex with ease because it can do a lot. You can have it handle bundle splitting and async loading of modules, image optimising and hashing, CSS/SASS/... processing, ... 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…

So a big reason to use Webpack is that I can replace both Gulp and Browserify with it, and have one fewer component?

Yes. Also, it will build faster and the configuration will probably be simpler. That's been my experience having used Browserify with Gulp and Grunt for 2 years and then switching.

Re: Things every React.js beginner should know

#137

Post by mst »

teej wrote: post #115
escherize wrote: post #100

Earlier quoted context omitted.

I'm a huge fan of Clojure's Hiccup library. It allows the user to make html like the following. Here's a function that always returns true - but it could do any kind of data access. It is just plain Clojure. (defn selected? [] true) Here is a datastructure that represents html: [:h2 {:class (when (selected?) "selected")} "Hello"] Calling the function hiccup.core/html on that datastructure yeilds an html string like t…

I don't know man. Every time I've worked with that style of approaching the problem, it feels like I'm just writing HTML with different syntax.

If (if) you already like lisp, it more feels like writing HTML with cleaner, more composable syntax. Were I working on an all-lisp team, I'd be totally happy to use it. Since I'm generally not, JSX function components seem to be the next best (or at least next-least-worst) thing.

Re: Things every React.js beginner should know

#138

Post by mst »

toolz wrote: post #96
matt4077 wrote: post #79

Earlier quoted context omitted.

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…

Pakyow also uses logicless templates. It achieves this by having processors in ruby that you can bind to scopes/attributes. Now I have everything I need to process this html with my logic to turn it into Frank Bob https://pakyow.org/ edit: I wish downvotes required commenting on why you're downvoting.

I suspect it's because people regard the implied foreach loop of data-scope to not count as logicless. Personally I can see the arguments both ways, and have concluded that simply ensuring I'm using the same definition of logicless as the people I'm talking to is the best answer.

Re: Things every React.js beginner should know

#139

Post by wanda »

robmcm wrote: post #52
pkrumins wrote: post #10

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?

The early web days were spend developing basic web pages without any complex tools. These days everyone seems to think they need an application style site, and whilst some sites really do benefit from this approach, others don't. The trinity of web standards (html/js/css) are still valid for informational, mostly static web pages, but are impractical for developing applications. The discussion of what is a web applic…

I think what qualifies a web application is the introduction of state and enabling the manipulation of data. Static sites, or dynamic websites without the state problem to the end user, are naturally better off without a client-side app approach (though ajax is still beneficial and structuring your approach to ajax can make client app frameworks/libraries tempting)

However, when you start giving the user powers to manipulate data and make the manipulation of data a core function of a website, it becomes a web application.

Photoshop is an extreme example of a web app really, and perhaps the most basic web app would be something like a CMS or a forum. Hence why social networks and email clients are created as apps now: they involve repeated display and manipulation of elements which are liable to change.

Initial attempts to improve the user experience of such tools as online chat and mail were made by using Ajax and this has culminated in asynchronous Ajax and virtual DOM models in order to achieve a real-time effect without sacrificing accessibility and performance.

We went from reloading entire pages to reloading bits of pages to never loading those bits but rather constructing them on the front-end drawing data from APIs.

Now with React and similar libs, we are looking at a hybrid approach: exposing data via API but (ideally) constructing and emitting HTML on the server before pushing the app to the client where a virtual abstraction of the DOM is established, but where data can still only be manipulated in one direction. This means that there is no state issue, because while routing and other interactions are achieved client-side, their composition is determined on the server.

It's almost a dialectic cycle of thesis, antithesis and synthesis.

Re: Things every React.js beginner should know

#140

Post by [deleted] »

escherize wrote: post #100
aikah wrote: post #91

Earlier quoted context omitted.

> ... that then expand to be turing-complete and basically offer everything their primary language offered in the beginning. then they wrote template languages on top of the template language to separate layout and logic again ( PHP vs Twig/Smarty ) so maybe we need to step back a little and figure out how to write a language that wouldn't need a different syntax for logic and layout. This family of languages exists…

I'm a huge fan of Clojure's Hiccup library. It allows the user to make html like the following. Here's a function that always returns true - but it could do any kind of data access. It is just plain Clojure. (defn selected? [] true) Here is a datastructure that represents html: [:h2 {:class (when (selected?) "selected")} "Hello"] Calling the function hiccup.core/html on that datastructure yeilds an html string like t…

[deleted]
Post reply on HN